July 3, 2026 • 20 mins
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.
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
SPEAKER_00 (00:06):
James, I've been thinking about how part one
ended.
SPEAKER_02 (00:09):
Good thoughts or bad thoughts?
SPEAKER_00 (00:11):
Unsettling thoughts.
You described a delivery teamthat did everything right, got
the operational budget approved,embedded it in the project
financials, delivered theplatform, and then watched it
get cut in the next OPEX reviewcycle by someone who didn't
understand what they werecutting.
SPEAKER_02 (00:32):
Right.
SPEAKER_00 (00:33):
And I keep coming back to the same question.
How does that happen?
The platform is running, thevalue is real, the budget was
approved.
What breaks?
SPEAKER_02 (00:45):
That's exactly where we're starting today.
Welcome back to AI Beyond theHype.
I'm James.
SPEAKER_00 (00:50):
And I'm Sarah.
Part two of two.
Last episode, James convinced methat most enterprise technology
fragmentation isn't a deliveryfailure, it's an operating model
problem.
Today we're going underneath themoney, how you fund foundations,
why the standard budget toolswork against you when you're
(01:11):
trying to sustain a sharedplatform.
And what a leadership team canactually do about it.
SPEAKER_02 (01:17):
And we're picking up the same organization we've been
following (01:19):
the one with three central data platforms, the
solid project framework, thearchitectural review toll gates
that don't bite.
The delivery team did the rightthing with the budget.
And then the annual cycle killedit.
SPEAKER_00 (01:34):
So walk me through the mechanics.
Why does that happen?
SPEAKER_02 (01:38):
Okay, let's start with CapEx and OPEX, because I
think this is one of thoseconcepts that everybody in a
leadership meeting nods at, andfewer people really understand
the trap inside it.
SPEAKER_00 (01:48):
Set it up.
SPEAKER_02 (01:49):
So capital expenditure, CapEx, is money
spent building or acquiring anasset.
Under accounting standards likeIAS38, you can capitalise
development costs, spread themover the asset's useful life
rather than hitting the PL allat once.
Which means building a newplatform looks on paper like an
investment.
(02:09):
It goes on the balance sheet.
It gets amortized over three tofive years.
SPEAKER_00 (02:14):
Which makes it easier to get approved.
Because you're not taking a bigPL hit in year one.
SPEAKER_02 (02:20):
Exactly.
And operational expenditure,OPEX, is the ongoing cost of
running and maintaining what youbuilt.
Under the same accountingstandards, once the asset is
live, maintenance costs getexpensed immediately.
They hit the P and L in theperiod they're incurred.
No spreading, no deferral.
SPEAKER_00 (02:39):
So the build looks like an investment, the run
looks like a cost.
SPEAKER_02 (02: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 approvedthrough the project framework,
business case, architecturereview, funding gate, the whole
(03:03):
machinery.
And then its ongoing OPEX issitting in a completely separate
bucket that gets reviewed at theend of the financial year,
alongside every otheroperational line item in the
business.
SPEAKER_00 (03:14):
And the people reviewing that list at the end
of the year don't necessarilyknow which line items are cut
the coffee subscription andwhich ones are cut the run cost
for a shared platform that eightprojects depend on.
SPEAKER_02 (03:28):
That is exactly the problem.
And it's structural.
The project framework isdesigned to govern capital
investment decisions.
It's not designed to govern theongoing operational commitment
that the capital investmentcreates.
So there's a gap between theCapEx approval that funds the
build and the OPEX reality thatfunds the run.
And in most organizations,nothing formally bridges that
(03:50):
gap.
SPEAKER_00 (03:51):
Which means the platform team is making the case
for their operational budgetevery year from scratch, in a
process that wasn't designed tounderstand their value.
SPEAKER_02 (04:00):
From scratch against everyone else's operational line
items.
Without the language or thevisibility to make the arguments
stick.
And here's what makes it worse: the value of a shared platform (04:09):
undefined
is diffuse.
It benefits multipledepartments, but the cost sits
in one place.
So when the cuts come, theplatform team can't point to a
single business unit that willvisibly suffer.
Everyone loses a little, nobodyloses enough to stand up and
block it.
SPEAKER_00 (04: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 carrythe cost.
The teams consuming it carry thebenefit.
And those two things almostnever sit on the same PL.
SPEAKER_02 (04: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 operationalbudgets are managed in most
large organizations.
The producer team's OPEX landsin a central cost pool.
The consumer team's businesscases are built on the value
they get from consuming it.
(05:11):
When the budget cycle hits, theconsumer teams are fighting for
their own projects.
The producer team is fightingalone.
SPEAKER_00 (05:19):
So what's the fix?
Because restructure how allenterprises manage their
accounting is not a Mondaymorning move.
SPEAKER_02 (05:27):
No, it's not.
But there are three things aleadership team can do that
don't require rewriting thechart of accounts.
The first is to shift the mentalmodel from projects to products,
and I mean that in a specificsense.
A project has a defined scope, adefined end date, a defined team
that disbands when it's done.
(05:48):
It's optimized for delivery.
A product has an ongoingroadmap, an ongoing team, and a
lifecycle that lasts as long asthe product delivers value.
It's optimized for sustainedoutcomes.
SPEAKER_00 (06:01):
And a shared data platform, a real foundation
layer platform, is a product,not a project.
SPEAKER_02 (06:08):
It's a product.
It evolves.
It needs investment afterGoLive, not just maintenance.
New use cases come in, securityrequirements 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 (06:27):
McKinse published something on this a couple of
years ago.
The product operating model.
The finding was that companiesthat fund and structure
technology as products ratherthan projects tend to realize
significantly higher returns ontheir technology investment.
Not because the technology isbetter, because the sustained
(06:49):
funding model means thetechnology keeps improving
rather than degrading after golive.
SPEAKER_02 (06:55):
And it changes the accountability structure.
A product team has a mandate.
Here's what this platform issupposed to deliver, here's how
we measure it, here's theongoing budget tied to those
outcomes.
That's a very differentconversation to have in a budget
review than we need OPEX to keepthe lights on.
SPEAKER_00 (07:12):
So what does that look like in practice for the
organization we've beenfollowing?
Because they're alreadymid-flight, they've got three
platforms, they've got theproject framework, they've got
the budget structure they have.
How do you shift from here?
SPEAKER_02 (07:27):
You start with visibility.
Which brings me to the secondfix: making platform value
explicit before the budgetcycle, not during it.
The reason platform OPEX getscut is almost always the same.
Nobody has made the case forwhat it's worth, in terms that a
finance team can engage withbefore the review starts.
(07:48):
The platform team knows thevalue.
The consuming teams know thevalue, but that value has never
been aggregated, quantified, andplaced next to the cost.
SPEAKER_00 (07:57):
This is where FinOps comes in.
And I want to talk about thisbecause I think it's underused
as a concept outside of cloudcost management.
Go on.
Finops, financial operations,started as a discipline for
managing cloud spend.
The core idea is that cloudcosts are variable and
(08:17):
distributed, and the only way tomanage them well is to give the
engineers, the finance team, andthe business leaders a shared
view of what things cost andwhat value they deliver.
But the underlying principleapplies to any shared technology
platform.
The FinOps Foundation'sframework is explicit about it.
(08:39):
The foundational principle isthat everyone takes ownership of
their usage.
And that only works if everyonecan see the cost of what they're
consuming.
SPEAKER_02 (08:48):
So applied to a shared data platform, what does
that look like practically?
SPEAKER_00 (08:53):
It looks like chargeback or showback.
Showback means every consumingdepartment gets a report.
Here's what you used, here'swhat it costs to run for you.
No money moves.
But the visibility is there.
Chargeback goes further.
The cost is actually allocatedto the consuming department's
(09:14):
budget.
Both models make the platform'svalue visible at the point where
it's consumed, rather thanburied in a central cost pool.
SPEAKER_02 (09:22):
And suddenly, the budget conversation changes.
Instead of the platform teamstanding up alone saying, please
don't cut our OPEX, you haveeight department heads who can
see exactly what they'd lose ifthe platform degraded.
Because it's on their costreport.
SPEAKER_00 (09:37):
And more importantly, the finance team
can see the total cost ofownership against the total
value delivered.
The platform team isn't makingan abstract argument anymore.
They're pointing to numbers.
SPEAKER_02 (09:50):
Which is the language that actually works in
a budget review?
This platform supports revenuefrom these use cases, reduces
manual effort across theseteams, is the foundation for
these three AI initiatives weapproved last year.
Cutting the run budget by 30%does this to those outcomes.
That's a decision.
(10:11):
We need money to keep the lightson, 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 visibilitymechanism, showback or
chargeback, making the valuevisible 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 aseat at the funding table, not
just the review table.
Because even if you fix the OPEXvisibility problem for existing
platforms, you'll keep buildingnew fragmentation if the
investment decision processstill funds use cases and
(10:52):
departments without anenterprise 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 beenfollowing, the architectural
review exists, the feedback isrecorded, the toll gate is
passed.
What doesn't exist is amechanism where that feedback
changes the funding decision.
Where a project that duplicatesan existing capability can be
redirected or held or requiredto use the enterprise platform.
(11:22):
Without that mechanism, thereview 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 architecturereviews that happen before
individual project fundinggates, not after.
Explicit exception processes forwhen a project needs to deviate
from the enterprisearchitecture, with a documented
consequence and a plan toresolve the divergence.
And critically, architectureinput into the early stage
(11:52):
funding gates, the ones thatrelease the first tranche of
capital.
Before the vendor is selected,before the team is assembled,
when the decision is still adecision.
SPEAKER_00 (12:02):
That last one is the one that's always missing.
Because the architecture reviewin 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 becomeschange management, not design
input.
SPEAKER_02 (12:21):
And it's not malicious, it's just the
sequence.
You fund the project, then youreview the architecture, then
you deliver.
If you want the architecture toshape the outcome, you need it
in the sequence before thefunding decision, not after.
SPEAKER_00 (12:35):
It also requires the architecture function to be
resourced to do that.
Because one of the reasonsarchitecture reviews become
rubber stamps is that thearchitecture team is stretched
across 20 projectssimultaneously and doesn't have
the capacity to do a realreview, let alone proactively
shape the portfolio.
SPEAKER_02 (12:55):
Which is itself a funding question.
If you want architecture tocreate value at the portfolio
level, you have to fund it atthe portfolio level, not as a
project overhead, as a standingenterprise capability with its
own budget, its own mandate, andits 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 theorganization one more time,
because there's a version ofthis story that ends well.
And I think it's important to beconcrete about what ends well
actually looks like.
Because it doesn't mean startingover, 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 atthe capability level.
What shared capabilities existtoday?
What does each one cost to run?
Which business units consumeeach one?
What are the three AI prioritiesthe organization has approved in
(13:57):
the last 12 months, and whichcapabilities do they depend on?
That map takes a few weeks tobuild, but it makes every
subsequent conversation aboutfragmentation, about OPEX cuts,
about which platforms to investin, concrete instead of
abstract.
SPEAKER_00 (14:14):
And it probably makes the three data platforms
problem visible in a way ithasn't been before.
Because right now, eachdepartment knows about their
platform.
Nobody has the enterprise view.
SPEAKER_02 (14:26):
Exactly.
The second thing I'd do is takethat map into the next budget
cycle, not at the end of thecycle, but at the start.
Use it to make the case thatthese three platforms should be
consolidated into one, that theconsolidation saves X in run
costs, and that the savings fundthe roadmap.
That's a business case.
(14:46):
It's not a technology project.
It's a strategic investment witha measurable return.
SPEAKER_00 (14:51):
And it changes the conversation from we need money
for platforms to here's wherewe're spending twice for no
additional value, and here's howwe stop.
SPEAKER_02 (15:01):
The third thing is harder and takes longer.
It's changing the governancesequence so that architecture
input comes before the fundinggate, not after the vendor
selection.
That's a change to the projectframework.
It requires political capital.
It requires the CIO or the CDOto own it visibly.
But it's the thing that preventsthe next fragmentation cycle
(15:24):
from starting before you'vefinished fixing this one.
SPEAKER_00 (15:27):
Because otherwise you fix the three platforms, and
18 months later you've got afourth one.
SPEAKER_02 (15:31):
Yep, you fix the three, and 18 months later,
someone has funded a new usecase 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 ofground across two episodes: the
operating model, the engagementmodel, the CapEx OpEx trap,
product funding, FinOps, thegovernance sequence.
What's the version of thisthat's actionable on Monday
morning?
SPEAKER_02 (15:58):
I'd give a leader five moves.
The first, ask for thecapability map, not the project
list, the capability map.
What shared platforms andservices exist, what they cost
to run, who depends on them.
If nobody can produce it, that'syour starting point.
The second, check thearchitecture review sequence.
Are architects in the roombefore funding gates or after?
(16:20):
If they're reviewing businesscases that are already approved,
they're annotating decisions,not shaping them.
One change to the sequence, onegate, early in the process
before vendor selection, changeseverything downstream.
The third?
Map your operating model bydomain.
Not the whole enterprise's oneanswer, but at the level of your
(16:41):
core data domains.
Customers, products, assets,operations.
Where do you need shared data?
Where can business units runtheir own processes?
If you can answer that questionby domain, you have the
foundation for a fundedarchitecture target state.
If you can't, the architectureteam is building against a
(17:01):
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 whatshared platforms cost and what
they deliver.
Do it before the annual review,not during it.
The goal is for the budgetconversation to be a decision,
(17:25):
not a surprise.
And the fifth?
Decide what a product lookslike.
Pick one platform, ideally theone most central to your AI
strategy, and fund it as aproduct.
Give it a roadmap, a team, alifecycle budget, and a set of
outcomes it's accountable for.
See what changes.
Use it as the model for therest.
SPEAKER_00 (17:46):
Those five things don't require a transformation
program.
They don't require a newframework.
They require a decision and afew process changes.
SPEAKER_02 (17:55):
Which is the point?
The reason this stuff doesn'tget fixed isn't usually that
it's too hard, it's that nobodyhas made it the leadership
team's problem.
It lives in IT, it lives in thearchitecture function, it lives
in the delivery teams who keeptrying to protect their
platforms and running out oflanguage to do it with.
The moment a CEO or a CFO asks,show me the capability map, it
(18:19):
gets made.
SPEAKER_00 (18:20):
And here's where I want to close the loop on
something.
In the data quality series, wespent two episodes on the
mechanics of dirty data, thedimensions, the failure modes,
the things that go wrong inpipelines and schemas and
governance controls.
And one of the things we keptcoming back to was the
producer-consumer gap.
(18:42):
The teams producing quality datadon't get funded.
The teams consuming it do.
Right.
What we've described in thesetwo episodes is where that gap
comes from.
It's not a data governanceproblem, it's an operating model
and funding design problem.
The producer-consumer gap iswhat happens when you have a
(19:02):
project-funded,department-budgeted,
architecture advisory enterprisethat hasn't made explicit
decisions about what must beshared, 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 theoperating model problem are the
same story.
Different entry points, samebuilding.
SPEAKER_00 (19:23):
It really is.
And I'll admit, two episodes agoI filed operating models under
Governance Admin and thoughtabout pipelines.
I remember.
And now I'm going to go home andmentally re-diagnose every data
quality problem I've ever fixedand 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 AIBeyond the Hype.
I'm James.
SPEAKER_00 (19:52):
And I'm Sarah.
If you've been in that budgetmeeting watching the platform
team lose an argument theyshould 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.
James, I've been thinking about how part one
ended.
SPEAKER_02 (00:09):
Good thoughts or bad thoughts?
SPEAKER_00 (00:11):
Unsettling thoughts.
You described a delivery teamthat did everything right, got
the operational budget approved,embedded it in the project
financials, delivered theplatform, and then watched it
get cut in the next OPEX reviewcycle by someone who didn't
understand what they werecutting.
SPEAKER_02 (00:32):
Right.
SPEAKER_00 (00:33):
And I keep coming back to the same question.
How does that happen?
The platform is running, thevalue is real, the budget was
approved.
What breaks?
SPEAKER_02 (00:45):
That's exactly where we're starting today.
Welcome back to AI Beyond theHype.
I'm James.
SPEAKER_00 (00:50):
And I'm Sarah.
Part two of two.
Last episode, James convinced methat most enterprise technology
fragmentation isn't a deliveryfailure, it's an operating model
problem.
Today we're going underneath themoney, how you fund foundations,
why the standard budget toolswork against you when you're
(01:11):
trying to sustain a sharedplatform.
And what a leadership team canactually do about it.
SPEAKER_02 (01:17):
And we're picking up the same organization we've been
following (01:19):
the one with three central data platforms, the
solid project framework, thearchitectural review toll gates
that don't bite.
The delivery team did the rightthing with the budget.
And then the annual cycle killedit.
SPEAKER_00 (01:34):
So walk me through the mechanics.
Why does that happen?
SPEAKER_02 (01:38):
Okay, let's start with CapEx and OPEX, because I
think this is one of thoseconcepts that everybody in a
leadership meeting nods at, andfewer people really understand
the trap inside it.
SPEAKER_00 (01:48):
Set it up.
SPEAKER_02 (01:49):
So capital expenditure, CapEx, is money
spent building or acquiring anasset.
Under accounting standards likeIAS38, you can capitalise
development costs, spread themover the asset's useful life
rather than hitting the PL allat once.
Which means building a newplatform looks on paper like an
investment.
(02:09):
It goes on the balance sheet.
It gets amortized over three tofive years.
SPEAKER_00 (02:14):
Which makes it easier to get approved.
Because you're not taking a bigPL hit in year one.
SPEAKER_02 (02:20):
Exactly.
And operational expenditure,OPEX, is the ongoing cost of
running and maintaining what youbuilt.
Under the same accountingstandards, once the asset is
live, maintenance costs getexpensed immediately.
They hit the P and L in theperiod they're incurred.
No spreading, no deferral.
SPEAKER_00 (02:39):
So the build looks like an investment, the run
looks like a cost.
SPEAKER_02 (02: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 approvedthrough the project framework,
business case, architecturereview, funding gate, the whole
(03:03):
machinery.
And then its ongoing OPEX issitting in a completely separate
bucket that gets reviewed at theend of the financial year,
alongside every otheroperational line item in the
business.
SPEAKER_00 (03:14):
And the people reviewing that list at the end
of the year don't necessarilyknow which line items are cut
the coffee subscription andwhich ones are cut the run cost
for a shared platform that eightprojects depend on.
SPEAKER_02 (03:28):
That is exactly the problem.
And it's structural.
The project framework isdesigned to govern capital
investment decisions.
It's not designed to govern theongoing operational commitment
that the capital investmentcreates.
So there's a gap between theCapEx approval that funds the
build and the OPEX reality thatfunds the run.
And in most organizations,nothing formally bridges that
(03:50):
gap.
SPEAKER_00 (03:51):
Which means the platform team is making the case
for their operational budgetevery year from scratch, in a
process that wasn't designed tounderstand their value.
SPEAKER_02 (04:00):
From scratch against everyone else's operational line
items.
Without the language or thevisibility to make the arguments
stick.
And here's what makes it worse: the value of a shared platform (04:09):
undefined
is diffuse.
It benefits multipledepartments, but the cost sits
in one place.
So when the cuts come, theplatform team can't point to a
single business unit that willvisibly suffer.
Everyone loses a little, nobodyloses enough to stand up and
block it.
SPEAKER_00 (04: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 carrythe cost.
The teams consuming it carry thebenefit.
And those two things almostnever sit on the same PL.
SPEAKER_02 (04: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 operationalbudgets are managed in most
large organizations.
The producer team's OPEX landsin a central cost pool.
The consumer team's businesscases are built on the value
they get from consuming it.
(05:11):
When the budget cycle hits, theconsumer teams are fighting for
their own projects.
The producer team is fightingalone.
SPEAKER_00 (05:19):
So what's the fix?
Because restructure how allenterprises manage their
accounting is not a Mondaymorning move.
SPEAKER_02 (05:27):
No, it's not.
But there are three things aleadership team can do that
don't require rewriting thechart of accounts.
The first is to shift the mentalmodel from projects to products,
and I mean that in a specificsense.
A project has a defined scope, adefined end date, a defined team
that disbands when it's done.
(05:48):
It's optimized for delivery.
A product has an ongoingroadmap, an ongoing team, and a
lifecycle that lasts as long asthe product delivers value.
It's optimized for sustainedoutcomes.
SPEAKER_00 (06:01):
And a shared data platform, a real foundation
layer platform, is a product,not a project.
SPEAKER_02 (06:08):
It's a product.
It evolves.
It needs investment afterGoLive, not just maintenance.
New use cases come in, securityrequirements 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 (06:27):
McKinse published something on this a couple of
years ago.
The product operating model.
The finding was that companiesthat fund and structure
technology as products ratherthan projects tend to realize
significantly higher returns ontheir technology investment.
Not because the technology isbetter, because the sustained
(06:49):
funding model means thetechnology keeps improving
rather than degrading after golive.
SPEAKER_02 (06:55):
And it changes the accountability structure.
A product team has a mandate.
Here's what this platform issupposed to deliver, here's how
we measure it, here's theongoing budget tied to those
outcomes.
That's a very differentconversation to have in a budget
review than we need OPEX to keepthe lights on.
SPEAKER_00 (07:12):
So what does that look like in practice for the
organization we've beenfollowing?
Because they're alreadymid-flight, they've got three
platforms, they've got theproject framework, they've got
the budget structure they have.
How do you shift from here?
SPEAKER_02 (07:27):
You start with visibility.
Which brings me to the secondfix: making platform value
explicit before the budgetcycle, not during it.
The reason platform OPEX getscut is almost always the same.
Nobody has made the case forwhat it's worth, in terms that a
finance team can engage withbefore the review starts.
(07:48):
The platform team knows thevalue.
The consuming teams know thevalue, but that value has never
been aggregated, quantified, andplaced next to the cost.
SPEAKER_00 (07:57):
This is where FinOps comes in.
And I want to talk about thisbecause I think it's underused
as a concept outside of cloudcost management.
Go on.
Finops, financial operations,started as a discipline for
managing cloud spend.
The core idea is that cloudcosts are variable and
(08:17):
distributed, and the only way tomanage them well is to give the
engineers, the finance team, andthe business leaders a shared
view of what things cost andwhat value they deliver.
But the underlying principleapplies to any shared technology
platform.
The FinOps Foundation'sframework is explicit about it.
(08:39):
The foundational principle isthat everyone takes ownership of
their usage.
And that only works if everyonecan see the cost of what they're
consuming.
SPEAKER_02 (08:48):
So applied to a shared data platform, what does
that look like practically?
SPEAKER_00 (08:53):
It looks like chargeback or showback.
Showback means every consumingdepartment gets a report.
Here's what you used, here'swhat it costs to run for you.
No money moves.
But the visibility is there.
Chargeback goes further.
The cost is actually allocatedto the consuming department's
(09:14):
budget.
Both models make the platform'svalue visible at the point where
it's consumed, rather thanburied in a central cost pool.
SPEAKER_02 (09:22):
And suddenly, the budget conversation changes.
Instead of the platform teamstanding up alone saying, please
don't cut our OPEX, you haveeight department heads who can
see exactly what they'd lose ifthe platform degraded.
Because it's on their costreport.
SPEAKER_00 (09:37):
And more importantly, the finance team
can see the total cost ofownership against the total
value delivered.
The platform team isn't makingan abstract argument anymore.
They're pointing to numbers.
SPEAKER_02 (09:50):
Which is the language that actually works in
a budget review?
This platform supports revenuefrom these use cases, reduces
manual effort across theseteams, is the foundation for
these three AI initiatives weapproved last year.
Cutting the run budget by 30%does this to those outcomes.
That's a decision.
(10:11):
We need money to keep the lightson, 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 visibilitymechanism, showback or
chargeback, making the valuevisible 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 aseat at the funding table, not
just the review table.
Because even if you fix the OPEXvisibility problem for existing
platforms, you'll keep buildingnew fragmentation if the
investment decision processstill funds use cases and
(10:52):
departments without anenterprise 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 beenfollowing, the architectural
review exists, the feedback isrecorded, the toll gate is
passed.
What doesn't exist is amechanism where that feedback
changes the funding decision.
Where a project that duplicatesan existing capability can be
redirected or held or requiredto use the enterprise platform.
(11:22):
Without that mechanism, thereview 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 architecturereviews that happen before
individual project fundinggates, not after.
Explicit exception processes forwhen a project needs to deviate
from the enterprisearchitecture, with a documented
consequence and a plan toresolve the divergence.
And critically, architectureinput into the early stage
(11:52):
funding gates, the ones thatrelease the first tranche of
capital.
Before the vendor is selected,before the team is assembled,
when the decision is still adecision.
SPEAKER_00 (12:02):
That last one is the one that's always missing.
Because the architecture reviewin 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 becomeschange management, not design
input.
SPEAKER_02 (12:21):
And it's not malicious, it's just the
sequence.
You fund the project, then youreview the architecture, then
you deliver.
If you want the architecture toshape the outcome, you need it
in the sequence before thefunding decision, not after.
SPEAKER_00 (12:35):
It also requires the architecture function to be
resourced to do that.
Because one of the reasonsarchitecture reviews become
rubber stamps is that thearchitecture team is stretched
across 20 projectssimultaneously and doesn't have
the capacity to do a realreview, let alone proactively
shape the portfolio.
SPEAKER_02 (12:55):
Which is itself a funding question.
If you want architecture tocreate value at the portfolio
level, you have to fund it atthe portfolio level, not as a
project overhead, as a standingenterprise capability with its
own budget, its own mandate, andits 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 theorganization one more time,
because there's a version ofthis story that ends well.
And I think it's important to beconcrete about what ends well
actually looks like.
Because it doesn't mean startingover, 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 atthe capability level.
What shared capabilities existtoday?
What does each one cost to run?
Which business units consumeeach one?
What are the three AI prioritiesthe organization has approved in
(13:57):
the last 12 months, and whichcapabilities do they depend on?
That map takes a few weeks tobuild, but it makes every
subsequent conversation aboutfragmentation, about OPEX cuts,
about which platforms to investin, concrete instead of
abstract.
SPEAKER_00 (14:14):
And it probably makes the three data platforms
problem visible in a way ithasn't been before.
Because right now, eachdepartment knows about their
platform.
Nobody has the enterprise view.
SPEAKER_02 (14:26):
Exactly.
The second thing I'd do is takethat map into the next budget
cycle, not at the end of thecycle, but at the start.
Use it to make the case thatthese three platforms should be
consolidated into one, that theconsolidation saves X in run
costs, and that the savings fundthe roadmap.
That's a business case.
(14:46):
It's not a technology project.
It's a strategic investment witha measurable return.
SPEAKER_00 (14:51):
And it changes the conversation from we need money
for platforms to here's wherewe're spending twice for no
additional value, and here's howwe stop.
SPEAKER_02 (15:01):
The third thing is harder and takes longer.
It's changing the governancesequence so that architecture
input comes before the fundinggate, not after the vendor
selection.
That's a change to the projectframework.
It requires political capital.
It requires the CIO or the CDOto own it visibly.
But it's the thing that preventsthe next fragmentation cycle
(15:24):
from starting before you'vefinished fixing this one.
SPEAKER_00 (15:27):
Because otherwise you fix the three platforms, and
18 months later you've got afourth one.
SPEAKER_02 (15:31):
Yep, you fix the three, and 18 months later,
someone has funded a new usecase 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 ofground across two episodes: the
operating model, the engagementmodel, the CapEx OpEx trap,
product funding, FinOps, thegovernance sequence.
What's the version of thisthat's actionable on Monday
morning?
SPEAKER_02 (15:58):
I'd give a leader five moves.
The first, ask for thecapability map, not the project
list, the capability map.
What shared platforms andservices exist, what they cost
to run, who depends on them.
If nobody can produce it, that'syour starting point.
The second, check thearchitecture review sequence.
Are architects in the roombefore funding gates or after?
(16:20):
If they're reviewing businesscases that are already approved,
they're annotating decisions,not shaping them.
One change to the sequence, onegate, early in the process
before vendor selection, changeseverything downstream.
The third?
Map your operating model bydomain.
Not the whole enterprise's oneanswer, but at the level of your
(16:41):
core data domains.
Customers, products, assets,operations.
Where do you need shared data?
Where can business units runtheir own processes?
If you can answer that questionby domain, you have the
foundation for a fundedarchitecture target state.
If you can't, the architectureteam is building against a
(17:01):
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 whatshared platforms cost and what
they deliver.
Do it before the annual review,not during it.
The goal is for the budgetconversation to be a decision,
(17:25):
not a surprise.
And the fifth?
Decide what a product lookslike.
Pick one platform, ideally theone most central to your AI
strategy, and fund it as aproduct.
Give it a roadmap, a team, alifecycle budget, and a set of
outcomes it's accountable for.
See what changes.
Use it as the model for therest.
SPEAKER_00 (17:46):
Those five things don't require a transformation
program.
They don't require a newframework.
They require a decision and afew process changes.
SPEAKER_02 (17:55):
Which is the point?
The reason this stuff doesn'tget fixed isn't usually that
it's too hard, it's that nobodyhas made it the leadership
team's problem.
It lives in IT, it lives in thearchitecture function, it lives
in the delivery teams who keeptrying to protect their
platforms and running out oflanguage to do it with.
The moment a CEO or a CFO asks,show me the capability map, it
(18:19):
gets made.
SPEAKER_00 (18:20):
And here's where I want to close the loop on
something.
In the data quality series, wespent two episodes on the
mechanics of dirty data, thedimensions, the failure modes,
the things that go wrong inpipelines and schemas and
governance controls.
And one of the things we keptcoming back to was the
producer-consumer gap.
(18:42):
The teams producing quality datadon't get funded.
The teams consuming it do.
Right.
What we've described in thesetwo episodes is where that gap
comes from.
It's not a data governanceproblem, it's an operating model
and funding design problem.
The producer-consumer gap iswhat happens when you have a
(19:02):
project-funded,department-budgeted,
architecture advisory enterprisethat hasn't made explicit
decisions about what must beshared, 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 theoperating model problem are the
same story.
Different entry points, samebuilding.
SPEAKER_00 (19:23):
It really is.
And I'll admit, two episodes agoI filed operating models under
Governance Admin and thoughtabout pipelines.
I remember.
And now I'm going to go home andmentally re-diagnose every data
quality problem I've ever fixedand 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 AIBeyond the Hype.
I'm James.
SPEAKER_00 (19:52):
And I'm Sarah.
If you've been in that budgetmeeting watching the platform
team lose an argument theyshould 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.
Popular Podcasts
Betrayal Weekly
Betrayal Weekly is back for a new season. Every Thursday, Betrayal Weekly shares first-hand accounts of broken trust, shocking deceptions, and the trail of destruction they leave behind. Hosted by Andrea Gunning, this weekly ongoing series digs into real-life stories of betrayal and the aftermath. From stories of double lives to dark discoveries, these are cautionary tales and accounts of resilience against all odds. From the producers of the critically acclaimed Betrayal series, Betrayal Weekly drops new episodes every Thursday. If you would like to share your story, you can reach out to the Betrayal Team by emailing them at betrayalpod@gmail.com and follow us on Instagram at @betrayalpod and @glasspodcasts. Please join our Substack for additional exclusive content, curated book recommendations, and community discussions. Sign up FREE by clicking this link Beyond Betrayal Substack. Join our community dedicated to truth, resilience, and healing. Your voice matters! Be a part of our Betrayal journey on Substack.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.