Take inventory management. One system keeps track of how much coffee, tea, and milk are left in the office and sends a notification when it’s time to reorder. Another controls the supply of parts to a production line. There, the right part has to be at the line within takt time. And the system has to keep running even when the connection to the MES (Manufacturing Execution System) or warehouse temporarily goes down.
Both systems manage inventory. It’s obvious they need completely different designs.
Function Is Not Enough
Yet this is where architecture discussions often go wrong. We classify systems by what they do: an inventory system, a CRM, a planning system. And once two systems have the same label, we quickly assume they need the same technical solution.
But a function only tells you what a system does. How it needs to do it depends on the environment in which it operates. If an office order takes a day longer to process, nobody really cares. If a part doesn’t reach the production line on time, the line stops. One hour of downtime can cost more than the entire office system ever did.
The Same System, a Different World
I saw this firsthand with a financial advisory system. It was originally built as a tool for advisors: first for internal employees, and later for partners as well. When the client started offering the system directly on its own website, to anyone who wanted to use it, they came to us.
Nothing about the system itself had changed. The calculations were still perfectly sound. Yet the system started struggling.
The trained advisors had been replaced by users with no training. They made more mistakes and used the system differently than intended. There were far more of them, and they used it at night and on weekends. The system was in danger of collapsing under the weight of its own success.
First, we kept the existing system running:
- fixed security issues;
- rewrote the heaviest calculations in the database;
- actively managed capacity: scaling up where necessary and scaling down where possible to reduce costs;
- monitored production for 18 hours a day with our teams in Vietnam and the Netherlands;
- set up an acceptance environment to reproduce and resolve problem cases without affecting production.
At the same time, we worked with the client on a step-by-step plan to regain control. The client could keep moving, and end users never noticed a thing.
The system was still doing exactly what it had always done. The only thing that had changed was the context—and nobody had gone back to ask the questions that the new context required.
Quality Requirements: Well Known, Rarely Specific
Those questions are about quality requirements, or non-functionals: availability, latency, consistency, recoverability, integration. ISO 25010 lays them out neatly. So these concepts are hardly unknown.
The problem is that they often end up written down as "the system must be fast and reliable." No number, no context, no consequences. A requirement like that could apply to any system, which means it doesn't actually drive the design.
My work starts with a statement like: "No more than 30 seconds of downtime" and "without stopping the production line." Now you know what you need to build. And just as importantly, what you don't need to build.
The Difference Is What’s at Stake
The office system can make trade-offs. A standard cloud platform, a simple database, and a basic interface are perfectly fine. If it goes down for an hour, someone drinks tea instead of coffee.
The production system has to be designed for failure. What happens when the connection to the machine goes down? Can the line continue using the last known inventory level, or does it have to stop? How do you recover from an outage without creating duplicate or missing transactions (idempotency)? How do you know something is going wrong before the operator does?
These aren't implementation details. They're design decisions, and they cost money. That money is well spent when the consequences of failure are significant. When they're not, it's money wasted.
The Questions I Ask
Good design starts with the reality in which the system has to operate. These are the questions I ask before technology choices enter the conversation:
- Users — Who uses the system, with what level of expertise, and when?
- Availability — What happens if the system is unavailable for a minute? And for an hour?
- Cost of downtime — What does an hour of downtime cost, and who bears that cost?
- Volume — How many users, transactions, or events do we need to handle, including during peak periods?
- Latency — How quickly does a change need to become visible, and to whom?
- Integration — What happens if a connection to another system goes down?
- Impact of errors — What happens if the system makes the wrong decision?
Only once you have answers to those questions—with numbers—can you determine which architecture fits. And when the context changes, you ask them all over again.
With an AI assistant, you can have a working inventory system up and running in an afternoon. But when you're vibecoding, those are still questions AI won't (yet) ask you.
Standardize on Criticality, Not Function
Standardization is valuable. It reduces complexity, simplifies operations, and saves time and money. I'm all for it.
The risk lies in a question I hear regularly: "We already have an inventory system. Why don't we just use that one here?" Or, as with the advisory system: "It already works, doesn't it? Just put it online."
It's a reasonable question. But the fact that a system already supports a particular function doesn't prove that it's suitable for every context in which that function is needed. If you standardize based on function, you impose the compromises of the office system on the production system. Or the other way around: you impose the cost of the production system on the office system.
That's why I prefer to classify systems by what's at stake—for example, into three criticality classes. For each class, you standardize the platform, monitoring, recovery procedures, and depth of testing. Two systems in the same class can share a platform perfectly well, regardless of what they do. Two inventory systems in different classes usually shouldn't.
Context First
In short:
A system can keep doing exactly what it has always done and still no longer be capable of doing what is required.
Not sure whether an existing system fits the context in which you want to use it? Or planning a standardization effort? Let's talk. Over a cup of coffee, of course.
