High risk, low reward

‍

“When it comes to moving off mainframes, CIOs and CTOs at many of the world’s largest organizations simply don’t want to entertain the idea of a failed transition on their watch.”

‍

Rob Mee’s quote captures the conundrum of legacy modernization. What’s behind the reluctance to take action, despite legacy’s drag on productivity? For one, it’s thankless: success might get a pat on the head, but failure can deliver a pink slip and some “time with the family.”  This lopsided risk/reward equation—the “risk asymmetry”—makes even the most talented leaders hesitant to take on a modernization project.

‍

But more fundamentally, legacy modernization is hard, risky, and takes a long time—longer than the average CIO tenure. Results emerge only after years of effort—and oftentimes not at all. Despite a persistent belief in long-term planning, most large IT transformation projects contain more surprises and quirks than a Choose Your Own Adventure book.

‍

The roots of failure

The best way to redress risks is to understand failure patterns. Mechanical Orchard has spoken with hundreds of people in Global 2000 corporations who have wrestled with legacy modernization. Here are the top failure modes we’ve documented.

‍

Surrendering to the kitchen sink

It’s natural to think of migrating IT systems as remodeling a house: if you’re going to move a wall, you might as well upgrade the wiring. And while we’re at it, let’s add a bathroom. But unlike buildings, IT systems are dynamic, in motion, and running critical processes. Introducing new feature requirements compounds an already complex process and massively reduces the odds of success. 

‍

A common story: it has been three years since the start of a multi-million dollar “digital transformation” project, launched with much fanfare. And there is absolutely nothing to show for it. 

‍

Underrating institutional knowledge 

Most modernization efforts, especially for mainframes, begin with translating old code into new code. But the code was written 30, 40, even 50 years ago to support the business needs at that time.

‍

In the meantime, only a handful of people are familiar with all the workarounds and adaptations that have evolved to support successive waves of business needs. Another handful of people might know about an unrelated team using an obscure database as a core part of their workflow. And these people are retiring.

‍

Neglecting the users 

Many legacy systems have defined how a company operates for a generation or longer. It’s nearly impossible to understand all the touchpoints and integrations between systems—and between systems and the humans who use them.

‍

But what remains true is that end users and customers are the ultimate stakeholders of technology systems. Change their everyday rhythm inadvertently—or worse, offer them an “improved experience” without consulting with them first—and you are rolling back your big launch (and might owe a hefty fine for the privilege).

‍

Safety first: the 3 principles of risk management

Could there be a different approach—one that is built around the principle of low-risk change—that seeks to change these failure patterns, and instead forges new disciplines that tame the problem?

‍

We believe there is, and it follows three principles:

‍

1: Minimize entropy

Though the concept of IT digital transformation is treated as a “change everything” ethos, it doesn’t have to mean changing more than one thing at the same time.

‍

During legacy modernization, the temptation is strong to add new functionality, fix bugs, and improve the interface. But that is inherently risky: there’s no way to track success when you’re changing the game while playing it.

‍

Put another way: adding entropy to what is already a complex system, one that users are used to, is not ideal. It is safer to reproduce exactly the existing behavior first, warts and all, and only then go on to change and improve behavior. This takes discipline and resolve.

‍

2: Data speaks louder than code

Most people tend to think of new code as being the center of the modernization effort. A complex legacy migration usually starts by analyzing the existing code, interviewing users and subject matter experts, reading old documentation, and building up a full picture of requirements. 

‍

From this comprehensive new specification the engineer can begin the work of rewriting the system. The risk comes from the hubris of presuming that the requirements and implementation are so precisely correct that there is no danger to the critical production data flows. 

‍

Safer to flip the thinking on its head: start with the data flows. Success results when the effect on data of the existing and the new system—their behaviors— are indistinguishable to the end users.

‍

3: Prove it as you go

Attempting to wholesale replace a legacy system with a new one spikes the risk needle. There are too many assumptions, unsolved last-mile problems, forgotten dependent systems: the combinations explode and the unknown unknowns scuttle the effort. 

‍

Instead, it is safer to create an incremental cycle: build only a small subcomponent at a time, and then do the work to run it alongside the existing system. The safety comes from taking on a series of small risks, each of which can be controlled and rolled back, rather than building up to an all-or-nothing moment. This gradual and relentless accretion of small successes also builds the political capital so necessary to socializing change.

‍

Relative rewards

Taken together, these disciplines lead to the conclusion that we are in need of a new kind of skill, one built around safety and provable progress. We must foster and hone a new competency of well-substantiated confidence. The successful organization creates a point of focus, sometimes called a “modernization factory”, that embraces a safety-first culture designed to minimize risk.

‍

It’s expensive to be unsafe, whether we’re talking about time, money or careers. Tackling the risk head on with humility leads us to new thinking and a fresh approach to what has been—until now—intractable.