Operating Models for Solid Foundations Part 1 - The Model You Didn't Choose

Part 1 of 2 in our Operating Models for Solid Foundations series.

Most large enterprises have project frameworks, architecture tollgates, and governance processes — and still end up with three separate "central" data platforms. In this episode, James makes the case that fragmented technology portfolios aren't a delivery failure. They're the downstream consequence of an operating model that was never explicitly chosen. Sarah comes in sceptical. By the end she's unsettled — and sees for the first time why so many of the data problems she's spent her career fixing kept coming back.

What we cover:

• Why "operating model" is a specific strategic choice — not a generic description of how the business runs — and the two axes that define it
• The four operating model types (Diversification, Coordination, Replication, Unification) and why each implies a completely different architecture and funding logic
• How architecture tollgates become rubber stamps when they're disconnected from investment decisions — and what a real IT engagement model looks like instead
• The "three central data platforms" problem: why every team that built one was responding rationally to the signals they were given
• How DBS Bank cut AI deployment time from 18 months to under 5 months — not through better models, but through an explicit operating model and funded platform foundations
• Why delivery teams that do everything right — including funding the operational run budget — still see their platforms degraded by sweeping opex cuts they had no language to resist

"The wiring can't be right if nobody decided what the building is supposed to do."

Key references:

• Ross, Weill & Robertson — Enterprise Architecture as Strategy (MIT CISR), foundational operating model framework: https://cisr.mit.edu/publication/enterprise-architecture-as-strategy
• MIT CISR, architecture learning and management practices that help EA create value: https://cisr.mit.edu/publication/2012_0901_ArchitectureLearning_RossQuaadgras
• McKinsey — DBS Bank platform transformation and AI deployment case: https://www.mckinsey.com/capabilities/tech-and-ai/how-we-help-clients/rewired-in-action/dbs-transforming-a-banking-leader-into-a-technology-leader
• INFORMS — UPS ORION route optimisation, built on unified operational data foundations: https://www.informs.org/Impact/O.R.-Analytics-Success-Stories/UPS

Better AI still starts with better foundations.

Transcript

SPEAKER_00 0:06

Sarah, I have to be honest with you, I've been looking forward to this episode for a while.

SPEAKER_01 0:10

I know. You mentioned it twice last week.

SPEAKER_00 0:14

Operating models, engagement frameworks, portfolio alignment. This is the stuff that actually makes or breaks an enterprise.

SPEAKER_01 0:22

Hmm, can't wait.

SPEAKER_00 0:24

You're not excited.

SPEAKER_01 0:25

James, you sent me a reading list. It had 11 items on it. One of them was a textbook.

SPEAKER_00 0:32

It's a very good textbook.

SPEAKER_01 0:34

I'm sure it is. I just. Look, I spend my days in data pipelines. I care deeply about whether your data lands clean, whether your schemas are versioned, whether your quality controls actually fire. Operating models feel like the PowerPoint that lives two floors above the actual problem.

SPEAKER_00 0:53

Two floors above the actual problem. I'm going to use that. Please don't. Okay, here's what I'll do. I'm not going to convince you with the framework up front. I'm going to tell you about an organization I've spent time with. And by the time I'm done, you're going to tell me the operating model is the problem. Deal?

SPEAKER_01 1:11

Sure. Um deal.

SPEAKER_00 1:13

That was not a confident deal.

SPEAKER_01 1:16

It was a conditional deal. Let's hear the scenario.

SPEAKER_00 1:19

Right. So I want to keep one organization in mind as we go through this episode. I'm not going to name them, but I've spent time with a large enterprise that has a genuinely well-defined project management framework. Not a PowerPoint framework, a real one. It covers agile and traditional delivery. It has documented key deliverables, clear processes, defined toll gates at every stage.

SPEAKER_01 1:44

That's actually rarer than it should be.

SPEAKER_00 1:47

Agreed. And here's the thing. The framework even includes architectural design reviews. There is a formal toll gate where architecture has to sign off before a project proceeds.

SPEAKER_01 1:57

Okay, so that sounds like they've got the machinery in place. What's the problem?

SPEAKER_00 2:02

They currently have at least three separate central data platforms.

SPEAKER_01 2:07

Three.

SPEAKER_00 2:08

Three. Built by different departments independently over time, each one described internally as the data platform. With overlapping scope, duplicated data, no common security controls, and genuine confusion about which one is the source of truth for any given data set.

SPEAKER_01 2:27

How does that happen when you have architectural review toll gates?

SPEAKER_00 2:32

That's exactly the right question. And the answer to it is what this whole episode is about. Welcome to AI.

SPEAKER_01 2:41

And I'm Sarah. Part one of two on operating models and foundations. Today we're starting with the thing James keeps calling upstream of everything. I'm going to be skeptical until he convinces me.

SPEAKER_00 2:56

Fair. Okay, so let me start with a concept that I think a lot of executives have heard and fewer have actually sat with. The operating model. And I mean this in a specific sense, not the generic how our business operates sense. I mean it as a strategic choice. How much do our business units need to run the same processes? And how much do they need to share data?

SPEAKER_01 3:19

Those feel like two very different questions.

SPEAKER_00 3:22

They are. And the framework that I keep coming back to. It's from three researchers at MIT, Ross, Weill, and Robertson. It puts those two questions on two axes. Standardization. How much do we want processes to look the same across the enterprise? And integration. How much does one part of the business depend on data from another part? Cross those axes and you get four operating model types.

SPEAKER_01 3:50

Walk me through them.

SPEAKER_00 3:51

So at one end you've got what they call diversification, low standardization, low integration. Business units operating basically independently, serving different markets, different customers. A conglomerate that owns a mining business, a media company, and a logistics arm. Those businesses might share a balance sheet, but they don't need each other's data to do their jobs.

SPEAKER_01 4:15

So a shared data platform there would be mostly overhead.

SPEAKER_00 4:19

Mostly, yes. You'd fund shared enterprise controls, security, finance consolidation, compliance, but you'd be careful about imposing platforms where there's no real dependency. The opposite corner is unification, high standardization, high integration, common processes, shared data, tightly interdependent business units. Think a bank with a single customer record, or an airline, one seat on one plane, one booking system, one revenue network.

SPEAKER_01 4:48

And that's where you'd invest heavily in enterprise-grade foundations. Because the whole operating model depends on them.

SPEAKER_00 4:55

Exactly. And in between, you've got coordination, where business units keep their own processes but really do need to share data. Customer data, product data, asset data. The units are independent, but they need a common view. And replication, where the processes themselves are standardized, like a franchise or a retail chain running the same model across hundreds of sites, but the sites don't need each other's data in real time.

SPEAKER_01 5:21

So the operating model tells you what architecture you actually need.

SPEAKER_00 5:26

That's the key move. The operating model is upstream of the architecture. It tells you what must be common, what can vary, what needs to be shared, and what can stay local. And I want to be clear about something here. None of this applies equally to every organization. A 50-person company with one product line doesn't need an enterprise architecture function. They need good engineers and clear priorities. The overhead of formal operating model design would slow them down more than it would help them.

SPEAKER_01 5:57

So when does it start to matter?

SPEAKER_00 5:59

When you grow, when you add departments, when you add geographies or business units. When the number of technology decisions being made simultaneously, by different teams, in different rooms, against different local priorities, gets large enough that no single person can see across all of them. There's a body of research on this that's pretty consistent. Organizational complexity drives technology complexity. And the organizations that don't have formal architecture management are the ones that see that complexity compound fastest as they scale. PWC did a global study on this. The finding was that managing complexity stays manageable up to a point, and then it doesn't. EA becomes the mechanism that keeps the technology landscape coherent when the organization can no longer rely on one person knowing everything.

SPEAKER_01 6:51

So it's not about being bureaucratic, it's about the information problem that comes with size.

SPEAKER_00 6:57

Exactly. When you're small, alignment is informal. You walk across the office. When you have 500 people across multiple departments and you're running 30 projects in parallel, informal alignment doesn't scale. You need structure. And the cost of not having it isn't obvious on day one. It compounds quietly. A duplicate platform here, an inconsistent data definition there, until you surface the issue and realize you've been paying for the same thing three times.

SPEAKER_01 7:27

Which brings us back to the three central data platforms.

SPEAKER_00 7:31

It always does. Without that operating model choice being made explicitly, you end up with every project team making their own call, and you end up with three data platforms.

SPEAKER_01 7:41

Okay, so walk me through why the organization you mentioned ends up there. Because they're not making no choices. They have a framework, they have toll gates, they have architectural reviews.

SPEAKER_00 7:53

Right, and here's where it gets interesting. The organization has the machinery. What it doesn't have is the operating model made explicit. So when a department comes in with a project, the architectural review happens, but it's happening against a target state that isn't fully defined. The architects can say, this looks like it duplicates something, and they do say that, in writing, in the review. But the feedback goes into the record, the toll gate gets passed, and nobody checks whether the feedback was acted on once the project moves into delivery.

SPEAKER_01 8:26

The toll gate clears, and then the review just stops.

SPEAKER_00 8:31

Stops. And here's the funding dynamic that makes it worse. Budgets are held by regional and functional teams. The project sponsor is in the business. When there's a conflict between the architect said we should use the enterprise platform, and the enterprise platform doesn't quite fit our use case and it'll slow us down by three months, the business team makes the call.

SPEAKER_01 8:53

Because they hold the budget.

SPEAKER_00 8:55

Because they hold the budget. And the architect can raise concerns, but they don't have a seat at the funding table. They have a seat at the review table. Those are different seats.

SPEAKER_01 9:06

So architecture governance without funding power is just advice.

SPEAKER_00 9:11

MITCISR. The research center at MIT that produced the framework I mentioned, they actually name this specifically. The management practices that let architecture create real value are things like transparent technology costs, explicit architecture exception debates, and critically, making investment decisions with enterprise architecture in mind. Not architecture as a review step, architecture as part of the capital allocation decision.

SPEAKER_01 9:41

That's a meaningful distinction. Because in most of the organizations I've worked with, the architecture review is a gate. You submit, you get feedback, you proceed. Nobody tracks whether the feedback changed the outcome.

SPEAKER_00 9:56

And the result, over time, is what I'd call portfolio fragmentation. Every department plans its work independently. There's no enterprise architecture function that shapes the portfolio, that looks across all the projects and says, these three are doing the same thing. Let's align them. Or this project needs a shared capability that doesn't exist yet. We need to sequence the foundation first. Instead, you get point solutions. Department A builds their own data extract. Department B builds their own. Department C builds theirs. Each one is locally rational. Together, they create duplication. They create inconsistent data. And when you try to apply a governance control, a security policy, a data classification, an access rule, you have to apply it three times to three different systems.

SPEAKER_01 10:46

And then someone comes in trying to do AI and they ask, what's the source of truth for this asset? And the answer is complicated.

SPEAKER_00 10:55

The answer is, it depends who you ask, which is no answer at all when you're trying to train a model or run an automated process.

SPEAKER_01 11:02

This is actually starting to land for me. Because I've walked into data problems that looked like engineering failures, pipelines misconfigured, schemas diverging, quality controls missing, and I've always treated them as things to fix at the platform level. But what you're describing is that those engineering failures are downstream symptoms of a decision that was never made above the platform level.

SPEAKER_00 11:28

That's exactly it. The wiring can't be right if nobody decided what the building is supposed to do.

SPEAKER_01 11:34

Okay, you've convinced me. This is upstream of the pipelines. I'll take the win!

SPEAKER_00 11:40

So let's go a layer deeper into why the architecture tollgate fails even when it exists. Because I want to name a concept that I think gets missed in most governance conversations. The IT engagement model.

SPEAKER_01 11:53

Which is what exactly?

SPEAKER_00 11:56

It's the third element of the MITCISR framework that almost everyone skips. People focus on the operating model and the enterprise architecture. The engagement model is the system of governance mechanisms that ensures projects achieve both local objectives and enterprise objectives. In plain language, it's how architecture, portfolio management, funding, and delivery governance actually connect to each other.

SPEAKER_01 12:23

So not just does the project have a toll gate, but does passing the toll gate actually change the investment decision?

SPEAKER_00 12:31

Right. And the reason this matters is that architecture governance is often experienced as friction when it's detached from enablement and funding. If a project team is told, use the shared platform, but the shared platform doesn't have capacity, or doesn't have documentation, or doesn't have a service level they can rely on, they'll bypass it. Locally rational, globally fragmenting.

SPEAKER_01 12:56

I've seen that. We would have used the enterprise tool, but it didn't support our use case. And by the time that feedback makes it back to the platform team, the project's already in delivery with a point solution.

SPEAKER_00 13:09

And here's the other side of it. Funding signals are the strongest signal in any organization of what's actually valued. If the enterprise funds use cases but not platforms, it's signaling that it values local delivery over reuse. If it funds the build of a platform but not the ongoing run, it's signaling that it values launch over reliability. Those signals aren't always intentional. They often emerge from how the annual budget cycle works, but they're real. And they compound over time.

SPEAKER_01 13:41

So when you're seeing three central data platforms, that's not incompetence on the part of the teams who built them. Each one of those teams was responding rationally to the signals they were given.

SPEAKER_00 13:53

Exactly. And to be clear about the organization I've been describing, these are good people, smart people. The project managers, the department heads, the architects who wrote those review comments, they all care. It's not negligence, it's a gap between how the system was designed and the conditions that would let the system actually function as intended. The framework says architecture should guide portfolio decisions. The funding mechanism says the business sponsor makes the call. Those two things are intention, and nobody resolved the tension explicitly.

SPEAKER_01 14:27

That's actually what I want executives to hear. Because I think the instinct when you see three data platforms is to say somebody dropped the ball. And what you're saying is the ball was always going to drop because of how the system was set up.

SPEAKER_00 14:41

It's a systemic failure, not an individual one. And the fix is systemic, which is why it has to start with the operating model. You can't fix the engagement model if you haven't made the operating model explicit. Because the engagement model is what makes the operating model real. It's how the strategic choice, we need data integration across these domains, becomes a funded platform, a prioritized project, a set of standards with teeth.

SPEAKER_01 15:09

Okay, let me ask you a diagnostic question. Because if I'm a CIO or a CDO listening to this, and I'm worried that my organization has this problem, how do I know? What are the signals?

SPEAKER_00 15:24

There are three I'd start with. The first is the how many question. How many central versions of the same capability do you currently run? How many integration platforms? How many data platforms? How many single sources of truth for your core entities, customers, products, assets, suppliers? If the answer to any of those is more than one, you've already got fragmentation.

SPEAKER_01 15:49

More than one source of truth is a phrase that should set off alarms.

SPEAKER_00 15:53

Immediately.

SPEAKER_01 16:18

If the architectural review feedback is recorded in the tollgate documentation, but nobody's checking whether it was implemented after the tollgate cleared, that's the same problem from a different angle.

SPEAKER_00 16:30

Exactly right. And the third signal is the operating model question itself. Can your chief architect or your CIO or your CDO explain your operating model by domain? Not the whole enterprise as one answer. But at the level of, in our customer domain, we're in coordination. We need shared data, but our business units can run different processes. If nobody can answer that question, the architecture has no foundation to build against. It's just preferences and precedents.

SPEAKER_01 17:00

And here's what makes this urgent now specifically. Because a lot of organizations are in the middle of laying their AI strategy on top of this. They're approving AI programs, they're running pilots, they're moving use cases into production. And the question of what's the source of truth for this data, or which platform do we actually trust, those questions are going to get asked every single time an AI model produces an output that doesn't match what someone expected.

SPEAKER_00 17:31

And the organization without an explicit operating model will answer that question in a different way every time it's asked. Because the answer depends on which data platform you happened to use. Which is not a place you want to be when a regulator or a board asks, how do we know this model's outputs are correct?

SPEAKER_01 17:49

That's the question that turns a data problem into a governance crisis.

SPEAKER_00 17:53

And very quickly. I want to spend a minute on what this looks like when it goes right. Because I don't want this episode to sound like enterprise architecture is the answer to everything. It isn't. But there are organizations that got this right, and the pattern is consistent. Who are you thinking of? DBS Bank is the clearest example I keep coming back to. They made a deliberate choice to restructure their technology delivery around 33 platforms, each aligned to a business segment, each jointly led by business and technology through what they called a two-in-a-box model. A business leader and a technology leader owning the same platform together.

SPEAKER_01 18:36

So architecture and business ownership were joined from the start, not architecture reviewing after business had already decided.

SPEAKER_00 18:45

Joined from the start. Not because their models were better, because their foundation was ready to receive.

SPEAKER_01 19:00

18 months to five months is the kind of number that should get a CFO's attention.

SPEAKER_00 19:05

It's the kind of number that turns a foundation investment from overhead into competitive advantage. And here's the thing about UPS. Similar story, different domain. They built a root optimization system called Orion that produced enormous savings in fuel and miles driven. But Orion didn't appear from nowhere. It was built on top of years of investment in unified operational data, standardized package data, standardized route data, standardized network data. The AI was the harvest. The foundation was the years of boring, unglamorous data work that came before it. And in both cases, DBS UPS, the operating model choice was made explicitly. Not as a slide, as a funded, governed, sequenced set of decisions about what had to be common, what could vary, and what needed to be shared across the enterprise before anything else could scale.

SPEAKER_01 20:12

Which brings us back to the organization you've been describing. Because they have the framework, they have the toll gates. What they don't have is the operating model choice made explicitly enough to drive the funding decisions.

SPEAKER_00 20:27

Right. And there's a consequence of that which we haven't touched on yet. It comes down to the operational budget. Tell me. So a delivery team works hard, genuinely hard, to get ongoing operational expenditure into the project financials. They know the platform needs to be sustained after Go Live. They build the numbers into the business case. They get it approved. The project delivers, the platform launches, the operational budget is embedded in the plan.

SPEAKER_01 20:56

That sounds like they did the right thing.

SPEAKER_00 20:58

They did the right thing. And then the annual operational budget review hits, and there's a sweeping cost reduction target. And someone, not the project team, not the architects, not the platform owner, someone in a budget function looks at a list of operational line items and makes a cut. Without understanding which of those line items is the run cost for a shared platform that multiple projects are now depending on.

SPEAKER_01 21:24

And the platform starts degrading. Support gets reduced. Monitoring gets cut. The security controls that were supposed to be applied enterprise-wide suddenly have no team maintaining them.

SPEAKER_00 21:36

And the people who know the platform team, they don't have the language to fight back. Because the platform's value is distributed, every department that uses it benefits, but no single department's PL captures that benefit. So when the budget cut happens, no single sponsor stands up and says, if you cut that, you're cutting mine. Everyone loses a little. Nobody loses enough to force the issue.

SPEAKER_01 22:02

That's the funding design problem, not negligence. The platform's value is real. It just isn't visible in the right place at the right time.

SPEAKER_00 22:12

And that is exactly where we're going in part two. Because what I've described today is the diagnosis, the operating model that was never chosen explicitly, the architecture governance that has no funding power, the portfolio that fragments by default. Part two is about the money. How you fund foundations so they don't degrade. Why the Capex OpEx distinction creates a specific kind of trap for technology leaders, and what a real life cycle funding model looks like. Because the fix isn't more governance ceremonies, the fix is changing what you fund and how.

SPEAKER_01 22:48

And can I just say, I came into this episode planning to be skeptical, and I'm leaving it genuinely unsettled. Because I've fixed a lot of data pipelines and data quality problems in my career, and what you've just described is the reason a lot of them came back.

SPEAKER_00 23:03

That's the thing about upstream problems. You can fix the symptoms as many times as you like. Until you change the source. Until you change the source. Thanks for listening to AI Beyond the Hype. I'm James.

SPEAKER_01 23:16

And I'm Sarah. Part two is where we fix it. Operating model diagnosis done, funding model next. We'll see you there.

SPEAKER_00 23:25

And remember, better AI still starts with better foundations.

SPEAKER_01 23:29

Even when the foundation is an org chart decision.

SPEAKER_00 23:32

Especially then.