The most useful hour I spend with a new leadership team is usually the one where I make them disagree in public. I draw two axes on a whiteboard, ask everyone to put a dot where they think the company sits, and wait. The dots never cluster. The CFO’s dot and the divisional MD’s dot are always in different quadrants, and the argument that follows is the actual work. The framework doing that work is the operating model, from Ross, Weill and Robertson’s Enterprise Architecture As Strategy — a 2006 book whose case studies are period pieces but whose diagnostic I still reach for most weeks.
This is the explainer I wish existed separately from the book, because someone searching “what are the four operating models” on a Sunday night wants a definition they can use in a meeting on Monday, not a verdict on a twenty-year-old management title. So: here are the four, the two axes that generate them, a company you’ll recognise for each, and — the part practitioners actually need — what each one implies for where the IT money should go.
The two axes
Everything comes from two questions, and both are about business process, not technology.
Standardisation — do our business units run the same processes the same way, or does each one do it differently? Do a customer order, a hire, or a month-end close look identical across divisions, or does each division have its own?
Integration — do our business units share data and hand work to each other in real time, or do they operate at arm’s length? When one unit serves a customer, does the next unit see it?
These are genuinely independent. You can be highly standardised and barely integrated (every branch identical, none of them talking to each other). You can be highly integrated and barely standardised (divisions sharing one customer record but each doing its own thing with it). Cross them and you get four quadrants. The whole trick of the model is that these two things, which most people bundle together as “how joined-up are we”, pull in different directions and cost money in different places.
Diversification — low standardisation, low integration
The holding-company quadrant. Independent businesses under one owner, sharing little beyond a balance sheet and a logo. Think of a diversified conglomerate whose insurance arm, rail arm and confectionery arm have nothing operational in common — the centre allocates capital and otherwise stays out of the way.
What it implies for IT: keep it thin and keep it local. The value the centre adds is financial, not operational, so shared IT should stop at the things where scale genuinely lowers cost with no strings attached — procurement leverage, payroll, maybe a corporate network. Everything else stays with the divisions, because forcing a shared platform onto units that don’t share customers or processes is how central IT earns its reputation as a tax. The failure mode here is a centre that mistakes ownership for synergy and builds a group-wide system nobody asked for.
Coordination — low standardisation, high integration
Shared customers, different processes. Divisions that need a single view of the same customer, account or product, but run their own operations to serve it. A retail-plus-wealth-plus-corporate bank is the classic: the same person is a current-account holder, a mortgage borrower and a business owner, and each division wants to see the whole relationship — but nobody sensibly argues that retail and corporate lending should run identical processes.
What it implies for IT: spend on the data layer and almost nothing on process. The prize is a trustworthy shared spine — master data, a common customer key, clean integration between systems that stay otherwise sovereign. This is the quadrant where a well-run data catalogue and a real integration platform earn their keep, and where mandating a single divisional process actively destroys value. The failure mode is a standardisation zealot who tries to make the divisions the same when what they needed was to be legible to each other.
Replication — high standardisation, low integration
The franchise quadrant. Many near-identical units that emphatically do not share operational data with each other. A fast-food chain or a limited-service hotel group: every outlet runs the same tightly specified process, and outlet A neither knows nor cares what outlet B is doing today. The unit of value is the repeatable operating template, stamped out again and again.
What it implies for IT: build the template once, centrally, and forbid local variation. The system is the process — point-of-sale, the operations playbook, the store-in-a-box — and autonomy is the enemy, because every local deviation degrades the thing that makes replication work. This is the one quadrant where “no, you may not customise it” is the correct architectural stance. The failure mode is letting strong-willed local managers fork the platform until you no longer have a replicable business, just a lot of similar-looking ones.
Unification — high standardisation, high integration
Same processes, shared data, one operation. A global parcel carrier or an airline: a single way of doing things, one set of data, tightly coupled end to end, because the product only works if every part executes the same process on the same information. This is the quadrant everyone thinks they’re in and most aren’t.
What it implies for IT: this is where the big enterprise-systems money is justified — the single ERP, the one CRM, the shared platform that both standardises and integrates. It’s the most expensive quadrant to run and the most fragile if you get the standardisation wrong, because there’s no divisional escape hatch. The failure mode is aspiration masquerading as fact: declaring yourself unified, buying the single global system, and then discovering the divisions were never going to give up their processes.
The part the book handles thinly
Here’s what the quadrant diagram doesn’t tell you, and where I’ve watched more programmes go wrong than anywhere else.
It’s a diagnostic, not a target. No quadrant is superior. Unification is not “level four of maturity”; it’s the right answer for an airline and the wrong answer for a conglomerate. The moment a leadership team treats the model as a ladder to climb, they start justifying a single global platform for a business that is structurally a holding company, and the platform fails for reasons the model predicted on day one.
Most organisations misidentify themselves upward. Ambition points to unification, so that’s where the dots land — the group CIO wants one operating model because it makes the org chart tidy and the vendor demo compelling. But the processes underneath are usually coordination at best. If you buy the unification system and live in the coordination world, you’ve bought integration you needed and standardisation the divisions will never accept, and you’ll spend three years discovering that in production.
You’re rarely one quadrant. This is the honest answer, and the book skims it: a real enterprise is diversification at the group level, coordination inside one division, and replication across that division’s branches — all at once. The model isn’t wrong; you’re applying it at the wrong altitude. The fix is to stop asking “which operating model are we” and start asking “at which scope”. Run the diagram separately for the group, for each division, and for the shared services layer. You’ll get different, defensible answers, and the disagreements will fall along the seams where they belong.
That altitude problem is exactly the one Gregor Hohpe writes about in The Software Architect Elevator — the architect’s job is riding between the floors so the boardroom’s “we’re one company” and the machine room’s “these are five different systems” are the same conversation (full review). And once you’ve named the scope, the shape of the teams that own each one is a Team Topologies question: a replication quadrant wants a platform team guarding one template, a coordination quadrant wants stream-aligned teams over a shared data spine (full review).
How to run the diagnostic on Monday
- Pick the scope out loud. Group, division, or shared-services layer — name it before you draw anything, because the answer changes with altitude.
- Score the two axes separately. “Do we run the same processes?” and “do we share data?” are different questions. Refuse to let the room collapse them.
- Place the dot, then place where people think it is. The gap between the two is your real finding. Most rooms sit lower and to the left than they claim.
- Point the IT spend at the quadrant you’re actually in, not the one on the strategy slide. Coordination buys data integration; replication buys a locked template; unification buys the single platform; diversification buys almost nothing central.
Bottom line
The four operating models are a diagnostic for two questions — do we standardise our processes, and do we integrate our data — that most organisations answer more ambitiously than the evidence supports. Get the answer right, at the right scope, and it tells you where to spend and, more usefully, where not to. Get it wrong and you buy a global platform for a business that was never going to use it.
If you want the original argument in full, with the case studies and the maturity model I’ve deliberately left out here, read Enterprise Architecture As Strategy — it’s the book that named the operating model, and my full review covers where it holds up and where it’s dated. It’s also the first book on my reading path for new architects, for exactly this reason: the operating model is the entry point to everything else.
Operating models — quick answers
- What are the four operating models in enterprise architecture?
- Diversification, coordination, replication and unification. They come from two axes: business process standardisation (do units run the same processes?) and integration (do units share data?). Low/low is diversification, low-standardisation/high-integration is coordination, high-standardisation/low-integration is replication, and high/high is unification.
- What is the difference between coordination and unification?
- Both integrate data across business units, but coordination lets each unit keep its own processes while unification standardises the processes too. A bank sharing one customer view across divisions that operate differently is coordination; a single global airline running one process on one dataset is unification.
- Which operating model is best?
- None. It's a diagnostic, not a maturity ladder. Unification suits a single integrated operation and is the wrong, expensive answer for a diversified holding company. The best model is the one that matches how your business actually creates value, which is why most organisations overstate where they sit.
- What if different divisions have different operating models?
- That's normal, and the framework is fine — you're applying it at the wrong altitude. Run the diagnostic separately for the group, each division, and the shared-services layer. You'll get different, defensible answers, and the model tells you where to integrate and where to leave units alone.
- Where does the operating model concept come from?
- From Enterprise Architecture As Strategy (Ross, Weill, Robertson, 2006). The case studies have dated, but the two-axis diagnostic has not, and it remains the fastest way to get a leadership team to admit they don't agree on what kind of company they are.