June 29, 2026 • 23 mins
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.
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
SPEAKER_00 (00:06):
Sarah, I have to be honest with you, I've been
looking forward to this episodefor a while.
SPEAKER_01 (00:10):
I know.
You mentioned it twice lastweek.
SPEAKER_00 (00:14):
Operating models, engagement frameworks, portfolio
alignment.
This is the stuff that actuallymakes or breaks an enterprise.
SPEAKER_01 (00:22):
Hmm, can't wait.
SPEAKER_00 (00:24):
You're not excited.
SPEAKER_01 (00:25):
James, you sent me a reading list.
It had 11 items on it.
One of them was a textbook.
SPEAKER_00 (00:32):
It's a very good textbook.
SPEAKER_01 (00:34):
I'm sure it is.
I just.
Look, I spend my days in datapipelines.
I care deeply about whether yourdata lands clean, whether your
schemas are versioned, whetheryour quality controls actually
fire.
Operating models feel like thePowerPoint that lives two floors
above the actual problem.
SPEAKER_00 (00: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 youwith the framework up front.
I'm going to tell you about anorganization I've spent time
with.
And by the time I'm done, you'regoing to tell me the operating
model is the problem.
Deal?
SPEAKER_01 (01:11):
Sure.
Um deal.
SPEAKER_00 (01:13):
That was not a confident deal.
SPEAKER_01 (01:16):
It was a conditional deal.
Let's hear the scenario.
SPEAKER_00 (01:19):
Right.
So I want to keep oneorganization in mind as we go
through this episode.
I'm not going to name them, butI've spent time with a large
enterprise that has a genuinelywell-defined project management
framework.
Not a PowerPoint framework, areal one.
It covers agile and traditionaldelivery.
It has documented keydeliverables, clear processes,
(01:41):
defined toll gates at everystage.
SPEAKER_01 (01:44):
That's actually rarer than it should be.
SPEAKER_00 (01:47):
Agreed.
And here's the thing.
The framework even includesarchitectural design reviews.
There is a formal toll gatewhere architecture has to sign
off before a project proceeds.
SPEAKER_01 (01:57):
Okay, so that sounds like they've got the machinery
in place.
What's the problem?
SPEAKER_00 (02:02):
They currently have at least three separate central
data platforms.
SPEAKER_01 (02:07):
Three.
SPEAKER_00 (02:08):
Three.
Built by different departmentsindependently over time, each
one described internally as thedata platform.
With overlapping scope,duplicated data, no common
security controls, and genuineconfusion about which one is the
source of truth for any givendata set.
SPEAKER_01 (02:27):
How does that happen when you have architectural
review toll gates?
SPEAKER_00 (02:32):
That's exactly the right question.
And the answer to it is whatthis whole episode is about.
Welcome to AI.
SPEAKER_01 (02:41):
And I'm Sarah.
Part one of two on operatingmodels and foundations.
Today we're starting with thething James keeps calling
upstream of everything.
I'm going to be skeptical untilhe convinces me.
SPEAKER_00 (02:56):
Fair.
Okay, so let me start with aconcept that I think a lot of
executives have heard and fewerhave actually sat with.
The operating model.
And I mean this in a specificsense, not the generic how our
business operates sense.
I mean it as a strategic choice.
How much do our business unitsneed to run the same processes?
(03:17):
And how much do they need toshare data?
SPEAKER_01 (03:19):
Those feel like two very different questions.
SPEAKER_00 (03:22):
They are.
And the framework that I keepcoming back to.
It's from three researchers atMIT, Ross, Weill, and Robertson.
It puts those two questions ontwo axes.
Standardization.
How much do we want processes tolook the same across the
enterprise?
And integration.
How much does one part of thebusiness depend on data from
(03:44):
another part?
Cross those axes and you getfour operating model types.
SPEAKER_01 (03:50):
Walk me through them.
SPEAKER_00 (03:51):
So at one end you've got what they call
diversification, lowstandardization, low
integration.
Business units operatingbasically independently, serving
different markets, differentcustomers.
A conglomerate that owns amining business, a media
company, and a logistics arm.
Those businesses might share abalance sheet, but they don't
(04:13):
need each other's data to dotheir jobs.
SPEAKER_01 (04:15):
So a shared data platform there would be mostly
overhead.
SPEAKER_00 (04:19):
Mostly, yes.
You'd fund shared enterprisecontrols, security, finance
consolidation, compliance, butyou'd be careful about imposing
platforms where there's no realdependency.
The opposite corner isunification, high
standardization, highintegration, common processes,
shared data, tightlyinterdependent business units.
(04:41):
Think a bank with a singlecustomer record, or an airline,
one seat on one plane, onebooking system, one revenue
network.
SPEAKER_01 (04:48):
And that's where you'd invest heavily in
enterprise-grade foundations.
Because the whole operatingmodel depends on them.
SPEAKER_00 (04:55):
Exactly.
And in between, you've gotcoordination, where business
units keep their own processesbut really do need to share
data.
Customer data, product data,asset data.
The units are independent, butthey need a common view.
And replication, where theprocesses themselves are
standardized, like a franchiseor a retail chain running the
(05:16):
same model across hundreds ofsites, but the sites don't need
each other's data in real time.
SPEAKER_01 (05:21):
So the operating model tells you what
architecture you actually need.
SPEAKER_00 (05:26):
That's the key move.
The operating model is upstreamof the architecture.
It tells you what must becommon, what can vary, what
needs to be shared, and what canstay local.
And I want to be clear aboutsomething here.
None of this applies equally toevery organization.
A 50-person company with oneproduct line doesn't need an
(05:46):
enterprise architecturefunction.
They need good engineers andclear priorities.
The overhead of formal operatingmodel design would slow them
down more than it would helpthem.
SPEAKER_01 (05:57):
So when does it start to matter?
SPEAKER_00 (05:59):
When you grow, when you add departments, when you
add geographies or businessunits.
When the number of technologydecisions being made
simultaneously, by differentteams, in different rooms,
against different localpriorities, gets large enough
that no single person can seeacross all of them.
There's a body of research onthis that's pretty consistent.
(06:21):
Organizational complexity drivestechnology complexity.
And the organizations that don'thave formal architecture
management are the ones that seethat complexity compound fastest
as they scale.
PWC did a global study on this.
The finding was that managingcomplexity stays manageable up
to a point, and then it doesn't.
(06:43):
EA becomes the mechanism thatkeeps the technology landscape
coherent when the organizationcan no longer rely on one person
knowing everything.
SPEAKER_01 (06:51):
So it's not about being bureaucratic, it's about
the information problem thatcomes with size.
SPEAKER_00 (06:57):
Exactly.
When you're small, alignment isinformal.
You walk across the office.
When you have 500 people acrossmultiple departments and you're
running 30 projects in parallel,informal alignment doesn't
scale.
You need structure.
And the cost of not having itisn't obvious on day one.
It compounds quietly.
(07:17):
A duplicate platform here, aninconsistent data definition
there, until you surface theissue and realize you've been
paying for the same thing threetimes.
SPEAKER_01 (07:27):
Which brings us back to the three central data
platforms.
SPEAKER_00 (07:31):
It always does.
Without that operating modelchoice being made explicitly,
you end up with every projectteam making their own call, and
you end up with three dataplatforms.
SPEAKER_01 (07:41):
Okay, so walk me through why the organization you
mentioned ends up there.
Because they're not making nochoices.
They have a framework, they havetoll gates, they have
architectural reviews.
SPEAKER_00 (07:53):
Right, and here's where it gets interesting.
The organization has themachinery.
What it doesn't have is theoperating model made explicit.
So when a department comes inwith a project, the
architectural review happens,but it's happening against a
target state that isn't fullydefined.
The architects can say, thislooks like it duplicates
(08:14):
something, and they do say that,in writing, in the review.
But the feedback goes into therecord, the toll gate gets
passed, and nobody checkswhether the feedback was acted
on once the project moves intodelivery.
SPEAKER_01 (08:26):
The toll gate clears, and then the review just
stops.
SPEAKER_00 (08:31):
Stops.
And here's the funding dynamicthat makes it worse.
Budgets are held by regional andfunctional teams.
The project sponsor is in thebusiness.
When there's a conflict betweenthe architect said we should use
the enterprise platform, and theenterprise platform doesn't
quite fit our use case and it'llslow us down by three months,
(08:51):
the business team makes thecall.
SPEAKER_01 (08:53):
Because they hold the budget.
SPEAKER_00 (08:55):
Because they hold the budget.
And the architect can raiseconcerns, but they don't have a
seat at the funding table.
They have a seat at the reviewtable.
Those are different seats.
SPEAKER_01 (09:06):
So architecture governance without funding power
is just advice.
SPEAKER_00 (09:11):
MITCISR.
The research center at MIT thatproduced the framework I
mentioned, they actually namethis specifically.
The management practices thatlet architecture create real
value are things liketransparent technology costs,
explicit architecture exceptiondebates, and critically, making
(09:32):
investment decisions withenterprise architecture in mind.
Not architecture as a reviewstep, architecture as part of
the capital allocation decision.
SPEAKER_01 (09:41):
That's a meaningful distinction.
Because in most of theorganizations I've worked with,
the architecture review is agate.
You submit, you get feedback,you proceed.
Nobody tracks whether thefeedback changed the outcome.
SPEAKER_00 (09:56):
And the result, over time, is what I'd call portfolio
fragmentation.
Every department plans its workindependently.
There's no enterprisearchitecture function that
shapes the portfolio, that looksacross all the projects and
says, these three are doing thesame thing.
Let's align them.
Or this project needs a sharedcapability that doesn't exist
yet.
(10:16):
We need to sequence thefoundation first.
Instead, you get pointsolutions.
Department A builds their owndata extract.
Department B builds their own.
Department C builds theirs.
Each one is locally rational.
Together, they createduplication.
They create inconsistent data.
And when you try to apply agovernance control, a security
(10:38):
policy, a data classification,an access rule, you have to
apply it three times to threedifferent systems.
SPEAKER_01 (10:46):
And then someone comes in trying to do AI and
they ask, what's the source oftruth 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 tryingto 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 dataproblems that looked like
engineering failures, pipelinesmisconfigured, schemas
diverging, quality controlsmissing, and I've always treated
them as things to fix at theplatform level.
But what you're describing isthat those engineering failures
(11:23):
are downstream symptoms of adecision that was never made
above the platform level.
SPEAKER_00 (11:28):
That's exactly it.
The wiring can't be right ifnobody decided what the building
is supposed to do.
SPEAKER_01 (11:34):
Okay, you've convinced me.
This is upstream of thepipelines.
I'll take the win!
SPEAKER_00 (11:40):
So let's go a layer deeper into why the architecture
tollgate fails even when itexists.
Because I want to name a conceptthat 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 operatingmodel and the enterprise
architecture.
The engagement model is thesystem of governance mechanisms
that ensures projects achieveboth local objectives and
enterprise objectives.
In plain language, it's howarchitecture, portfolio
(12:18):
management, funding, anddelivery 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 gateactually change the investment
decision?
SPEAKER_00 (12:31):
Right.
And the reason this matters isthat architecture governance is
often experienced as frictionwhen it's detached from
enablement and funding.
If a project team is told, usethe shared platform, but the
shared platform doesn't havecapacity, or doesn't have
documentation, or doesn't have aservice level they can rely on,
(12:51):
they'll bypass it.
Locally rational, globallyfragmenting.
SPEAKER_01 (12:56):
I've seen that.
We would have used theenterprise tool, but it didn't
support our use case.
And by the time that feedbackmakes it back to the platform
team, the project's already indelivery with a point solution.
SPEAKER_00 (13:09):
And here's the other side of it.
Funding signals are thestrongest signal in any
organization of what's actuallyvalued.
If the enterprise funds usecases but not platforms, it's
signaling that it values localdelivery over reuse.
If it funds the build of aplatform but not the ongoing
run, it's signaling that itvalues launch over reliability.
(13:32):
Those signals aren't alwaysintentional.
They often emerge from how theannual 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 notincompetence on the part of the
teams who built them.
Each one of those teams wasresponding rationally to the
signals they were given.
SPEAKER_00 (13:53):
Exactly.
And to be clear about theorganization I've been
describing, these are goodpeople, smart people.
The project managers, thedepartment heads, the architects
who wrote those review comments,they all care.
It's not negligence, it's a gapbetween how the system was
designed and the conditions thatwould let the system actually
function as intended.
(14:15):
The framework says architectureshould guide portfolio
decisions.
The funding mechanism says thebusiness 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 instinctwhen you see three data
platforms is to say somebodydropped the ball.
And what you're saying is theball was always going to drop
because of how the system wasset up.
SPEAKER_00 (14:41):
It's a systemic failure, not an individual one.
And the fix is systemic, whichis why it has to start with the
operating model.
You can't fix the engagementmodel if you haven't made the
operating model explicit.
Because the engagement model iswhat makes the operating model
real.
It's how the strategic choice,we need data integration across
(15:03):
these domains, becomes a fundedplatform, 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 CDOlistening to this, and I'm
worried that my organization hasthis 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 manyquestion.
How many central versions of thesame capability do you currently
run?
How many integration platforms?
How many data platforms?
How many single sources of truthfor your core entities,
customers, products, assets,suppliers?
(15:44):
If the answer to any of those ismore 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, butnobody's checking whether it was
implemented after the tollgatecleared, that's the same problem
from a different angle.
SPEAKER_00 (16:30):
Exactly right.
And the third signal is theoperating model question itself.
Can your chief architect or yourCIO or your CDO explain your
operating model by domain?
Not the whole enterprise as oneanswer.
But at the level of, in ourcustomer domain, we're in
coordination.
We need shared data, but ourbusiness units can run different
(16:52):
processes.
If nobody can answer thatquestion, the architecture has
no foundation to build against.
It's just preferences andprecedents.
SPEAKER_01 (17:00):
And here's what makes this urgent now
specifically.
Because a lot of organizationsare in the middle of laying
their AI strategy on top ofthis.
They're approving AI programs,they're running pilots, they're
moving use cases intoproduction.
And the question of what's thesource of truth for this data,
or which platform do we actuallytrust, those questions are going
(17:24):
to get asked every single timean AI model produces an output
that doesn't match what someoneexpected.
SPEAKER_00 (17:31):
And the organization without an explicit operating
model will answer that questionin a different way every time
it's asked.
Because the answer depends onwhich data platform you happened
to use.
Which is not a place you want tobe when a regulator or a board
asks, how do we know thismodel'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 whatthis looks like when it goes
right.
Because I don't want thisepisode to sound like enterprise
architecture is the answer toeverything.
It isn't.
But there are organizations thatgot this right, and the pattern
is consistent.
Who are you thinking of?
DBS Bank is the clearest exampleI keep coming back to.
(18:17):
They made a deliberate choice torestructure their technology
delivery around 33 platforms,each aligned to a business
segment, each jointly led bybusiness and technology through
what they called a two-in-a-boxmodel.
A business leader and atechnology leader owning the
same platform together.
SPEAKER_01 (18:36):
So architecture and business ownership were joined
from the start, not architecturereviewing after business had
already decided.
SPEAKER_00 (18:45):
Joined from the start.
Not because their models werebetter, 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'sattention.
SPEAKER_00 (19:05):
It's the kind of number that turns a foundation
investment from overhead intocompetitive advantage.
And here's the thing about UPS.
Similar story, different domain.
They built a root optimizationsystem called Orion that
produced enormous savings infuel and miles driven.
But Orion didn't appear fromnowhere.
(19:25):
It was built on top of years ofinvestment in unified
operational data, standardizedpackage data, standardized route
data, standardized network data.
The AI was the harvest.
The foundation was the years ofboring, unglamorous data work
that came before it.
(19:54):
And in both cases, DBS UPS, theoperating model choice was made
explicitly.
Not as a slide, as a funded,governed, sequenced set of
decisions about what had to becommon, what could vary, and
what needed to be shared acrossthe 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 theoperating model choice made
explicitly enough to drive thefunding decisions.
SPEAKER_00 (20:27):
Right.
And there's a consequence ofthat which we haven't touched on
yet.
It comes down to the operationalbudget.
Tell me.
So a delivery team works hard,genuinely hard, to get ongoing
operational expenditure into theproject financials.
They know the platform needs tobe sustained after Go Live.
They build the numbers into thebusiness case.
(20:48):
They get it approved.
The project delivers, theplatform launches, the
operational budget is embeddedin 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 operationalbudget review hits, and there's
a sweeping cost reductiontarget.
And someone, not the projectteam, not the architects, not
the platform owner, someone in abudget function looks at a list
of operational line items andmakes a cut.
Without understanding which ofthose line items is the run cost
(21:20):
for a shared platform thatmultiple projects are now
depending on.
SPEAKER_01 (21:24):
And the platform starts degrading.
Support gets reduced.
Monitoring gets cut.
The security controls that weresupposed to be applied
enterprise-wide suddenly have noteam maintaining them.
SPEAKER_00 (21:36):
And the people who know the platform team, they
don't have the language to fightback.
Because the platform's value isdistributed, every department
that uses it benefits, but nosingle department's PL captures
that benefit.
So when the budget cut happens,no single sponsor stands up and
says, if you cut that, you'recutting mine.
(21:57):
Everyone loses a little.
Nobody loses enough to force theissue.
SPEAKER_01 (22:02):
That's the funding design problem, not negligence.
The platform's value is real.
It just isn't visible in theright place at the right time.
SPEAKER_00 (22:12):
And that is exactly where we're going in part two.
Because what I've describedtoday is the diagnosis, the
operating model that was neverchosen explicitly, the
architecture governance that hasno funding power, the portfolio
that fragments by default.
Part two is about the money.
How you fund foundations so theydon't degrade.
(22:33):
Why the Capex OpEx distinctioncreates a specific kind of trap
for technology leaders, and whata real life cycle funding model
looks like.
Because the fix isn't moregovernance ceremonies, the fix
is changing what you fund andhow.
SPEAKER_01 (22:48):
And can I just say, I came into this episode
planning to be skeptical, andI'm leaving it genuinely
unsettled.
Because I've fixed a lot of datapipelines and data quality
problems in my career, and whatyou'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 manytimes as you like.
Until you change the source.
Until you change the source.
Thanks for listening to AIBeyond 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.
Sarah, I have to be honest with you, I've been
looking forward to this episodefor a while.
SPEAKER_01 (00:10):
I know.
You mentioned it twice lastweek.
SPEAKER_00 (00:14):
Operating models, engagement frameworks, portfolio
alignment.
This is the stuff that actuallymakes or breaks an enterprise.
SPEAKER_01 (00:22):
Hmm, can't wait.
SPEAKER_00 (00:24):
You're not excited.
SPEAKER_01 (00:25):
James, you sent me a reading list.
It had 11 items on it.
One of them was a textbook.
SPEAKER_00 (00:32):
It's a very good textbook.
SPEAKER_01 (00:34):
I'm sure it is.
I just.
Look, I spend my days in datapipelines.
I care deeply about whether yourdata lands clean, whether your
schemas are versioned, whetheryour quality controls actually
fire.
Operating models feel like thePowerPoint that lives two floors
above the actual problem.
SPEAKER_00 (00: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 youwith the framework up front.
I'm going to tell you about anorganization I've spent time
with.
And by the time I'm done, you'regoing to tell me the operating
model is the problem.
Deal?
SPEAKER_01 (01:11):
Sure.
Um deal.
SPEAKER_00 (01:13):
That was not a confident deal.
SPEAKER_01 (01:16):
It was a conditional deal.
Let's hear the scenario.
SPEAKER_00 (01:19):
Right.
So I want to keep oneorganization in mind as we go
through this episode.
I'm not going to name them, butI've spent time with a large
enterprise that has a genuinelywell-defined project management
framework.
Not a PowerPoint framework, areal one.
It covers agile and traditionaldelivery.
It has documented keydeliverables, clear processes,
(01:41):
defined toll gates at everystage.
SPEAKER_01 (01:44):
That's actually rarer than it should be.
SPEAKER_00 (01:47):
Agreed.
And here's the thing.
The framework even includesarchitectural design reviews.
There is a formal toll gatewhere architecture has to sign
off before a project proceeds.
SPEAKER_01 (01:57):
Okay, so that sounds like they've got the machinery
in place.
What's the problem?
SPEAKER_00 (02:02):
They currently have at least three separate central
data platforms.
SPEAKER_01 (02:07):
Three.
SPEAKER_00 (02:08):
Three.
Built by different departmentsindependently over time, each
one described internally as thedata platform.
With overlapping scope,duplicated data, no common
security controls, and genuineconfusion about which one is the
source of truth for any givendata set.
SPEAKER_01 (02:27):
How does that happen when you have architectural
review toll gates?
SPEAKER_00 (02:32):
That's exactly the right question.
And the answer to it is whatthis whole episode is about.
Welcome to AI.
SPEAKER_01 (02:41):
And I'm Sarah.
Part one of two on operatingmodels and foundations.
Today we're starting with thething James keeps calling
upstream of everything.
I'm going to be skeptical untilhe convinces me.
SPEAKER_00 (02:56):
Fair.
Okay, so let me start with aconcept that I think a lot of
executives have heard and fewerhave actually sat with.
The operating model.
And I mean this in a specificsense, not the generic how our
business operates sense.
I mean it as a strategic choice.
How much do our business unitsneed to run the same processes?
(03:17):
And how much do they need toshare data?
SPEAKER_01 (03:19):
Those feel like two very different questions.
SPEAKER_00 (03:22):
They are.
And the framework that I keepcoming back to.
It's from three researchers atMIT, Ross, Weill, and Robertson.
It puts those two questions ontwo axes.
Standardization.
How much do we want processes tolook the same across the
enterprise?
And integration.
How much does one part of thebusiness depend on data from
(03:44):
another part?
Cross those axes and you getfour operating model types.
SPEAKER_01 (03:50):
Walk me through them.
SPEAKER_00 (03:51):
So at one end you've got what they call
diversification, lowstandardization, low
integration.
Business units operatingbasically independently, serving
different markets, differentcustomers.
A conglomerate that owns amining business, a media
company, and a logistics arm.
Those businesses might share abalance sheet, but they don't
(04:13):
need each other's data to dotheir jobs.
SPEAKER_01 (04:15):
So a shared data platform there would be mostly
overhead.
SPEAKER_00 (04:19):
Mostly, yes.
You'd fund shared enterprisecontrols, security, finance
consolidation, compliance, butyou'd be careful about imposing
platforms where there's no realdependency.
The opposite corner isunification, high
standardization, highintegration, common processes,
shared data, tightlyinterdependent business units.
(04:41):
Think a bank with a singlecustomer record, or an airline,
one seat on one plane, onebooking system, one revenue
network.
SPEAKER_01 (04:48):
And that's where you'd invest heavily in
enterprise-grade foundations.
Because the whole operatingmodel depends on them.
SPEAKER_00 (04:55):
Exactly.
And in between, you've gotcoordination, where business
units keep their own processesbut really do need to share
data.
Customer data, product data,asset data.
The units are independent, butthey need a common view.
And replication, where theprocesses themselves are
standardized, like a franchiseor a retail chain running the
(05:16):
same model across hundreds ofsites, but the sites don't need
each other's data in real time.
SPEAKER_01 (05:21):
So the operating model tells you what
architecture you actually need.
SPEAKER_00 (05:26):
That's the key move.
The operating model is upstreamof the architecture.
It tells you what must becommon, what can vary, what
needs to be shared, and what canstay local.
And I want to be clear aboutsomething here.
None of this applies equally toevery organization.
A 50-person company with oneproduct line doesn't need an
(05:46):
enterprise architecturefunction.
They need good engineers andclear priorities.
The overhead of formal operatingmodel design would slow them
down more than it would helpthem.
SPEAKER_01 (05:57):
So when does it start to matter?
SPEAKER_00 (05:59):
When you grow, when you add departments, when you
add geographies or businessunits.
When the number of technologydecisions being made
simultaneously, by differentteams, in different rooms,
against different localpriorities, gets large enough
that no single person can seeacross all of them.
There's a body of research onthis that's pretty consistent.
(06:21):
Organizational complexity drivestechnology complexity.
And the organizations that don'thave formal architecture
management are the ones that seethat complexity compound fastest
as they scale.
PWC did a global study on this.
The finding was that managingcomplexity stays manageable up
to a point, and then it doesn't.
(06:43):
EA becomes the mechanism thatkeeps the technology landscape
coherent when the organizationcan no longer rely on one person
knowing everything.
SPEAKER_01 (06:51):
So it's not about being bureaucratic, it's about
the information problem thatcomes with size.
SPEAKER_00 (06:57):
Exactly.
When you're small, alignment isinformal.
You walk across the office.
When you have 500 people acrossmultiple departments and you're
running 30 projects in parallel,informal alignment doesn't
scale.
You need structure.
And the cost of not having itisn't obvious on day one.
It compounds quietly.
(07:17):
A duplicate platform here, aninconsistent data definition
there, until you surface theissue and realize you've been
paying for the same thing threetimes.
SPEAKER_01 (07:27):
Which brings us back to the three central data
platforms.
SPEAKER_00 (07:31):
It always does.
Without that operating modelchoice being made explicitly,
you end up with every projectteam making their own call, and
you end up with three dataplatforms.
SPEAKER_01 (07:41):
Okay, so walk me through why the organization you
mentioned ends up there.
Because they're not making nochoices.
They have a framework, they havetoll gates, they have
architectural reviews.
SPEAKER_00 (07:53):
Right, and here's where it gets interesting.
The organization has themachinery.
What it doesn't have is theoperating model made explicit.
So when a department comes inwith a project, the
architectural review happens,but it's happening against a
target state that isn't fullydefined.
The architects can say, thislooks like it duplicates
(08:14):
something, and they do say that,in writing, in the review.
But the feedback goes into therecord, the toll gate gets
passed, and nobody checkswhether the feedback was acted
on once the project moves intodelivery.
SPEAKER_01 (08:26):
The toll gate clears, and then the review just
stops.
SPEAKER_00 (08:31):
Stops.
And here's the funding dynamicthat makes it worse.
Budgets are held by regional andfunctional teams.
The project sponsor is in thebusiness.
When there's a conflict betweenthe architect said we should use
the enterprise platform, and theenterprise platform doesn't
quite fit our use case and it'llslow us down by three months,
(08:51):
the business team makes thecall.
SPEAKER_01 (08:53):
Because they hold the budget.
SPEAKER_00 (08:55):
Because they hold the budget.
And the architect can raiseconcerns, but they don't have a
seat at the funding table.
They have a seat at the reviewtable.
Those are different seats.
SPEAKER_01 (09:06):
So architecture governance without funding power
is just advice.
SPEAKER_00 (09:11):
MITCISR.
The research center at MIT thatproduced the framework I
mentioned, they actually namethis specifically.
The management practices thatlet architecture create real
value are things liketransparent technology costs,
explicit architecture exceptiondebates, and critically, making
(09:32):
investment decisions withenterprise architecture in mind.
Not architecture as a reviewstep, architecture as part of
the capital allocation decision.
SPEAKER_01 (09:41):
That's a meaningful distinction.
Because in most of theorganizations I've worked with,
the architecture review is agate.
You submit, you get feedback,you proceed.
Nobody tracks whether thefeedback changed the outcome.
SPEAKER_00 (09:56):
And the result, over time, is what I'd call portfolio
fragmentation.
Every department plans its workindependently.
There's no enterprisearchitecture function that
shapes the portfolio, that looksacross all the projects and
says, these three are doing thesame thing.
Let's align them.
Or this project needs a sharedcapability that doesn't exist
yet.
(10:16):
We need to sequence thefoundation first.
Instead, you get pointsolutions.
Department A builds their owndata extract.
Department B builds their own.
Department C builds theirs.
Each one is locally rational.
Together, they createduplication.
They create inconsistent data.
And when you try to apply agovernance control, a security
(10:38):
policy, a data classification,an access rule, you have to
apply it three times to threedifferent systems.
SPEAKER_01 (10:46):
And then someone comes in trying to do AI and
they ask, what's the source oftruth 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 tryingto 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 dataproblems that looked like
engineering failures, pipelinesmisconfigured, schemas
diverging, quality controlsmissing, and I've always treated
them as things to fix at theplatform level.
But what you're describing isthat those engineering failures
(11:23):
are downstream symptoms of adecision that was never made
above the platform level.
SPEAKER_00 (11:28):
That's exactly it.
The wiring can't be right ifnobody decided what the building
is supposed to do.
SPEAKER_01 (11:34):
Okay, you've convinced me.
This is upstream of thepipelines.
I'll take the win!
SPEAKER_00 (11:40):
So let's go a layer deeper into why the architecture
tollgate fails even when itexists.
Because I want to name a conceptthat 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 operatingmodel and the enterprise
architecture.
The engagement model is thesystem of governance mechanisms
that ensures projects achieveboth local objectives and
enterprise objectives.
In plain language, it's howarchitecture, portfolio
(12:18):
management, funding, anddelivery 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 gateactually change the investment
decision?
SPEAKER_00 (12:31):
Right.
And the reason this matters isthat architecture governance is
often experienced as frictionwhen it's detached from
enablement and funding.
If a project team is told, usethe shared platform, but the
shared platform doesn't havecapacity, or doesn't have
documentation, or doesn't have aservice level they can rely on,
(12:51):
they'll bypass it.
Locally rational, globallyfragmenting.
SPEAKER_01 (12:56):
I've seen that.
We would have used theenterprise tool, but it didn't
support our use case.
And by the time that feedbackmakes it back to the platform
team, the project's already indelivery with a point solution.
SPEAKER_00 (13:09):
And here's the other side of it.
Funding signals are thestrongest signal in any
organization of what's actuallyvalued.
If the enterprise funds usecases but not platforms, it's
signaling that it values localdelivery over reuse.
If it funds the build of aplatform but not the ongoing
run, it's signaling that itvalues launch over reliability.
(13:32):
Those signals aren't alwaysintentional.
They often emerge from how theannual 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 notincompetence on the part of the
teams who built them.
Each one of those teams wasresponding rationally to the
signals they were given.
SPEAKER_00 (13:53):
Exactly.
And to be clear about theorganization I've been
describing, these are goodpeople, smart people.
The project managers, thedepartment heads, the architects
who wrote those review comments,they all care.
It's not negligence, it's a gapbetween how the system was
designed and the conditions thatwould let the system actually
function as intended.
(14:15):
The framework says architectureshould guide portfolio
decisions.
The funding mechanism says thebusiness 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 instinctwhen you see three data
platforms is to say somebodydropped the ball.
And what you're saying is theball was always going to drop
because of how the system wasset up.
SPEAKER_00 (14:41):
It's a systemic failure, not an individual one.
And the fix is systemic, whichis why it has to start with the
operating model.
You can't fix the engagementmodel if you haven't made the
operating model explicit.
Because the engagement model iswhat makes the operating model
real.
It's how the strategic choice,we need data integration across
(15:03):
these domains, becomes a fundedplatform, 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 CDOlistening to this, and I'm
worried that my organization hasthis 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 manyquestion.
How many central versions of thesame capability do you currently
run?
How many integration platforms?
How many data platforms?
How many single sources of truthfor your core entities,
customers, products, assets,suppliers?
(15:44):
If the answer to any of those ismore 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, butnobody's checking whether it was
implemented after the tollgatecleared, that's the same problem
from a different angle.
SPEAKER_00 (16:30):
Exactly right.
And the third signal is theoperating model question itself.
Can your chief architect or yourCIO or your CDO explain your
operating model by domain?
Not the whole enterprise as oneanswer.
But at the level of, in ourcustomer domain, we're in
coordination.
We need shared data, but ourbusiness units can run different
(16:52):
processes.
If nobody can answer thatquestion, the architecture has
no foundation to build against.
It's just preferences andprecedents.
SPEAKER_01 (17:00):
And here's what makes this urgent now
specifically.
Because a lot of organizationsare in the middle of laying
their AI strategy on top ofthis.
They're approving AI programs,they're running pilots, they're
moving use cases intoproduction.
And the question of what's thesource of truth for this data,
or which platform do we actuallytrust, those questions are going
(17:24):
to get asked every single timean AI model produces an output
that doesn't match what someoneexpected.
SPEAKER_00 (17:31):
And the organization without an explicit operating
model will answer that questionin a different way every time
it's asked.
Because the answer depends onwhich data platform you happened
to use.
Which is not a place you want tobe when a regulator or a board
asks, how do we know thismodel'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 whatthis looks like when it goes
right.
Because I don't want thisepisode to sound like enterprise
architecture is the answer toeverything.
It isn't.
But there are organizations thatgot this right, and the pattern
is consistent.
Who are you thinking of?
DBS Bank is the clearest exampleI keep coming back to.
(18:17):
They made a deliberate choice torestructure their technology
delivery around 33 platforms,each aligned to a business
segment, each jointly led bybusiness and technology through
what they called a two-in-a-boxmodel.
A business leader and atechnology leader owning the
same platform together.
SPEAKER_01 (18:36):
So architecture and business ownership were joined
from the start, not architecturereviewing after business had
already decided.
SPEAKER_00 (18:45):
Joined from the start.
Not because their models werebetter, 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'sattention.
SPEAKER_00 (19:05):
It's the kind of number that turns a foundation
investment from overhead intocompetitive advantage.
And here's the thing about UPS.
Similar story, different domain.
They built a root optimizationsystem called Orion that
produced enormous savings infuel and miles driven.
But Orion didn't appear fromnowhere.
(19:25):
It was built on top of years ofinvestment in unified
operational data, standardizedpackage data, standardized route
data, standardized network data.
The AI was the harvest.
The foundation was the years ofboring, unglamorous data work
that came before it.
(19:54):
And in both cases, DBS UPS, theoperating model choice was made
explicitly.
Not as a slide, as a funded,governed, sequenced set of
decisions about what had to becommon, what could vary, and
what needed to be shared acrossthe 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 theoperating model choice made
explicitly enough to drive thefunding decisions.
SPEAKER_00 (20:27):
Right.
And there's a consequence ofthat which we haven't touched on
yet.
It comes down to the operationalbudget.
Tell me.
So a delivery team works hard,genuinely hard, to get ongoing
operational expenditure into theproject financials.
They know the platform needs tobe sustained after Go Live.
They build the numbers into thebusiness case.
(20:48):
They get it approved.
The project delivers, theplatform launches, the
operational budget is embeddedin 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 operationalbudget review hits, and there's
a sweeping cost reductiontarget.
And someone, not the projectteam, not the architects, not
the platform owner, someone in abudget function looks at a list
of operational line items andmakes a cut.
Without understanding which ofthose line items is the run cost
(21:20):
for a shared platform thatmultiple projects are now
depending on.
SPEAKER_01 (21:24):
And the platform starts degrading.
Support gets reduced.
Monitoring gets cut.
The security controls that weresupposed to be applied
enterprise-wide suddenly have noteam maintaining them.
SPEAKER_00 (21:36):
And the people who know the platform team, they
don't have the language to fightback.
Because the platform's value isdistributed, every department
that uses it benefits, but nosingle department's PL captures
that benefit.
So when the budget cut happens,no single sponsor stands up and
says, if you cut that, you'recutting mine.
(21:57):
Everyone loses a little.
Nobody loses enough to force theissue.
SPEAKER_01 (22:02):
That's the funding design problem, not negligence.
The platform's value is real.
It just isn't visible in theright place at the right time.
SPEAKER_00 (22:12):
And that is exactly where we're going in part two.
Because what I've describedtoday is the diagnosis, the
operating model that was neverchosen explicitly, the
architecture governance that hasno funding power, the portfolio
that fragments by default.
Part two is about the money.
How you fund foundations so theydon't degrade.
(22:33):
Why the Capex OpEx distinctioncreates a specific kind of trap
for technology leaders, and whata real life cycle funding model
looks like.
Because the fix isn't moregovernance ceremonies, the fix
is changing what you fund andhow.
SPEAKER_01 (22:48):
And can I just say, I came into this episode
planning to be skeptical, andI'm leaving it genuinely
unsettled.
Because I've fixed a lot of datapipelines and data quality
problems in my career, and whatyou'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 manytimes as you like.
Until you change the source.
Until you change the source.
Thanks for listening to AIBeyond 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.
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.