“A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness.”
– Alfred Korzybski

‍
There’s something deeply satisfying about a well-drawn map. It makes terra incognita navigable. It gives you a sense of the whole before you start traveling. And in mainframe modernization, Business Rules Extraction (BRE), the practice of using AI to surface the logic embedded in decades of legacy code, promises exactly that: a clear, readable map of what your system actually does before you touch a single line of it.

BRE delivers shared understanding. It helps business stakeholders reconnect with systems they long ago stopped being able to read. It auto-magically creates documentation that probably should have been written thirty years ago. It gives modernization teams a common language for what they’re working with. For those purposes, it’s fabulous.

But when the map gets mistaken for the territory — when BRE’s output is treated not just as a tool for understanding, but as a sufficient and complete specification for reimagining the new, modern system — then we have a problem.

As my colleague Sam Sanders wrote in a white paper, BRE reliably captures the logic layer, such as the conditions, calculations, and decisions that look like policy. But what it doesn’t capture is everything below that layer: say, the encoding rules that govern how a number is stored as bytes on disk, the runtime integration details, tacit “rules” that have accumulated, unremarked, over decades of production operation. To extend the Korzybski analogy, that “layer below” consists of the terrain: the elevation, the soil type, the seasonal flooding that the map’s similar (and not wrong) structure doesn’t convey.

So what? you might say. If I have a detailed map — that is, a complete extraction of my business logic, my process flows, my data models — I can hand that to an AI agent and forward-engineer an entirely new architecture. Reimagine from extracted business rules! Yay!

But think about what that actually means: constructing an entirely new system that is based on incomplete behavioral information, then discovering what it’s left out at the moment you need to cutover, when the cost of being wrong is at its absolute highest. All those details below the “rules” layer — the terrain, the territory — they don’t disappear, they jumpscare the heck out of you at the end. In fact, you’ve not only built a system you can’t confidently cut over to, you’re back to square one.

What’s the alternative? As it turns out, there is a way to produce a specification of the map and the territory. It’s — you guessed it — the running system, observed exhaustively under real conditions. Feed the same inputs to both the original and the emerging rewrite, compare outputs at every step, and you have something BRE alone cannot give you: a precise, executable harness that tells you, continuously, whether what you’ve built faithfully reproduces what you’re replacing.

This doesn’t make BRE redundant — the map is still valuable for understanding, communication, and planning. But the territory is what you verify against. And verification is what makes cutover something you can schedule with confidence, rather than walking in circles.

‍

News and Views

Speaking of why code isn’t the only issue at play here, Maryna Klo writes in Hacker Noon about Why Mainframe Modernization Keeps Failing at the Integration Layer. While the article bears Claude’s fingerprints, the ideas are worth thinking hard about: “Even when documentation and models are thorough, they can miss crucial dependencies or unrecognized processes that only become visible when something breaks in production.”

The banking industry has one of the highest concentrations of mainframe systems. Dharmesh Mistry discusses the challenge of this, not least that you can’t just bolt AI onto what you’ve been doing, in his engaging “Franken-core” series in FinTech Futures. Great insight: current incentives buy time, they don’t buy a future. Part one here.

‍

From the Orchard

For a more technical explanation with concrete examples of how Imogen complements BRE, read the white paper, Mainframe modernization is a verification problem, written by Sam Sanders. And Sam appears again (season of Sam!) in a Fed Gov Today show session titled, The Hidden Risk Hiding in Plain Sight - Ultra Legacy Systems.

For a fun yet edifying romp through what a coding rookie encountered on his way to mastering LLMs, read Jai Morjaria’s AI 201: Effective LLM usage beyond spicy autocomplete.

AI has radically decreased the time and cost of building software, which creates new problems. Over two days at a farm in Tennessee last month, we gathered a group of notable and curious minds to discuss how the economics of building good software will change. Read our reflections here.If you’re craving a bit of in-person time, our Unfinished Business series in partnership with Thoughtworks arrives in Dallas on July 16th. It will feature a panel discussion on exactly the territory this newsletter covers: why neither code transpilation nor business rules extraction closes the gap between understanding a system and proving the new one works. Drinks, canapes, and considerably more useful conversation than another webinar. Details and registration here.


Curious to learn more? Say hello@mechanical-orchard.com.‍

‍

—

View all newsletters here