Requirements Engineering and Legacy Systems
|Dr. Jens Kawelke is Head of the Competence Unit Requirements Engineering at NTT DATA Germany. He consults clients regarding the Requirements Engineering methodology and offers Requirements Engineering training for clients and internal staff.|
In an earlier article Requirements Engineering and the benefits of its professional use in software development projects were introduced. Examples of project failures were given and it was argued that requirements engineering techniques can reduce the risk of such failures. Furthermore, the necessary skills of a requirements engineer and the subareas of Requirements Engineering were listed. Also, possible tool support for the work of a Requirements Engineer was introduced.
In this article specific IT project situations will be considered where Requirements Engineering techniques are very essential. Legacy systems, that are still very prominent in the insurance business, will be looked at. Some alternatives to overcome the problems with legacy systems will be suggested and necessary Requirements Engineering methods for each of the alternatives be analysed in detail.
2 Legacy Systems - a Love-Hate-Relationship
You have all seen legacy systems and many of you probably still work with them almost daily - these systems with the black background and bright letters (mostly white, yellow or green). You hardly need the computer mouse to work with them. The more you need the "tab" key to jump from one input field to the next. And you need short cuts, i.e. numbers and letters or the "F"-keys to change from one screen to the next (see Figure 1 for an example of a legacy system screen).
Figure 1: screen of a legacy system
Legacy System are usually more than 25 years old, some even 40 years and more. They are implemented with programming languages called, for example, "COBOL" or "PL/I". The original programmers are mostly pensioners by now and if you are lucky they have entered lots of comments into the source code and written a lot of system documentation.
In our days the word "legacy" has a bad "aftertaste" in the IT world. But IT systems are legacy systems and still exist because they are successful. They are very reliable and have very few bugs. And: They are fast!
Users are very familiar with their old system. Some do not think that there is anything better on the market. However, as much as some love the legacy systems, others hate it.
Especially in these days, when the competition in the insurance market is very high, the insurance companies need to react quickly to the changing needs of the customers. New insurance products need to be introduced in a short time. Think only of the upcoming car insurance issues like telemetry and autopilots.
And here, the disadvantages of the legacy systems become apparent:
- High maintenance costs
- Low scalability
- Integration problems with other systems
In other words, legacy systems can be a barrier to innovation.
3 The Alternatives
The legacy system does not necessarily need to be scrapped altogether.
However, in order to remain a big player in the market, the insurance companies need to take a strategic decision.
Depending on the
- pressure of the market
- available budget
- available modern products for the functionality to be replaced
- size of the legacy system
you can mainly choose between 3 different options:
1. The modernization of the legacy system
2. The replacement of the legacy system by
a. an off-the-shelf product
b. a new system
All these options must, off course, be performed within an IT project. One of the key factors for the success of those projects is the application of professional requirements engineering. The following chapters are intended to give guidance for the right decision and to help reducing the risk of a project failure.
4 A Precondition
Independent of the choice of the 3 options above, a prerequisite for the start of a modernization or replacement project is the existence of a professional documentation of the legacy system. This could be a detailed textual system documentation of all available functionalities of the old system or even better documentation based on the Use Case concept - a mixture of textual documentation and UML diagrams. Since the Use Case concept was not "invented" by the time of the implementation of most legacy systems yet, the best you can get is probably the textual documentation.
But if there is no documentation, then a project must be undertaken that results in the post-documentation of the legacy system. The technique to do that is a specific form of Requirements Engineering called Reverse Engineering or system archaeology.
Fortunately, it is not necessary to assign a big team of Cobol or PL/I programmers to go through the source code line by line in order to identify the functionality of the system. There are tools available that support the reverse engineering job.
We have experiences with a successful tool that can save up to 90% of the time that would be necessary to analyse the source code line by line.
The source code is imported into a so-called hypercube, from where the tool starts the automatic analysis of the code. First it compiles the source code and applies a high number of quality and quantity checks. For example, unused code and source code with errors are discovered and the number of file statements used in each program is deter-mined.
Different forms of data are extracted from the source code and entered into a vast number of tables where they can be selected and further analysed.
The tool also creates graphical representations of the source code that support the Requirements Engineer in his/her analysis of the system.
Some of the graphs and browsers the tool can produce are:
- Structure Browser
- Resource Browser
- Selected Call Graph
- Full Call Graph
As an Example, figure 2 shows part of a Structure Browser:
Figure 2: Structure Browser
Of course, the functionality is not extracted automatically into a readable format. The "real" work still has to be done by one or more Requirements Engineers who have technical skills as well as business skills of the system to be analysed. But no hardcore developers are needed for this task.
So, the job of post-documenting the legacy system is not as hard anymore as it seems.
5 Modernisation of the Legacy System
Modernising the legacy system can be done in various ways, one of them being, for ex-ample, to use the analysis tool described above to identify "dead code" and other weak points in the system and then to restructure it.
Of the three alternatives, the modernization is probably the cheapest, at least short-term. However, it has its drawbacks. The modernization options are limited as long as the system remains in an old programming language. It will always be much more costly to enter new insurance products in a system that is written in COBOL than entering them in a system that has been programmed with Java or C#.
So, the more often requirements (e.g. in the form of new insurance products) change, the less advisable it is to chose to modernize the legacy system.
However, there is one compromise you can consider: It is possible to automatically translate a system written in programming languages like COBOL into modern languages like Java or C#. But then you have a modern language still with the old and unflexible structure. That means a re-engineering project would be necessary to modernize the structure. So, here we are close to the third option - developing a new system, which means high costs.
6 Replacing the Legacy System by an Off-the-Shelf Product
If, considering the above analysis, the modernization of the legacy system is not the right option, then existing products should be considered that contain the same or at least similar functionality as the old system.
The advantage is that such a product has presumably been tried out at other clients and as such has gone through several application management cycles. So, it should have become stable over the years.
The problem with off-the-shelf-products is that their inherent processes very seldom fit the processes your business staff is used to. The differences have to be documented by first analyzing the system documentation provided by the product vendor. Afterwards, additional functionality needed by the customer and functionality that has to be changed in the product need to be identified by the requirements engineer using various requirements gathering techniques. With this documentation, fairly good cost estimates can be formed.
If the product has to be customized for the client a lot, then the costs will "explode". Also, higher costs of future product updates have to be taken into consideration.
Again, there is an option to be considered that weakens the disadvantage. Products with a modular architecture might help here. Similar to Lego bricks a system can be built that fits the needs of the customer. Well-known modular systems for insurance businesses are FirstGen for P&C insurers, FirstLife for Life insurers and FirstRe for Reinsurers.
7 Development of a New System
The presumably most expensive option is the development of a new system. However, it is the option that will have the best result for the customer, provided the software de-velopment project is done in a highly professional manner.
The main advantage is that all internal processes can be implemented identically in the new system. Also, the technology (e.g. programming language) can be chosen to fit the customer's technology strategy.
The key factor for a successful project is again and here more than ever professional Requirements Engineering. For this option, a complete specification of the whole sys-tem is necessary. The use case concept as a highly successful method is recom-mended here.
The risk of a failure of such a project is higher the bigger the project or the system to be developed is. There are mainly 3 strategies that can reduce that risk (apply all of them):
1. Use an agile development method (e.g. Essential Unified Process or SCRUM)
2. Try to split a big project in smaller projects
3. Assign the project to a well-trained and very experienced IT team
In order to remain competitive in the market, for example by a fast introduction of new insurance products, the legacy systems have to be modernized or replaced sooner or later. For this task, three alternatives were introduced with their advantages and disadvantages. All alternatives rely on a successful IT-Project.
In order to help them to succeed in time, budget, and scope, the professional application of different Requirements Engineering techniques are a key success factor.