Extra Time.
A companion piece to It Can.
After publishing that first post, I did wonder whether or not to shake off any illusions that this blog would be anything other than an altar to Mick McCarthy. Just imagine the titles – "Are you taking the Mick?", "In the Mick of time" — I could go on, but I'll spare you. Whilst that was absolutely not my intention (promise), I have had to return to the metaphor a little earlier than anticipated. An unexpected conversation off the back of the previous post got stuck in my head. Someone working on a large enterprise data platform — the kind with multiple project teams, a central architecture function, and published modelling standards — asked a question that sounds simple and isn't:
How do you apply golden path thinking to data architecture?
The golden path idea is straightforward: instead of gating teams behind approval processes, you make the right thing the easiest thing to do. Pave the path. Provide the template, the module, the accelerator — whatever your mechanism is for achieving that. Teams self-serve, the platform scales, happy days. For infrastructure, this works. Tag your resources, follow the naming convention, use the blessed module. The conformance criteria are objective. The validation is automatable. The path is clear.
Data architecture is where this logic runs out. In the first post I argued for golden paths over golden gates — and that still holds for infrastructure. For data architecture, the line between path and gate is blurrier, and pretending otherwise doesn't help anyone. Extra time, then.
The Incentives Problem
Golden paths assume that conformance is either in a team's interest or cheap enough that they won't resist. For infrastructure, that's usually true — the golden path is genuinely faster than trying to roll everything over from scratch. The incentive and the standard point in the same direction.
For data models, the incentive structure is inverted, or at the very least that is the prevalent perception. Conforming to an enterprise modelling standard — designing your customer entity to align with a canonical definition you didn't write, for a reuse case you'll never see — slows your project down. The benefit doesn't accrue to you. It accrues to some future team, some future use case, some future version of the org that may or may not materialise. You are being asked to pay a cost today for a return that someone else collects later.
Project teams are rational actors. When the business measures them on delivery velocity – and 99% of the time they will be, since that's rightly or wrongly what most orgs use as a proxy for whether they are delivering well – they will optimise for delivery velocity. Conway's Law shows up here the same way it shows up everywhere: teams design for their own communication boundary, because that's the context they can see. Asking them to design for the enterprise is asking them to optimise for a context that is, by definition, outside their line of sight.
So the question isn't why won't project teams conform? It's why would they?
But — and this is the part that makes the problem genuinely hard rather than just politically annoying — the enterprise standard exists for a reason. If every project team models customer their own way, those datasets don't join. Every cross-cutting question the business eventually asks — how many customers who bought X also used Y, what's the lifetime value across products, where are we losing people — becomes a bespoke integration effort that costs more than conforming would have in the first place. The value of a canonical model isn't that it makes life easier for project teams today. It's that it makes cross-domain use cases possible tomorrow. And as we argued last time, most organisations are not structured for that kind of value to emerge organically. If your org isn't set up for data mesh — and structurally, most aren't — then cross-product, cross-domain insight doesn't just happen. Someone has to design for it.
And if you're wondering whether the current wave of AI changes that calculus — it makes it more urgent, not less. Every knowledge graph, every RAG pipeline, every attempt to get an LLM to reason across your data estate depends on a shared ontology: a canonical set of entity definitions that tells the system what customer means, how it relates to product, where the boundaries are. That ontology doesn't emerge from project teams modelling independently. It's designed, maintained, and governed.
The unsexy enterprise modelling work is the AI readiness work. Most organisations just haven't connected those two conversations yet.
So both things are true at once: the incentives for project teams are wrong, and the enterprise need is real. The problem is that most organisations respond to this tension in the worst possible way — another review gate, another approval step, another ARB/TDA/COE sign off – frankly, it's no surprise that project teams CBA.
What You Can and Can't Automate
The honest answer to can we golden-path data models? is: partially.
Structural conformance — column names, data types, key constraints — is automatable in principle. But there's a spectrum, and the far end of it is data contracts: fully versioned schema definitions with strict compatibility rules and breaking change detection. In theory that's the golden path dream. In practice, it's hard to sustain. Source systems — particularly non-prod environments — are messy, inconsistent, and often outside your control. Upstream changes happen without warning. Systems that should conform to an interface spec simply don't, because the team that owns them can't or won't fix it. If your conformance checks are brittle enough to break on every unexpected upstream change, you haven't built a safety net — you've built a noise machine.
The pragmatic version is closer to a bellwether test suite than a comprehensive one. Validate the things that actually matter: primary keys, foreign key relationships, the attributes that must be a certain type because downstream logic depends on it. Not every column, not every constraint, not a full schema diff on every commit. The important tests, run reliably, surfacing the failures that genuinely indicate something is wrong. You can always extend coverage later once the foundation is trusted. Starting with everything enforced is how you end up with a pipeline that's either red all the time — or worse, has so many suppressed warnings that nobody looks at it anymore.
Semantic conformance is harder, and I'm less sure of the answer here. Does your project's customer_id refer to the same entity as the canonical one? Or is it a project-specific variant — a billing customer, a shipping customer, an internal customer — that happens to share a name? A linter can't tell you. It requires judgment, context, domain knowledge that lives in people's heads rather than in schemas. This is where most data modelling pain actually lives, and it's where automation runs out.
What you're left with is a gate — but ideally a much smaller one. Automate the structural checks so the only thing that lands on a human's desk is the semantic layer, the genuinely hard questions about what an entity means across contexts. If your approval process is rejecting submissions because of column naming violations, something has gone wrong well before the meeting invite was sent.
The Gate Itself
A man who once spent an afternoon folded into a laundry basket to dodge a UEFA ban can, it turns out, be unexpectedly cogent on coaching philosophy. José Mourinho's description of how he distinguished tactics from principles — "One thing is tactical systems, another thing is principles of play. Principles of play have to be permanent" — is one of those moments.
The tactical system changes match to match — you adapt to the opponent, the conditions, the personnel available. But the principles don't move. They're the non-negotiables that make the team recognisable as itself regardless of formation or context.
Enterprise data modelling has the same structure. The canonical definitions — what customer means, how product relates to order, where the domain boundaries sit — are your principles of play. They don't change project to project. The implementation details — which columns you need, how you source them, what the refresh cadence is — are your tactical system. They adapt to context. The mistake most organisations make is treating the principles as if they're tactical: negotiable, project-dependent, up for reinterpretation every time a new team starts work. They're not. Or at least, they shouldn't be.
The default gate looks like this. Project team builds a data model. Submits it for review. Enterprise architecture team rejects it. Project team reworks. Resubmits. Gets rejected again, this time for a different reason nobody mentioned the first time round. Everyone's frustrated, the enterprise team becomes the bottleneck, and the whole process starts to look suspiciously like the thing the first post warned about — a golden gate dressed up as governance.
There is another way to do this, and it's not complicated in concept: engagement before building, not review after. Whoever owns the enterprise data model gives project teams visibility of the canonical definitions — and the rationale behind them — before those teams start designing. Not a governance board. Not a weekly review meeting that everyone dreads. A formalised line of sight: here is what customer means in this organisation, here is why, here are the structural checks your model will be validated against. If you're going to ask teams to conform, they need to see what they're conforming to and understand the reasoning before they write a line of DDL.
That shifts things. The gate becomes a conversation at design time — when changes are cheap and context is fresh — rather than a rejection at review time, when the model's already built and nobody wants to hear it. Someone still makes the call on whether a project's interpretation of an entity is compatible with the canonical one. But the odds of that call going smoothly are dramatically better when the project team understood the target before they started.
The catch — and I keep coming back to this — is ownership. Not "the data team" in the abstract. A specific person or team whose job it is to maintain the canonical definitions, engage with project teams early, and make the semantic calls. If that ownership doesn't exist, if the enterprise data model is everyone's responsibility and therefore nobody's, none of the above works. There's no source of truth to automate against, no authority to make the judgment calls, no one to have the design-time conversation with. You end up back at the adversarial gate by default — not because anyone chose it, but because nobody chose anything else.
I don't have a neat ending for this one. But if I had to distil it: shrink the gate, don't pretend it isn't there. Automate the structural checks. Get the semantic conversations happening at design time, not review time. And find someone — a real, specific someone — who owns the canonical model and is willing to defend it.
The golden path is still the right aspiration. It just doesn't get you all the way here. We couldn't work it out in extra time, so I suppose we're going to penalties. But that's a post for another day.
