In today’s rapidly changing world of disruptive digital innovation, how are you keeping your software current? Your answer to this question will have a real impact on your company and its ongoing success.
In a 2014 Keynote to the Engineering of Complex Computer Systems (ICECCS) 19th International Conference, Professor Mike Hinchey, director of the Irish Software Research Centre, Lero, stated “software can be considered to be critical, due to the business or other functionality which it supports. Upgrades or changes to such software are expensive and risky, primarily because the software has not been designed and built for ease of change.”
Software is designed and written to solve a problem. Software architecture, guided by highly educated and experienced software engineers, is currently considered to be well designed when it does an efficient and effective job of solving the problems it was intended to solve. That design is not necessarily meant to solve future problems or enable easy adjustment to changing business realities – this is a challenge in today’s rapidly evolving technology driven world. And the problem of keeping business critical software current is even more of a concern when it comes to legacy software installations.
The 2015 IFIP IP3 GIC 2020 Skills Report covers an area of growing concern for many enterprises – legacy software.
According to the report, “Within most organisations there will be a mix of technologies and capabilities, some leading edge, some commodity and some ageing or legacy. This legacy debt does not mean that the technology is useless or has no value. Sometimes it is core to the business. However, some of those technologies are no longer being supported. As part of the analysis it has been very difficult to quantify the challenge faced globally from systems and software that can be viewed as legacy.”
How does a company deal with this legacy issue? The Skills Report found that companies cope in one of three ways:
- If the systems are working and there is no need to replace the systems, they will continue to be used;
- The approaches to managing such systems have moved from white box changes to more black box assessment (i.e. do not touch the system but let it do what it does); and
- As these systems get older the available pool of labour that can provide support diminishes.
As proof for the third point, there are a number of articles lamenting the shortage of COBOL programmers capable of keeping that workhorse main frame humming along. Yet many organizations including those in the financial services industry continue to rely on COBOL based business critical systems.
The COBOL need points to an issue that needs a solution going forward: we need to move away from past software design practice and move to design software that can be easily changed and without risk. This is already happening in some companies.
Amazon Web Services (AWS) uses “formal specification and model checking to help solve difficult design problems in critical systems.” Despite protests to the high cost and complexity of formal methods design, AWS found through their experience that:
- Formal methods find bugs in system designs that cannot be found through any other technique we know of;
- Formal methods are surprisingly feasible for mainstream software development and give good return on investment.
This lesson has been so deeply learned that, now, “at Amazon, formal methods are routinely applied to the design of complex real-world software, including public cloud services.”
Software will continue to be used and that usage will increase in all aspects of business. There will likely come a day not too far from now where every business on the planet will rely on software in some form.
According to the AWS experience and based on the work of Professor Mike Hinchey and his team at Lero, there are ways to move forward that will enable agility and reduce risk in maintaining and changing our business critical software. Business leaders and in particular CIOs and CTO’s need to understand this approach to software design and start to insist on it from their architects. Software engineers can only benefit from incorporating these approaches in their design arsenal and deploying them whenever possible.
This is not a completely new way of doing things but it is not nearly as well known or understood as it needs to be.
If you want to get a solid understanding and overview of the whole domain of evolving critical systems from the director of the Lero Institute himself, then you can register today for the upcoming August 2 ACM webinar with Professor Mike Hinchey.