A legacy conversation
“I’m sorry, what was that language?”
“…right, and we have mission-critical services written in this?”
That’s how a conversation between an unfortunate service owner and their CIO might start as they rediscover that there is yet another piece of proprietary technology embedded deep within the organization’s IT estate. The service owner complains that the position the legacy technology holds is due to persistent underinvestment. The CIO counters that we can’t possibly continue to run essential services on such an unknown technology – is it even supported?
The rule of the monolith
This, or similar reactions, is something we often encounter when talking with our clients. They have services that are crucial to the continuation of the business built on a platform that is creaking, or skills that are waning fast. Users of any legacy technology must face the one indisputable fact that, at some point, they will have to do something with this technology.
The IT monoliths of yesterday are not necessarily the wrong answer. They perform their designated functions very nicely. They are stable, well-behaved, and finely tuned. And if you have a static business model, that might be fine. But I doubt that you do, or that it is.
Today, organizations no longer need monolithic IT services that live in the background. Organizations want to unlock the potential of the data while users are demanding easy-to-use interfaces, up-to-date information, and regular (if not constant) feedback on business transactions. With the incessant drive to deliver more and more business services through digital channels and drive down IT costs by moving to open source and migrating services to the cloud, organizations with investments in products such as CA Gen are finding it difficult to respond to customers’ needs.
The best strategy is not necessarily the first…
…Or even the sixth. Consider the six Rs commonly referenced around application migration and transformation:
Retire – if your organization can do without the service.
Retain – might be an option when you know the service has a defined lifetime, or if a decision simply cannot be made immediately. However, procrastinating is rarely profitable.
Repurchase – replace the application with something you can buy off the shelf. If 20 years ago someone created a standard accounting package from scratch, this could be an answer, but if that legacy service, with all its imbedded business rules, has survived till now, it is unlikely.
Rehost – moving that beloved monolithic legacy application to some new infrastructure, rehosting is sometimes part of the answer to buy time for a more complete solution and it may address some technical debt around the infrastructure, but that’s all.
Replatform – once you have found a new platform to rehost that legacy Cobol mainframe application you will have a nice new platform with a legacy Cobol application deployed on it. Some more technical debt may have been addressed, but other issues remain.
Rebuild – is sometimes the answer. This can give organizations the opportunity to move to agile development, change processes, and shift to a modern language drawing in fresh talent. New ways of working can be established and the rebuilt application can address the current business need. If the business requirement documentation is up to date, it can deliver a unique, bespoke system for users.
However, significant investment has usually been made in these legacy services, in building business rules, for example, investment over many years, even decades, could have been made by individuals who are likely to have left the organization by now. Such systems are typically not easy to replace but also cannot be expected to run seamlessly without a future strategy in place to de-risk their ongoing use.
The seventh R
If the recalcitrant legacy application is still doing the right thing, there is a step back from Rebuild that is Rewrite – replace the existing application with something in a new language, mapping the code statement for statement. This approach should guarantee an identical application, with all the business rules intact, regardless of any actual understanding of the business. In practice, this approach has variable success, particularly if there is an incomplete understanding of the original requirement or intent within the code; subtleties may be misinterpreted and coverage may not be complete.
Which brings us to the seventh R: Automation*
The use of automation to convert a legacy application is inherently lower risk. Coverage should be complete and the application conversion process it vastly simplified and shortened. The automated output must be usable and maintainable by the organization for future changes so care is needed in choosing the right solution. But automating the conversion allows an organization to concentrate on other aspects of their IT service management that will help them move from that legacy position, such as moving to DevOps and deploying the application onto a cloud platform – all of which help the business of organization become more agile.
*which you could argue was Robotics
The necessary caveat
Legacy modernization should never really be considered in isolation. Often, the problem application (e.g., written in CA Gen) is one aspect that organizations find difficult to incorporate into the implementation of a strategy or roadmap. In our experience, the migration or replacement of applications needs to be part of, and in support of a wider strategy of application modernization, operational streamlining, or business change rather than an isolated technical exercise to replicate an existing application in different technologies.
To learn more about how Capgemini can help with legacy transformation, or with managing your CA Gen applications through our REGENRATE offering, connect with me.