Operating Models for Solid Foundations Part 2 - Fund the Foundation, Not Just the Launch

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

Part 1 diagnosed the problem: enterprises fragment their technology portfolios when they don't choose an operating model explicitly, and architecture governance without funding power is just advice. Part 2 goes underneath the money. Why does a shared platform that was properly funded at build time get cut in the next annual opex review? Why do the teams building foundations keep losing arguments they should win? And what can a leadership team actually change — without rewriting the chart of accounts?

What we cover:

• The CapEx/OpEx accounting trap: why building a platform looks like an investment but running it looks like overhead — and how that difference alone explains most platform degradation after go-live
• The producer-consumer funding gap: why every shared platform's costs land in one place while the value is spread across every team consuming it — and why that structure makes the platform impossible to defend in a budget review
• From projects to products: what the product operating model actually means for how you fund, staff, and measure a shared foundation — and why McKinsey's research shows it produces higher technology returns
• FinOps as an enterprise governance tool: how showback and chargeback make a platform's value visible to finance teams and business leaders before the annual budget cycle, not during it
• Closing the governance loop: what it means to give architecture a seat at the funding table instead of the review table — and the one sequence change that prevents the next fragmentation cycle from starting
• Five Monday-morning moves for senior leaders: from the capability map to the product funding pilot — concrete actions that don't require a transformation program

"The moment a CEO or CFO asks 'show me the capability map' — it gets made."

Key references:

• McKinsey — The bottom-line benefit of the product operating model, technology funding and returns: https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-bottom-line-benefit-of-the-product-operating-model
• FinOps Foundation — Managing shared cloud and platform costs, showback and chargeback framework: https://www.finops.org/framework/capabilities/invoicing-chargeback/
• IAS 38 (IFRS Foundation) — Intangible asset capitalisation standards, CapEx treatment of software development: https://www.ifrs.org/content/dam/ifrs/publications/pdf-standards/english/2021/issued/part-a/ias-38-intangible-assets.pdf
• Ross, Weill & Robertson — Enterprise Architecture as Strategy (MIT CISR), operating model and engagement model: https://cisr.mit.edu/publication/enterprise-architecture-as-strategy

Better AI still starts with better foundations.

Transcript

SPEAKER_00 0:06

James, I've been thinking about how part one ended.

SPEAKER_02 0:09

Good thoughts or bad thoughts?

SPEAKER_00 0:11

Unsettling thoughts. You described a delivery team that did everything right, got the operational budget approved, embedded it in the project financials, delivered the platform, and then watched it get cut in the next OPEX review cycle by someone who didn't understand what they were cutting.

SPEAKER_02 0:32

Right.

SPEAKER_00 0:33

And I keep coming back to the same question. How does that happen? The platform is running, the value is real, the budget was approved. What breaks?

SPEAKER_02 0:45

That's exactly where we're starting today. Welcome back to AI Beyond the Hype. I'm James.

SPEAKER_00 0:50

And I'm Sarah. Part two of two. Last episode, James convinced me that most enterprise technology fragmentation isn't a delivery failure, it's an operating model problem. Today we're going underneath the money, how you fund foundations, why the standard budget tools work against you when you're trying to sustain a shared platform. And what a leadership team can actually do about it.

SPEAKER_02 1:17

And we're picking up the same organization we've been following: the one with three central data platforms, the solid project framework, the architectural review toll gates that don't bite. The delivery team did the right thing with the budget. And then the annual cycle killed it.

SPEAKER_00 1:34

So walk me through the mechanics. Why does that happen?

SPEAKER_02 1:38

Okay, let's start with CapEx and OPEX, because I think this is one of those concepts that everybody in a leadership meeting nods at, and fewer people really understand the trap inside it.

SPEAKER_00 1:48

Set it up.

SPEAKER_02 1:49

So capital expenditure, CapEx, is money spent building or acquiring an asset. Under accounting standards like IAS38, you can capitalise development costs, spread them over the asset's useful life rather than hitting the PL all at once. Which means building a new platform looks on paper like an investment. It goes on the balance sheet. It gets amortized over three to five years.

SPEAKER_00 2:14

Which makes it easier to get approved. Because you're not taking a big PL hit in year one.

SPEAKER_02 2:20

Exactly. And operational expenditure, OPEX, is the ongoing cost of running and maintaining what you built. Under the same accounting standards, once the asset is live, maintenance costs get expensed immediately. They hit the P and L in the period they're incurred. No spreading, no deferral.

SPEAKER_00 2:39

So the build looks like an investment, the run looks like a cost.

SPEAKER_02 2:43

And here's where the trap opens. In most large enterprises, capital budgets and operational budgets are managed separately. Different approval processes, different budget owners, different review cycles. A project can get CapEx approved through the project framework, business case, architecture review, funding gate, the whole machinery. And then its ongoing OPEX is sitting in a completely separate bucket that gets reviewed at the end of the financial year, alongside every other operational line item in the business.

SPEAKER_00 3:14

And the people reviewing that list at the end of the year don't necessarily know which line items are cut the coffee subscription and which ones are cut the run cost for a shared platform that eight projects depend on.

SPEAKER_02 3:28

That is exactly the problem. And it's structural. The project framework is designed to govern capital investment decisions. It's not designed to govern the ongoing operational commitment that the capital investment creates. So there's a gap between the CapEx approval that funds the build and the OPEX reality that funds the run. And in most organizations, nothing formally bridges that gap.

SPEAKER_00 3:51

Which means the platform team is making the case for their operational budget every year from scratch, in a process that wasn't designed to understand their value.

SPEAKER_02 4:00

From scratch against everyone else's operational line items. Without the language or the visibility to make the arguments stick. And here's what makes it worse: the value of a shared platform is diffuse. It benefits multiple departments, but the cost sits in one place. So when the cuts come, the platform team can't point to a single business unit that will visibly suffer. Everyone loses a little, nobody loses enough to stand up and block it.

SPEAKER_00 4:29

We actually named this in the data quality series. The producer-consumer gap. The team producing the platform, or the clean data, or the governance controls, they carry the cost. The teams consuming it carry the benefit. And those two things almost never sit on the same PL.

SPEAKER_02 4:49

And now we understand why that gap exists structurally. It's not a governance oversight, it's a natural consequence of how capital and operational budgets are managed in most large organizations. The producer team's OPEX lands in a central cost pool. The consumer team's business cases are built on the value they get from consuming it. When the budget cycle hits, the consumer teams are fighting for their own projects. The producer team is fighting alone.

SPEAKER_00 5:19

So what's the fix? Because restructure how all enterprises manage their accounting is not a Monday morning move.

SPEAKER_02 5:27

No, it's not. But there are three things a leadership team can do that don't require rewriting the chart of accounts. The first is to shift the mental model from projects to products, and I mean that in a specific sense. A project has a defined scope, a defined end date, a defined team that disbands when it's done. It's optimized for delivery. A product has an ongoing roadmap, an ongoing team, and a lifecycle that lasts as long as the product delivers value. It's optimized for sustained outcomes.

SPEAKER_00 6:01

And a shared data platform, a real foundation layer platform, is a product, not a project.

SPEAKER_02 6:08

It's a product. It evolves. It needs investment after GoLive, not just maintenance. New use cases come in, security requirements change, the data landscape around it shifts. If you fund it as a project, you're optimizing for the launch. If you fund it as a product, you're optimizing for the value it delivers continuously.

SPEAKER_00 6:27

McKinse published something on this a couple of years ago. The product operating model. The finding was that companies that fund and structure technology as products rather than projects tend to realize significantly higher returns on their technology investment. Not because the technology is better, because the sustained funding model means the technology keeps improving rather than degrading after go live.

SPEAKER_02 6:55

And it changes the accountability structure. A product team has a mandate. Here's what this platform is supposed to deliver, here's how we measure it, here's the ongoing budget tied to those outcomes. That's a very different conversation to have in a budget review than we need OPEX to keep the lights on.

SPEAKER_00 7:12

So what does that look like in practice for the organization we've been following? Because they're already mid-flight, they've got three platforms, they've got the project framework, they've got the budget structure they have. How do you shift from here?

SPEAKER_02 7:27

You start with visibility. Which brings me to the second fix: making platform value explicit before the budget cycle, not during it. The reason platform OPEX gets cut is almost always the same. Nobody has made the case for what it's worth, in terms that a finance team can engage with before the review starts. The platform team knows the value. The consuming teams know the value, but that value has never been aggregated, quantified, and placed next to the cost.

SPEAKER_00 7:57

This is where FinOps comes in. And I want to talk about this because I think it's underused as a concept outside of cloud cost management. Go on. Finops, financial operations, started as a discipline for managing cloud spend. The core idea is that cloud costs are variable and distributed, and the only way to manage them well is to give the engineers, the finance team, and the business leaders a shared view of what things cost and what value they deliver. But the underlying principle applies to any shared technology platform. The FinOps Foundation's framework is explicit about it. The foundational principle is that everyone takes ownership of their usage. And that only works if everyone can see the cost of what they're consuming.

SPEAKER_02 8:48

So applied to a shared data platform, what does that look like practically?

SPEAKER_00 8:53

It looks like chargeback or showback. Showback means every consuming department gets a report. Here's what you used, here's what it costs to run for you. No money moves. But the visibility is there. Chargeback goes further. The cost is actually allocated to the consuming department's budget. Both models make the platform's value visible at the point where it's consumed, rather than buried in a central cost pool.

SPEAKER_02 9:22

And suddenly, the budget conversation changes. Instead of the platform team standing up alone saying, please don't cut our OPEX, you have eight department heads who can see exactly what they'd lose if the platform degraded. Because it's on their cost report.

SPEAKER_00 9:37

And more importantly, the finance team can see the total cost of ownership against the total value delivered. The platform team isn't making an abstract argument anymore. They're pointing to numbers.

SPEAKER_02 9:50

Which is the language that actually works in a budget review? This platform supports revenue from these use cases, reduces manual effort across these teams, is the foundation for these three AI initiatives we approved last year. Cutting the run budget by 30% does this to those outcomes. That's a decision. We need money to keep the lights on, is a plea.

SPEAKER_00 10:14

Nobody wins a plea in a budget review.

SPEAKER_02 10:16

Nobody.

SPEAKER_00 10:17

Okay, so we've got the mental model shift, projects to products. We've got the visibility mechanism, showback or chargeback, making the value visible before the budget cycle. What's the third fix?

SPEAKER_02 10:31

The third is the hardest. And it goes back to part one. You need to give architecture a seat at the funding table, not just the review table. Because even if you fix the OPEX visibility problem for existing platforms, you'll keep building new fragmentation if the investment decision process still funds use cases and departments without an enterprise view of what it's creating.

SPEAKER_00 10:56

So this is about closing the loop on the engagement model.

SPEAKER_02 11:00

Exactly. In the organization we've been following, the architectural review exists, the feedback is recorded, the toll gate is passed. What doesn't exist is a mechanism where that feedback changes the funding decision. Where a project that duplicates an existing capability can be redirected or held or required to use the enterprise platform. Without that mechanism, the review is still just advice.

SPEAKER_00 11:25

And what does the mechanism look like in practice?

SPEAKER_02 11:28

It looks like a few specific things. Portfolio level architecture reviews that happen before individual project funding gates, not after. Explicit exception processes for when a project needs to deviate from the enterprise architecture, with a documented consequence and a plan to resolve the divergence. And critically, architecture input into the early stage funding gates, the ones that release the first tranche of capital. Before the vendor is selected, before the team is assembled, when the decision is still a decision.

SPEAKER_00 12:02

That last one is the one that's always missing. Because the architecture review in most frameworks happens after the business case is approved, by which point the business sponsor has a vendor preference, a delivery team lined up, and a deadline. The architectural input becomes change management, not design input.

SPEAKER_02 12:21

And it's not malicious, it's just the sequence. You fund the project, then you review the architecture, then you deliver. If you want the architecture to shape the outcome, you need it in the sequence before the funding decision, not after.

SPEAKER_00 12:35

It also requires the architecture function to be resourced to do that. Because one of the reasons architecture reviews become rubber stamps is that the architecture team is stretched across 20 projects simultaneously and doesn't have the capacity to do a real review, let alone proactively shape the portfolio.

SPEAKER_02 12:55

Which is itself a funding question. If you want architecture to create value at the portfolio level, you have to fund it at the portfolio level, not as a project overhead, as a standing enterprise capability with its own budget, its own mandate, and its own accountability.

SPEAKER_00 13:12

The architecture team is also a producer.

SPEAKER_02 13:15

The architecture team is absolutely also a producer. I want to bring this back to the organization one more time, because there's a version of this story that ends well. And I think it's important to be concrete about what ends well actually looks like. Because it doesn't mean starting over, it means changing a few specific things.

SPEAKER_00 13:35

What would you change first?

SPEAKER_02 13:37

If I was walking in tomorrow, the first thing I'd do is map the portfolio. Not at the project level, but at the capability level. What shared capabilities exist today? What does each one cost to run? Which business units consume each one? What are the three AI priorities the organization has approved in the last 12 months, and which capabilities do they depend on? That map takes a few weeks to build, but it makes every subsequent conversation about fragmentation, about OPEX cuts, about which platforms to invest in, concrete instead of abstract.

SPEAKER_00 14:14

And it probably makes the three data platforms problem visible in a way it hasn't been before. Because right now, each department knows about their platform. Nobody has the enterprise view.

SPEAKER_02 14:26

Exactly. The second thing I'd do is take that map into the next budget cycle, not at the end of the cycle, but at the start. Use it to make the case that these three platforms should be consolidated into one, that the consolidation saves X in run costs, and that the savings fund the roadmap. That's a business case. It's not a technology project. It's a strategic investment with a measurable return.

SPEAKER_00 14:51

And it changes the conversation from we need money for platforms to here's where we're spending twice for no additional value, and here's how we stop.

SPEAKER_02 15:01

The third thing is harder and takes longer. It's changing the governance sequence so that architecture input comes before the funding gate, not after the vendor selection. That's a change to the project framework. It requires political capital. It requires the CIO or the CDO to own it visibly. But it's the thing that prevents the next fragmentation cycle from starting before you've finished fixing this one.

SPEAKER_00 15:27

Because otherwise you fix the three platforms, and 18 months later you've got a fourth one.

SPEAKER_02 15:31

Yep, you fix the three, and 18 months later, someone has funded a new use case that quietly creates a fourth.

SPEAKER_00 15:38

Okay, I want to land this for the executive listener. Because we've covered a lot of ground across two episodes: the operating model, the engagement model, the CapEx OpEx trap, product funding, FinOps, the governance sequence. What's the version of this that's actionable on Monday morning?

SPEAKER_02 15:58

I'd give a leader five moves. The first, ask for the capability map, not the project list, the capability map. What shared platforms and services exist, what they cost to run, who depends on them. If nobody can produce it, that's your starting point. The second, check the architecture review sequence. Are architects in the room before funding gates or after? If they're reviewing business cases that are already approved, they're annotating decisions, not shaping them. One change to the sequence, one gate, early in the process before vendor selection, changes everything downstream. The third? Map your operating model by domain. Not the whole enterprise's one answer, but at the level of your core data domains. Customers, products, assets, operations. Where do you need shared data? Where can business units run their own processes? If you can answer that question by domain, you have the foundation for a funded architecture target state. If you can't, the architecture team is building against a target nobody has agreed on.

SPEAKER_00 17:03

The fourth?

SPEAKER_02 17:04

Make the OPEX visible before the budget cycle. Whatever mechanism you use, showback reports, internal cost allocation, a simple dashboard, give the finance team and the business leaders a view of what shared platforms cost and what they deliver. Do it before the annual review, not during it. The goal is for the budget conversation to be a decision, not a surprise. And the fifth? Decide what a product looks like. Pick one platform, ideally the one most central to your AI strategy, and fund it as a product. Give it a roadmap, a team, a lifecycle budget, and a set of outcomes it's accountable for. See what changes. Use it as the model for the rest.

SPEAKER_00 17:46

Those five things don't require a transformation program. They don't require a new framework. They require a decision and a few process changes.

SPEAKER_02 17:55

Which is the point? The reason this stuff doesn't get fixed isn't usually that it's too hard, it's that nobody has made it the leadership team's problem. It lives in IT, it lives in the architecture function, it lives in the delivery teams who keep trying to protect their platforms and running out of language to do it with. The moment a CEO or a CFO asks, show me the capability map, it gets made.

SPEAKER_00 18:20

And here's where I want to close the loop on something. In the data quality series, we spent two episodes on the mechanics of dirty data, the dimensions, the failure modes, the things that go wrong in pipelines and schemas and governance controls. And one of the things we kept coming back to was the producer-consumer gap. The teams producing quality data don't get funded. The teams consuming it do. Right. What we've described in these two episodes is where that gap comes from. It's not a data governance problem, it's an operating model and funding design problem. The producer-consumer gap is what happens when you have a project-funded, department-budgeted, architecture advisory enterprise that hasn't made explicit decisions about what must be shared, who pays for it, and how it gets sustained.

SPEAKER_02 19:13

That's the connection I was hoping we'd land. The data quality problem and the operating model problem are the same story. Different entry points, same building.

SPEAKER_00 19:23

It really is. And I'll admit, two episodes ago I filed operating models under Governance Admin and thought about pipelines. I remember. And now I'm going to go home and mentally re-diagnose every data quality problem I've ever fixed and ask whether the real issue was two floors up.

SPEAKER_02 19:42

That sounds like a productive weekend.

SPEAKER_00 19:44

I've already started a list.

SPEAKER_02 19:46

Of course you have. Thanks for listening to AI Beyond the Hype. I'm James.

SPEAKER_00 19:52

And I'm Sarah. If you've been in that budget meeting watching the platform team lose an argument they should have won, this one was for you.

SPEAKER_01 20:00

And remember, better AI still starts with better foundations.

SPEAKER_00 20:04

Even when the foundation is a line item on someone's spreadsheet. Especially then.