Modernizing something means changing it so it’s more up to date. It’s a neat twist that―in the context of IT systems―we now need to rethink what we mean by modernization, and how and why we execute it. Because it no longer means what many people always assumed it did.

Back against the wall

Allow me to explain. Up until a few years ago, if you asked a company why it was looking to modernize its systems, you could be fairly sure what you would hear in response. It would be something about moving applications off the mainframe to somewhere else, in order to get lower costs or address a technology sunset problem.

That sunset might be any number of things: a no-longer supported language, an out-of-date system, a piece of kit that had to be retired. But the fact was the business’s back was against the wall, and it had no option but to modernize its legacy―despite the fact that doing so would create minimal business value.

True, there might be some OpEx savings as a result. But these were expensive, time-consuming projects that essentially involved a like-for-like migration into the target environment. And they often delivered little in terms of new business capabilities. In fact, making changes along the way could significantly complicate the modernization project, and was actively discouraged.

A different world

This back-against-the wall view of modernization has persisted, despite the fact that the IT landscape has changed beyond recognition. The challenge today for many well-established companies is that they’re operating in an entirely new digital era, but still have monolithic legacy systems. Whether package or custom, these systems were created for a different world and often remain at the core of the enterprise.

When these systems were built, few imagined the amount of flexibility that would be required in the digital era. Nor did they foresee that there’d be a need to combine their functions and features with other systems to create composite applications.

But in the digital era, these things are precisely what systems need to be able to do. The result? An increasingly urgent need for more agility in legacy systems and higher velocity in delivering software. Which means we must redefine what’s meant by modernization―because a like-for-like migration won’t help.

Decomposing the legacy

One option that’s often suggested is wholesale rebuilding. But rewriting a system with 30 million lines of code―even with all the advances of Low-Code/No-Code environments and automated migration tools―is an enormous undertaking.

So companies are embracing other techniques. Foremost among these is “service decomposition.” This means breaking the legacy application into components that can be more easily maintained and developed independently. The next step is exposing these components using APIs, often as containerized microservices.

This is an increasingly popular form of modernization―but not in the traditional sense of the word. Rather than moving systems to another platform to avoid an impending sunset or achieve cost reduction, it means opening them up to extend their useful life. We do this by enabling them to interact with the digital era in a way that’s scalable, efficient and is able to keep pace with the expectations of the business. In fact, this opens up thinking to a completely different business case looking at both top-line growth and cost savings.

<<< Start >>>

<<< End >>>

The power of components

This is a very different value proposition―and one that involves looking at legacy systems in a very different light. Rather than waiting for the point where they’re no longer meeting business needs and need to be replaced, it means taking a proactive decision to break them into discrete parts. These parts can then be used in much more creative ways in the digital ecosystem.

What does this mean in practice? Take a utility’s legacy customer care system, which may have other elements shoehorned into it like billing, meter reading and collections. If the company breaks those macro components into more discrete and atomic services, it could end up with one that just deals with customer maintenance, another with meter reading analysis, another with invoicing and billing, and so on.

Having separated out the components, it becomes possible to combine them in different ways. So, if the utility previously had one customer care and billing system for electricity customers and another for gas customers, it can now pull these together and offer new propositions such as a common API for customer information, even if there are two different systems. Decomposition also unlocks new capabilities. If the utility wants to get into new business areas like selling insurance against electrical storms, it can now do this by hooking up its components to different front-ends rather than building an entirely new system. This is sophisticated and complex work. The degree of skills and expertise required is significant. However, the investment around it has paid significant dividends for Accenture’s clients as they leverage interchangeable parts across a vast array of systems in their enterprise.

<<< Start >>>

<<< End >>>

Turning legacy to advantage

Across many industries, I’m seeing forward-thinking companies apply this kind of ingenuity and creativity to turn their legacy systems into a positive asset. This enables them to compete with start-ups and new competitors in ways they could never have imagined. And it all comes down to embracing new thinking and techniques around modernization. Combining that with the latest in Agile software development methods and DevSecOps automation.

So, consider this question. Given the advent of the digital era, isn’t it time your business updated its thinking around the modernization of legacy systems? If you look at the potential benefits, the answer is probably yes.

Adam Burden

Chief Software Engineer, Accenture

Subscription Center
Subscribe to Software Engineering Blog Subscribe to Software Engineering Blog