Legacy Modernisation - Too Slow for Digital Demands?

Ostia blog legacy Tech

In relation to this article, I believe the answer to this is a firm ‘yes’, however, the article seems very much committed to throwing the baby out with the bathwater implying the only way to address this is to throw away the mainframe legacy applications. This is too simplistic and requires a more measured approach.

We need to remember that these machines and applications have served the businesses and their customers well over the past decade.

The applications may be written in COBOL but they are tried, tested and have served the business for many years. It is true that your average Java programmer could potentially emulate the logic in each COBOL application, however, what about..

    • ..the years of testing?
    • ..the other processes that have been built around the COBOL application?
    • ..the control, audit and security built up around these applications over the decades?
    • ..the backups and disaster recovery?

The cost of replacing a COBOL application with a new technology is far higher than just the refactoring of the code into some new language.

Winning Evolutionary Approach

The bottom line is that quicker wins will be made by reusing the existing infrastructure as much as possible. By adopting an evolutionary approach one can build out services reusing the existing infrastructure which are just as agile as any new code will be yet retains all the attributes built up around the legacy application. So why hasn’t this happened?

There is a second answer to this question which relates to the tools that are used for modernisation approaches.

Agile Delivery

These ‘legacy tools’ were built to run inside the firewall and thus do not play well in our new digital world. The processes built up around these tools also create a very secure and safe approach but result in requests to access data or business logic on the legacy system taking months or years.

With the digital revolution, you can be sure that the requirement will have moved out of sight by the time the integration is delivered. These organisations must adopt new tools designed for the digital age to augment their traditional integration stacks and give them an agile way to deliver component services.

Is your organisation stuck in the past?

There is a fear factor around these legacy systems that if anything is installed or changed, they may crash causing enormous loses.

The local ‘jobsworths’ simply will not countenance innovation as it risks the cosy lives they have built up around protecting ‘their’ mainframes from harm. Ultimately this is acceptable to run the business; however, it is preventing the business from moving into the 21st century.

A decision must be taken to move on from this point and look at new alternatives while weighing up the risks correctly. It is always possible to manage risk and this must be done to enable these legacy environments to become an agile part of the infrastructure to deliver what the digital business needs.

The article above comments on the following piece:

http://www.zdnet.com/article/legacy-modernization-approaches-too-slow-for-digital-demands/

 

Learn more about our services

Download your free whitepaper - Transforming your IT Systems

Gravatar
Michael Brice
The referenced article starts with the phrase "Legacy is a continuing problem for all of IT." which is stating the bleeding obvious. The rest of the article repeats a number of well known and understood issues and simply concludes that there is no quick fix and we have to spend a lot of money and time to move forward. Not a lot of original thought here I would suggest.

Any application system by definition is a legacy system, or soon will be. The characteristics that make a legacy system a risk, is poor design, not the age of the system, nor the technology used to implement it. The concepts of structured programming have been known for a long time. In my opinion it is the failure to follow good practise in the design and build of an application system that is the major risk factor going forward.

The methodologies that are in use to support the design and build process have evolved and morphed around a small number of common sense principles. Whether you call it 'Agile development' or 'Rapid Application Development' is for the marketing types to play games with. The basic principle is to define and deliver small components with as much user involvement as is possible.

These components need to be modular, with standard interfaces to maximise opportunities for reuse. If the legacy system has not been designed and built with these characteristics, then the first order of business must be to identify and rework the core business components in the application system(s) of interest. I would suggest that there are few organisations that have the resources, and the skills, to start again with a 'clean piece of paper'. Evolution needs to be based upon reworking the key/core business components so that they are future proofed. This activity should be undertaken with the understanding that the underlying business data is probably the most valuable resource, not the business application.

Being able to respond in the Digital world, whatever that means, is in my simplistic view, the ability to reuse existing business components, build additional business components, with a new User interface or experience that can be reworked and/or replaced quickly. If the design of the underlying business components is sound, then the user experience can be enriched easily as new technology options present themselves.

Detect location

2500 Characters left