The "legacy system" Achilles' heel of digital transformation

 

Faced with a "legacy system" that prevents movement, 

what to do? 

Companies that have made heavy investments in digital transformation programs often find that the slider of said transformation has not moved at the expected pace!

(Too) many answers have been developed historically with technologies that now belong to the past: legacy systems. And unfortunately the dependence on these technologies is strong, because these systems contain the data that companies need to make decisions today, and surely those of tomorrow!

More than ever, this strong dependence on legacy systems is one of the major obstacles in the path strewn with pitfalls of digital transformation. IT services are heavily involved with sometimes incompatible injunctions: movement towards Cloud platforms, simple replacement of dated application solutions with SaaS software, launch of major legacy modernization programs, etc.

All this while ensuring real continuity of service. Good luck !

Start by not rushing things.

Over the past 10 years, many legacy modernization programs have failed, and some major migration projects have delivered grossly underperforming solutions. It is often the companies that wanted to go too fast, or that sinned by pride. From a legacy system that they drag like a ball and chain, they end up finding themselves in the cloud with incomprehensible architectures, inflationary costs, and business that complains because it is not part of these procrastination. From a legacy system A, we move to a future legacy system B. Too bad!

Do not give in to fads. There had been a move towards ERP type packaged solutions some time ago, now we have the Cloud. But this can lead to real regressions.

If there is a risk of degrading the key functionalities of the company permanently or that these functionalities affect the key skills of the company, then it will be appropriate not to rush things, to take your time, to avoid at all price the “black boxes”.

Work tracks

1- A technical overlay

Completely replacing legacy systems is risky business. A European retail company that we know opted instead for a specific strategy: creating an envelope around the legacy system. These "wrappers" bring out the business logic that is implemented deep in the legacy systems by preserving the stability of the system, while breaking the uniformity of the system in place. Streaming technologies, such as Kafka, Spark or Kinesis, etc., make it possible to implement this intelligent “wrapping”. This model has typically allowed many companies to reuse logic from their mainframes, without undertaking costly decommissioning programs.

2- Map your legacy system, and know the "hot", "cold" areas

It is very important to be aware of the technological heritage that has developed incrementally over the years. To do this, the best method will be to map the IS technically by defining the origins of the information, what it is used for, who it is used for. Areas of over-use and under-use of the IS must be identified to enable work sites to be prioritized. With this "map" in hand, the teams have the mastery on the flows in the systems, their interactions with the application systems, their importance. Upgrading the systems, or downright decommissioning them will be infinitely simpler. Especially if this mapping is delivered continuously.

3- The "Dead matter" in a legacy system

Legacy systems carry “dead matter”. Typically flows that were created for applications that are no longer used, or for people who are no longer around. It will be valuable to consider “unplugging” the solutions that are no longer used.

The data that is actually used has an imprint in the audit databases. By going through all the flows making it possible to produce this data used by business people in parallel, a mechanical distinction is made between the components of the systems which are useful and those which are not.

The technical teams will have the opportunity to delete or archive the "dead matter" in continuous time. We can thus bring the system to its proper measure in a reasonable time, without operating a revolution.

Furthermore, the "useful" processing is entangled in the overall kinematics. It may be wise to massively reduce the number of processing operations by automatically generating “set-oriented” code that will factorize everything that can be factorized (especially the cursors in the procedural code). We will thus bring the system to its optimum, with in addition a facilitated understanding of the processing of the data.

4- Rely on the business, a “top down” logic.

Instead of spending energy to completely revolutionize a legacy system, it is sometimes better to invest resources in obtaining an exploitable result by the business that can quickly develop new "business insights".

This will create a powerful "top-down" transformation engine, which will allow a pragmatic evolution of the IS with the idea of creating business. It's more seducting. The team that will work on this project must include collaborators who know the legacy system perfectly, because the new solutions will use the business logic already present for a long time.

Conclusion

The evolution of information systems, and therefore the modernization of legacy is not an option: international competition imposes on companies an ever finer reading of their business, and directs them towards “data driven” strategies.

How in this context to dispose of its legacy system, so cumbersome, but so useful. How to modernize it, then migrate to the clouds as most companies want. Adding a technical layer can do the job, it's a real option. It seems essential to map your IS to simplify it better. Above all, it will be necessary to rely on the business lines, giving priority to taking into account their current and future needs so as not to create a break in load.

#cloudmigration  #legacysystem #Itdebt

www.ellipsys-bi.com