I trained for the strategy room. I spent twenty years in the requirements room.
The strategic room. Where you decide what the organisation essentially is. What it’s for. How it holds together. What it must become.
I know I’m good at that work. I found out early, the way you only really find out once. About twenty years ago, in a business strategy simulation, my team came first. Afterwards I coached two other teams to first place. I played again recently and we took third in our class. The knack is real, and it’s the kind of real you can’t talk yourself into.
So I went looking for the room where that kind of thinking gets used for a living. I trained, certified, and stepped into the title that seemed to promise it.
For about twenty years, the door to that room stayed shut.
Not all the way. I’d get near it. A strategy offsite here, a target operating model there. But the centre of gravity of the job always pulled me somewhere else. Toward systems. Toward solutions. Toward requirements. The architecture I was paid to produce was never quite the architecture I’d come to do.
For a long time I assumed the fault was mine. Or political. Or just the way large organisations ration access to the top. I told myself the usual stories.
The real reason is more interesting, and it took me most of those twenty years to see it.
I wasn’t locked out because I lacked strategy. I was locked out because the discipline itself had quietly left the strategic layer and set up shop one floor down. I was standing exactly where the title said I should stand. The title had moved.
The Layer Enterprise Architecture Was Supposed to Occupy
Strip an enterprise back far enough and you reach a layer that has nothing to do with technology.
It’s the layer of essential acts. People deciding. People committing. People judging whether a commitment was met. A hospital is essentially a set of agreements to admit, treat, and discharge a patient. A bank is essentially a set of agreements to hold, lend, and settle. None of that depends on which system you run or which vendor you chose. It’s what the enterprise is, independent of how it happens to be built this year.
Jan Dietz and the enterprise-engineering school have a precise name for this. They call it the essential level of the organisation, abstracted from everything implementational. I’ll keep the jargon light: think of it as the essence layer. What the enterprise fundamentally does, before any system is named.
Below the essence sit the implementation tiers. The information that gets recorded. The documents that carry it. The technology that runs it all. Useful, necessary, concrete. But downstream. They serve the essence; they aren’t it.
Enterprise architecture was meant to live at the essence layer.
That’s the whole point of the word enterprise. Not the systems of the enterprise. The enterprise. The thing itself, designed as a coherent whole.
It didn’t stay there.
The Collapse
Watch where the work actually goes and the drift is obvious.
“Enterprise architect” became, in practice, a senior technology role. “Solutions architecture” became its most common expression. And solutions architecture, stripped of the brochure, is mostly requirements management dressed in strategic language. Capture what’s needed. Translate it into systems. Govern the build.
All worthwhile. All necessary. None of it the essence layer.
This is the essence-layer title doing implementation-tier work. A function named for what the enterprise is, spending its days on how the enterprise is built. The collapse is so complete we stopped noticing it had happened.
And the dominant framework didn’t just permit the collapse. It enshrined it.
Look at TOGAF’s architecture development cycle. Every domain orbits a centre. And the centre, the thing every phase reports back to, is Requirements Management. The implementation tier sits in the middle of the wheel. The essence layer isn’t demoted in TOGAF. It was never given a seat.
So the most widely taught definition of enterprise architecture puts requirements at the heart of the enterprise. We certified a generation, including me, into the collapse and called it best practice.
That’s not an oversight. That’s a confession.
The shift nobody announced: enterprise architecture stopped designing what the enterprise is and started managing what its systems require.
Why It Drifted (And Why That’s Not a Character Flaw)
This wasn’t stupidity. It was economics, working exactly as economics works.
Requirements are concrete. You can scope them, cost them, ship them. Someone signs a purchase order for a solution. A vendor invoices against it. A programme reports green or red. The implementation tier is fundable, billable, demonstrable. It has a budget.
The essence layer has none of that. Nobody raises a PO for “the implementation-independent design of how we coordinate.” There’s no line item for clarity about what the enterprise essentially is. The work is real and it is abstract, and abstract work without a budget loses, every time, to concrete work with one.
So architecture drifted to where the money was. Not in a decision. In a thousand small ones, over two decades. Each individually rational. Take the fundable scope. Bill the concrete deliverable. Repeat.
This is a competency trap, and it’s a familiar one. I’ve written before about how the discipline optimised for artefacts instead of decisions, and about the engineering rigour it never developed. The collapse from essence to implementation is the same pattern at the layer above. The discipline got very good at the work that paid, and that skill became a cage. Twenty years of doing the fundable thing well left it structurally unable to do the strategic thing at all.
Path dependence doesn’t feel like a trap from inside. It feels like being responsible. Like delivering. That’s what makes it so hard to see.
The Org-Chart Mistake
You can hear the discipline straining against the cage. Listen for it.
“Enterprise architecture should report to the CEO, not the CIO.” It comes up at every conference. The instinct behind it is correct. People sense, accurately, that the function belongs in the strategic room. That it’s been filed in the wrong place.
But the prescription is wrong. You cannot promote a function back into the strategic layer by changing who it reports to. A solutions-architecture team that lands under the CEO is still a solutions-architecture team. It will do implementation-tier work with a better view of the car park.
The layer isn’t an org-chart position. It’s a kind of work. You reach the essence layer by doing essence-layer work, not by being reassigned to it. Moving the box up the chart treats a structural problem as a reporting problem. It mistakes the symptom for the cure.
Reclaiming the Layer
Here’s where the twenty years stop feeling like a waste, though I won’t pretend they cost nothing. A talent you can’t find a professional room for is a quiet, particular kind of loss. After enough years you start to wonder if you imagined it. That’s the part the simulation games kept answering for me: no, you didn’t imagine it. The room was missing, not the ability.
So I now know the room I wanted exists, that it was always real, and exactly why I kept missing it. I wasn’t failing at strategy. I was working at the wrong altitude with the right map. That’s not grievance. That’s coordinates.
The essence layer is still vacant. The work of designing what the enterprise fundamentally is, abstracted from this year’s systems, is still mostly undone in most organisations. That vacancy is the opportunity. It’s the space I’d call strategic architecture: the enterprise designed at its essence, plus one question the implementation tiers can’t even ask.
Can the enterprise respond in time?
The essence layer isn’t only structure. It’s structure under a clock. A signal arrives from the market. Somewhere between sensing it and responding to it, the enterprise either moves or it doesn’t. I’ve come to call that gap the signal-response distance, and it’s the most strategic question there is. No solution architecture answers it. No requirements catalogue. It lives one floor up, in the layer the discipline abandoned, and it’s the layer worth coming back for.
That’s the work I do now. Not because I left enterprise architecture, but because I climbed past where it settled, up to the layer it abandoned. That’s the altitude I work from. Nobody hands you that room. You take it by doing the work that belongs there.
The Provocation
If your enterprise architecture function spent the last quarter on solutions, systems, and requirements, you don’t have an enterprise architecture problem. You have an enterprise architecture vacancy. The title is occupied; the layer is empty.
You can’t fix that by promoting the box. Move the requirements-and-solutions work under the CEO and all you’ve built is a very senior implementation function with an aspirational name.
So ask the question the org chart can’t answer. Not who does architecture report to? Ask what is the essential design of this enterprise, and can it respond in time?
If nobody in the building owns that question, you’ve just found the room. It’s been empty the whole time.
The Bottom Line
The strategic layer of enterprise architecture isn’t broken. It’s deserted. The discipline didn’t fail to reach it; it withdrew, one billable deliverable at a time, until the essence of the enterprise had no one tending it.
Twenty years to see the door.
The door was open.