“There is only one way to eat an elephant: one bite at a time.” Attributed to notables ranging from St. Francis of Assisi (whose elephant-related credentials are a bit suspect, tbh), to Desmond Tutu, the meaning is obvious: any task, no matter how challenging, can be tackled bit by bit. The reverse is equally true: when we try to do too much at once, disaster can happen.
Mainframe modernization is the elephant in the room. We need the systems that run on mainframes. But they’re so vast, complex, and interwoven, it can feel daunting—and dangerous—to approach the beast.
A Fancy Term for the Feast: “Complexity Partitioning”
Taking an iterative, piece-by-piece approach is the most efficient, lowest risk way to migrate systems. “Complexity partitioning” is the generic term for this strategy. Take a big problem. Break it into pieces. Solve the pieces. Integrate the solutions.
And just as there are many ways to carve an elephant, skin a cat, slice a melon, there are many ways to migrate a legacy system. What are the pieces? How do they relate? What will you discover upon integration?
This is how Mechanical Orchard approaches legacy applications: take a small piece, find out what it does and how it relates to the overall system, rewrite, test, and get it into production as soon as possible, then continually monitor it for equivalence and performance. Then take another piece. Rinse. Repeat. Eventually, all the pieces will be in place, working together in a new, more flexible environment with minimal disruption.
A Manageable Approach for Manageable Pieces
All well and good, you may say, but what about that in-between state, where some of the applications are on the mainframe and some are in the cloud? Data has to move back and forth, operations synced and progress tracked. Not the most comfortable place to be.
But here’s the thing: it’s never going to be comfortable. You run a business with decades of history. With all your systems, interfaces, people, experience, wisdom, and customers there is no way any of this is going to be simple or easy. It all comes down to choosing the complexity you wish to manage.
The Mechanical Orchard approach of moving applications one at a time pragmatically responds to that complexity. Rather than bury it and pretend it doesn’t exist, only to have it come roaring back when you least expect it, we would rather digest the complexity one bite at a time. If that puts us all in a bit of an awkward situation for a bit, that’s a small price to pay for the insurance of knowing that we aren’t ignoring anything important.
The Substance of Each Step
Here’s how a Mechanical Orchard legacy modernization project goes:
> Replicate first, innovate next: the running system IS the spec. We work with our customers to find a “spike”—a workflow that’s a candidate for pioneering the migration. Then we take one workflow, understand it, and replicate it in the cloud.
> Deliver incrementally, and continuously monitor, test, and validate. We ensure the replica in the cloud is performance and functionally equivalent, verifying this continuously.
> Maximize acceleration. The total feedback loop between code delivery and live production should be as short as possible; ideally, multiple times a day. This means a workflow can be migrated and working in weeks, not months.
We do this for each workflow, until everything has been migrated to the cloud and works well. Then, and only then, do we recommend decommissioning the mainframe. Elephant, digested!
Now you have a functionally- and performance-equivalent of your critical application in the cloud, where then you can take it wherever you’d like. That’s the power behind the flywheel of build-run-innovate-repeat.
There’s a lot more that goes into this, of course. In subsequent blogs, we’ll be diving deep into how each of our three phases of engagement works to minimize risk. Up first will be the Discovery Phase, an extremely low-investment, no-regrets way to gauge the biggest risk of all: is this migration even possible?