There’s an XKCD comic that gets passed around in engineering circles.
xkcd.com/2347 — CC BY-NC 2.5
In March 2016, a developer named Azer Koçulu — working out of Oakland, California — unpublished 250 npm packages after a dispute with npm Inc. over a package name. One of those packages was left-pad: eleven lines of JavaScript that padded strings on the left. Within hours, React wouldn’t build. Babel wouldn’t build. Thousands of projects that had never heard of Azer Koçulu, that had never made a conscious decision to depend on him, were broken.
Nobody designed this. Nobody governed it. The dependency crept in, package by package, until a Turkish developer in California with a legitimate grievance had more impact on the global software supply chain than any single engineering organization.
That’s the open-source internet, and it operates under its own rules.
But the same thing happens inside large enterprises very often. Just slower, less dramatic, and without the tweets.
How enterprises are organized
Medium and large enterprises divide by business domain. Production. Retail. Digital. B2B. HR. Each domain has its own budget, its own leadership, its own roadmap, its own engineers.
This is correct. I am not saying politically — structurally correct. Conway’s Law is not a suggestion: the systems you build reflect the communication structure of the organization building them. Domain-oriented organizations produce domain-coherent systems. That’s what you want.
Domain architecture operates across four layers within each domain:
Technology enables applications, applications produce and consume data, data enables business capability. This is well understood, which is a problem since the edges are not smooth.
The no man’s land
When you divide into domains, you create boundaries. And boundaries, left unmanaged, become no man’s land.
No man’s land is what happens when something important doesn’t clearly belong to any single domain — and so nobody owns it.
In practice it looks like this:
Too many business domains, and some units fall outside any of them — nobody claimed them, nobody maintains them, and they persist in a state of benign neglect until something breaks.
A unit gets assigned to the closest domain even though the fit is wrong. It gets the attention of a domain that doesn’t understand it and doesn’t have the right incentives to invest in it.
Analytical data that crosses domain boundaries has no clear owner. Multiple domains use it; none of them maintains it. Everyone assumes someone else is responsible.
Tooling that enables a transformation programme lives in one domain, but the programme spans three. When the original sponsor moves on, the tool becomes an orphan — technically alive, practically unsupported.
Systems get upgraded and modernised within their domains; the integration interfaces between them don’t. No single domain has the mandate or the budget to own the crossing. The interfaces hang in maintenance mode, a thread holding up a wall.
There’s a version of this I’ve used in presentations: imagine Mufasa showing Simba the kingdom from Pride Rock, the savanna stretching out in every direction. Simba points to a dark patch on the horizon. “Dad, what is that area?” Mufasa doesn’t look. “Son, we don’t go there. That part was created by Steve from accounting.”
Everyone laughs. Everyone in the room has a Steve from accounting.
The grey zone problem is organizational, not technical. The thing in the dark patch isn’t broken — it just has no owner, no mandate, no one who sees it as their job to understand it. Domain teams can’t fix this. Each domain is optimizing for its own area by design. Nobody in Production has the incentive, the mandate, or the full picture to govern something that touches Production, Retail, and Finance simultaneously.
Steve sometimes does, and generally people do not mind, because they dont know what steve does, they jsut knwo thsi is not presenting the problem.
At least one function needs to transcend the boundaries
This is where architecture comes in — specifically because it is a multidisciplinary function. The BDAT stack is a map of everything a domain team manages internally and everything that falls apart at the seams between them. An architecture function that operates across all four layers — business, data, application, technology — and across all domains is structurally positioned to see what no single domain team can see.
That’s the job - ensure nothing stays in the grey zone urecognized, and unmanaged. To say: this crosses boundaries, which means it belongs to architecture until it belongs somewhere else. To make the invisible visible, assign ownership, and then get out of the way.
Domain teams will optimize for their domains. That’s what they’re designed to do, and it’s right that they do it. You can’t ask a Production domain team to take ownership of the integration layer between Production and Retail — that’s not their scope, not their mandate, and not their incentive.
Someone else has to hold the picture that no single domain can hold. That function is enterprise architecture.
The challenges of governance
This is where most architecture functions fail.
Standards that are agreed but not enforced don’t hold. Decision-making authority that isn’t clear doesn’t hold. Architecture reviews that can be bypassed at will don’t hold.
The challenge: the things you’re governing are moving. Teams ship. Domains grow. New capabilities appear. The governance model has to be firm enough to provide consistency and fast enough not to become a bottleneck.
Most organizations fail in one of two directions. Governance is so light it doesn’t actually constrain anything — you have principles, not decisions, and everyone nods at them and does what they were going to do anyway. Or it’s so heavy that teams route around it — the process costs more than violating it costs, so violation becomes standard practice.
Governance needs to be affordable and firm. Can you achieve that?
The test is simple: can someone get a clear answer to a significant technical proposal from your architecture function before the window for that decision has closed? If the answer is usually no — either because the function doesn’t engage or because it engages too slowly to matter — governance is broken. The direction of the failure tells you how to fix it.
Three questions
Any significant technical initiative eventually needs three questions answered:
You can’t design how until you know whether. You can’t commit to when until you know how.
The architecture function’s job is to own the first question and structure the path to the second.
The first phase — business modeling and assessment — establishes the what and why, then produces a technical verdict: feasible or not, on what terms, with what constraints. This is where architecture earns its place at the business table. Not by showing up to validate decisions that have already been made, but by engaging early enough to shape them.
The second phase — the architecture creation — works from data architecture through application architecture to technology architecture, in that order:
The “when” falls out of planning once the architecture decisions exist — not before, and not by someone guessing.
What this means for how you set up the function
A few things that distinguish architecture functions that have real impact from:
The no man’s land inventory. Someone in the architecture function should be able to answer, at any given time: what exists in this organization that isn’t clearly owned by any domain? If nobody has that list, nobody is governing it.
Upstream, not downstream. Architecture that arrives at the end of a project to validate decisions is audit, not governance. The function needs to be in the room when the “can it be done” question is first asked — not when the answer has already been baked into a budget commitment.
Cross-boundary ownership is explicit. Every integration interface, every shared data asset, every cross-domain capability needs a named owner with a named mandate.
The three-question model is a forcing function. When a business stakeholder asks “when will this be done?” before anyone has established “can it be done?”, the architecture function needs to redirect, not answer the wrong question faster. Part of the job is training the organization to sequence correctly.
Left-pad broke the internet in an afternoon. That was a governance failure at ecosystem scale — nobody owned the dependency graph, so nobody could protect it.
Enterprise architecture exists to solve the same problem at organizational scale. Not to prevent domains from making their own decisions — that would break the thing that makes domain teams work.
Job is to ensure that what lives between the domains, at the crossings, in the integration layer, in the shared capabilities that everyone uses and nobody maintains — that those things have owners, have governance, and don’t become your organization’s left-pad moment.
The function is not glamorous. The decisions it makes are often invisible even if they prevent a problem that nobody ever knew was coming. That invisibility is the point. The architecture function is working when nothing breaks unexpectedly at the boundaries.