Businesses Shouldn’t Have to Run to Stay in Place

Businesses spend a lot of money staying exactly where they are.

Take an ordinary modernization project. You migrate a database, replace an old framework, and rewrite a few services. After months of planning, implementation, testing, and surprises, the same reports run, the same approvals work, and the same invoices get sent.

I find this strange.

Some modernization gives a business new capabilities. But the familiar kind is defensive: the old software is becoming insecure, unsupported, too expensive, or impossible to hire for. The business works hard and pays a lot to avoid moving backward. It has to run to stay in place.

I was discussing this recently with Sam Rose, who has built information systems in telecommunications, healthcare, and other complicated domains. He said that if you already have a good software solution, you should be able to keep using it instead of continually building more software around it.

The awkward question is: what exactly are we trying to keep? Usually, we preserve the software even though the business decision encoded in it was the thing that mattered.

The six handoffs

A business system often begins with a decision.

Someone decides that certain customers require an additional review, that a supplier must meet a new condition, or that an invoice above a threshold needs another approval. From there, the decision typically travels through something like this:

Those are six handoffs. Every handoff translates the original meaning into a different language.

The meeting turns the decision into a shared understanding (hopefully). The ticket compresses it into a unit of work. The specification tries to remove ambiguity. The code turns it into control flow, data structures, and calls to other software. Deployment fits it into an operational environment. Maintenance inherits whatever survived.

Some loss is unavoidable. A precise implementation cannot preserve every bit of context that existed in the decision. But we rarely make the loss explicit. By the time the system is running, the business requirement is scattered across code, database schemas, configuration, tests, tickets, and the memories of the people who were there.

Later, somebody asks:

Why can’t we do it this other way?

And the answer is no longer about the business. The framework does not support it. The schema makes it difficult. That service belongs to another team. The workflow cannot be changed while instances are running. The vendor API does not expose what we need.

The implementation has become the requirement.

Software starts aging immediately

We use legacy as an insult for old software. New software gets a grace period during which it is clean, modern, and full of potential. But it starts aging as soon as a business depends on it. From then on, somebody must understand, operate, secure, upgrade, integrate, and eventually replace it.

Good software is not exempt. In fact, the better it works, the more important it becomes and the more expensive it may be to remove.

Companies often describe a large bespoke software stack as an asset. It contains years of engineering effort, so surely it must be valuable. Sometimes it is. But if that software mainly translates rules the business already knows, and needs continuous work just to preserve those rules, part of the “asset” is a liability with a source repository.

The business knowledge and the program are not the same thing. Yet most systems preserve the former only as the latter.

Maybe being behind is not the problem

Sam told me that earlier in his career he repeatedly encountered businesses whose software appeared to be many years behind what the industry could build. The usual diagnosis is that they need to modernize. During our conversation, he asked a more interesting question: perhaps some of them should be behind.

Clearly, this is not an excuse to run insecure or failing systems. But a successful manufacturer, hospital, insurer, or telecommunications company does not exist to demonstrate the current state of software development. If its operating model works, why should it reorganize itself around every new generation of software?

The goal should be to benefit from faster hardware, better reliability, stronger security, and lower operating costs without turning every advance into a rewrite of the business.

Change for the right reason

Business rules change. “Business rules never change” would be a convenient foundation for this argument, but it would also be false.

Prices change. Regulations change. Agreements change. A company learns that its approval process is too conservative, or not conservative enough. It enters a new market. It changes what it sells and how it sells it.

Those changes happen for business reasons. Operating systems, frameworks, databases, cloud services, deployment practices, and hardware change for other reasons. Trouble starts when the two are fused. A framework upgrade should not require us to rediscover why an approval exists, and changing an approval should not require us to redesign the machinery around it.

The same applies to user interfaces. Suppose the requirement is that somebody reviews evidence and approves a decision. Does the business really require a table, a dialog, and a button? Usually it does not. Those are choices made for a particular interface.

We have been experimenting with describing the interaction at a higher level: its purpose, intent, and affordances (what a person can do). From that description we can project an interface for a desktop, phone, watch, voice, Braille, or an editable PDF. It can happen in real time and account for the platform, modality, and individual preferences without specifying the business interaction all over again.

What mainframes got right

Mainframe designers dealt with a similar problem. IBM still builds IBM i around a Technology-Independent Machine Interface (TIMI). Applications are compiled into an intermediate representation that can be translated for the hardware underneath, allowing existing programs to survive processor changes without being rewritten. This overview explains how TIMI works.

No, I am not proposing that we write everything in COBOL. I am interested in the boundary. Could the rules, constraints, relationships, and implications in a business system survive a change in the software that evaluates them?

Instead of compiling business meaning all the way down into one bespoke application, we can keep that meaning in a form the business can inspect. The software underneath becomes an interpreter, an optimizer, or, loosely speaking, a virtual machine for the operational model.

The runtime will still age. But replacing it does not have to mean reconstructing the business from its remains.

Give software an expiration date

Imagine that every piece of software is required by law to expire after five years. On the expiration date, you must delete it and replace it with a different implementation. You can keep your data, but you cannot keep the program.

How would you build a business system under that constraint?

You would probably make its data portable. But data is not enough. A table can tell you that an approval happened; it rarely tells you the complete policy that required the approval, the evidence considered, the exceptions in force, and why this outcome followed.

You would need to preserve more than rows and files:

What exists in the business, and how is it related?
Which facts came from where, and which sources have authority?
Which rules and constraints apply?
Why did a particular decision happen?

That should be enough to build another implementation and verify that it still does what the business intended. Five years is arbitrary, but software already expires. It just does so gradually, unpredictably, and without the courtesy of putting a date on the package.

What should become software?

Obviously, doing this still requires software. I write an unreasonable amount of it, so it would be a little awkward to argue that we should stop.

Databases, operating systems, compilers, storage engines, solvers, and network protocols are software. They are foundational machinery, and improving that machinery can benefit many systems at once. Some business capabilities are also genuinely novel algorithms whose implementation is a large part of their value.

The issue is what we make inseparable from a particular implementation.

An invoice approval threshold is not more valuable because it lives inside a TypeScript service. A supplier policy is not more precise because it is spread across a workflow definition and three database queries. Those are implementation choices, not business meaning.

At Inferal, we call the durable expression of that meaning an operational model. It connects current facts to the entities, relationships, rules, constraints, and implications that make them operationally relevant. Ontologies preserve what the terms mean, provenance preserves where the claims came from, and an engine determines what follows.

When the business changes a policy, it changes the model. When technology moves, we should be able to replace the engine underneath it. Neither task is automatic, but at least they are separate tasks.

I do not expect to make software immortal. I would rather design as if it will die, and make sure the business does not have to be reconstructed when it does.