The Unbundling of the Enterprise ERP

Why the monolith won in the first place

The case for the single enterprise system was never that it was good at any particular job. It was that integration was ruinous. Getting two pieces of software to agree about a customer, an invoice or a stock level meant bespoke work, a permanent maintenance burden, and a class of failure — the two systems silently disagreeing — that is worse than either being wrong on its own.

Faced with that, buying one system that did everything adequately beat buying five that each did one thing well. The adequacy was the price of coherence.

What you bought with it, though, was a model of your business written by somebody who had never seen it. Every enterprise system encodes assumptions — about what an order is, what a customer is, how a discount works — and the further your operation sits from those assumptions, the more of your budget goes on configuration, customisation, and eventually on changing how you work to suit the software.

Adequacy was the price of coherence. What you bought with it was a model of your business written by somebody who had never seen it.

What changed

Three things, none of them dramatic on its own.

Integration stopped being bespoke. An interface between two systems used to be a project; it is now, for well-built software, a matter of days. The cost that made the monolith rational has fallen by an order of magnitude.

Infrastructure stopped being a capital decision. Running a system used to mean buying servers, which meant consolidating systems to justify them. Now a system that serves a single department costs what it costs to run, and can be discontinued without stranding hardware.

And the cost of building something specific fell far enough that a vertical — hotels, clinics, logistics, restaurants — became a market worth serving on its own. Not a configuration of a general system, but software that assumes you are a hotel from the first screen.

The vertical operating system

What replaces the monolith is not a pile of disconnected apps. It is a smaller number of systems that each understand one domain deeply, agree about the few things they must agree about, and are honest about the boundary between them.

Take a hotel group. The old answer is a property management system that also handles the restaurant, the payroll, the purchasing and the accounts, badly, because it is a hotel system with modules attached. The new answer is a booking and inventory system that is genuinely excellent at rooms and rates, a restaurant system that is genuinely excellent at a busy floor, and an accounting system that is nobody's idea of exciting and works perfectly — with clean interfaces between them.

The crucial discipline is deciding what has to be shared and refusing to share the rest. A guest identity has to be shared. A booking has to be shared with the accounts. The restaurant's table-turn logic does not have to be shared with anybody, and the moment you try, you have rebuilt the monolith with extra steps.

Where this goes wrong

Unbundling has a failure mode, and it is not theoretical. It is the company with eleven subscriptions, four of which hold a partial copy of the customer list, and nobody able to say which one is right.

The discipline that prevents it is deciding, deliberately and in writing, which system owns each piece of information. One system owns the guest. One owns the booking. Everything else reads. When two systems both believe they own something, the disagreement is not a bug to be fixed — it is a design decision nobody made.

The second failure is subtler. A bundle of specialist tools can leave nobody responsible for the whole. The vendor of each part is happy; the business cannot get a straight answer about why the numbers do not match. Somebody has to own the seams, and if it is not an internal person it has to be contracted for explicitly.

When two systems both believe they own something, the disagreement is not a bug. It is a design decision nobody made.

What this means if you are buying

Stop asking which system does the most. Ask which system does the thing that is hardest for you, and then ask what it refuses to do and how cleanly it hands that off.

Be suspicious of any product whose demonstration covers eight departments. Breadth in a demonstration is almost always depth borrowed from somewhere, and the somewhere is usually the part you care about.

And insist on being able to get your data out, in a usable form, without asking permission. That single contractual line is what makes an unbundled estate survivable, because it means any one component can be replaced without replacing the rest. It is also the line most often missing.