For most of my career I was the person in the room rolling his eyes at the words “enterprise architecture”. Not architecture — I’ve always believed in that. Enterprise architecture: the capital-letters kind, with the framework, the reference models, the certification, the hundred-page standard nobody reads twice. I thought it was expensive ceremony for big companies with the headcount to afford a department that draws diagrams about diagrams.
I had two good reasons, and I want to be fair to my past self, because both were honest trade-off judgements rather than laziness.
Why I was a sceptic
The first reason was scar tissue. I’d lived through a heavyweight framework rollout, years back, that failed. It failed the way these things usually fail: we adopted the apparatus — the templates, the phases, the vocabulary — without ever landing the point. It produced artefacts that impressed in a steering meeting and changed nothing about how anything got built. So I filed enterprise architecture under “tried it, watched it die,” which is a very human and very misleading way to reason.
The second reason was scale. A small team, a system you can more or less hold in your head — what does that need with strategic architecture? Solution architecture was plenty: solve the problem in front of you, keep it coherent, ship. Adding an enterprise layer felt like buying a freight timetable to walk to the shops. And honestly, for a good while, it was the right call.
The trouble with a right call is that it has a shelf life, and nobody sends you a reminder when it expires.
What actually changed my mind
What changed was a transformation programme — a greenfield rewrite of an old system, with new ways of working bolted on at the same time. And the thing that exposed the gap wasn’t the diagrams I’d been dismissing. It was governance. Or rather, the complete absence of it.
We had project governance — someone owned the plan, the budget, the deadline. What we had almost none of was architectural governance: any shared answer to “are we building this the right way, and how would we even know?” The cost showed up as a slow, grinding tax. Painful re-alignment. Refactoring that existed only because two parts of the team had quietly assumed different things. And — the one that stung — a run of early decisions that nobody could reconstruct, because they were never written down. We were paying interest on choices we couldn’t even remember making.
That’s when the penny dropped, and it dropped in a very specific place: the problem was never “we don’t have enterprise architecture”. The problem was “we have no governance, and I’d talked myself out of the discipline that supplies it because I’d conflated the discipline with the framework that once failed us.” Those are not the same thing. TOGAF is not enterprise architecture any more than a particular gym membership is fitness. Rejecting the one because it disagreed with me had let me reject the other, and the other was the part I actually needed.
Lightweight, or not at all
So I did the thing I’d have mocked a year earlier: I started building an architecture practice. The trick — and it is the whole trick — was to take almost none of the framework. I leaned on Kotusev’s idea that only a handful of architecture artefacts ever earn their keep, and deliberately ignored the rest. Not “TOGAF lite”. Just the few things that pay for themselves: a small set of principles, the decisions actually recorded, a light-touch monthly design authority to ask the “are we doing the right thing” question out loud before it became expensive to answer wrongly.
None of it looked like the capital-letters version. That was the point. This is the same argument I keep making about systems — that there is no “right” architecture, only one appropriate to its forces — and it turns out to apply to the practice of architecture as squarely as it applies to the architecture itself. The honest question was never “do we adopt enterprise architecture, yes or no?” It was “how much of it earns its place here?” — and the answer for a small team is far less than a framework assumes, but a lot more than zero.
The part the conversion stories leave out
Here’s the bit I’d have wanted someone to tell me, and that the tidy “and then we adopted governance” write-ups always skip: at first, it didn’t work.
The delivery team had spent years treating process as the enemy of shipping, and a new forum with “authority” in its name confirmed every suspicion they held. People used it only when I convened it. The quality of what turned up was thin. For a few weeks it had all the momentum of a meeting that exists because someone put it in the calendar.
What turned it around wasn’t a better template or a more persuasive deck. It was leadership actually stopping work that had bypassed the process — a couple of features held at the door until they’d been through review. That was the whole difference. Governance without teeth is a suggestion, and a suggestion is exactly what a delivery team under pressure will decline. Governance with visible executive backing is a control, and controls change behaviour. Uncomfortable, a little political, and completely true. The artefact was the easy part; the teeth were the hard part, and the teeth were never mine to supply alone.
And I want to be honest about the bit that even the teeth don’t fix: it’s still hard work. The backing gets people through the door, but it doesn’t make the conversations easy, or the trade-offs obvious, or the team stop resenting the friction on a bad week. I’m still working out how much process is enough and how much is theatre, still losing the odd argument I should have won and winning ones I probably shouldn’t have. The teeth changed the odds. They didn’t hand me the answers, and I’d be selling you something if I pretended otherwise.
So, a convert — but read the small print
I’m an advocate now, which my younger self would find insufferable. But I’m not a convert to the framework, the certification, or the department. I’m a convert to the small, unglamorous slice of the discipline that pays for itself even in a team of one — writing decisions down, agreeing a few principles, and creating one honest place to ask whether we’re building the right thing.
And I’m a convert to the harder lesson underneath it: the diagram is never the deliverable. The deliverable is a team that shares an understanding of what it’s building and why — and that only sticks when someone with authority is willing to hold the line. I spent years dismissing enterprise architecture because I’d watched the ceremony fail. I’d never actually tried the substance. They are, it turns out, very different things.