The missing architect

There is a particular kind of stuck that mid-size mission-driven organisations reach — the NGOs, the agencies, the institutes between thirty and five hundred people. It doesn’t feel like a crisis. Nothing is on fire. The org just gets slower and more brittle than its size should allow. Small requests take weeks. New systems land on top of old ones instead of replacing them. Every decision about technology is made well, locally, by a capable person — and yet the sum of all those good local decisions is a mess nobody chose.

The cause is almost always the same, and it’s structural rather than personal: no one owns the architecture. IT is run reactively, competently, by generalists who are good at saying yes and making the immediate problem go away. What’s missing is the person whose actual job is the whole picture — how the parts fit, where they’re heading, what should never have been bought. I call it the missing architect, and once you see the pattern you can’t unsee it.

The symptoms you’ll recognise

You don’t diagnose the missing architect by looking for the architect. You diagnose it by the residue they would have prevented. A few you’ll know on sight:

• The stale intranet. A platform launched with great fanfare three years ago, half-populated, last meaningfully updated by someone who has since changed roles. Everyone routes around it. Nobody will say it’s dead.
• The app the one enthusiast built. A genuinely useful tool a motivated colleague spun up in their spare time — a tracker, a small database, a clever automation. It became load-bearing. Then they left, and now it’s a black box nobody can change and nobody dares turn off.
• The audit finding that keeps coming back. The same observation about access, or backups, or data handling, year after year. Each year it’s patched locally and the patch doesn’t stick, because no one owns the underlying control.
• “So — what are we doing about AI?” Asked at a board meeting, with real anxiety underneath it. There’s no answer, because there’s no one whose job is to have an answer, and the pressure to do something visible starts to override the question of whether it’s the right something.

None of these is a failure of effort. Every one is a failure of ownership. The tools accreted ad hoc, one reasonable purchase at a time, and the connective tissue between them — the part that makes a collection of systems into an estate — was never anybody’s responsibility.

Why the gap exists (the economics)

The gap isn’t an oversight. It’s the rational outcome of how organisations this size are funded and staffed. A true enterprise architect — senior, expensive, dedicated — is a role you can justify at two thousand people and a board that already thinks in terms of systems. At a hundred and twenty people on programme-restricted funding, you cannot. The headcount math doesn’t close, and it shouldn’t: a full-time architect would be idle most weeks and impossible to defend to a donor who wants money spent on the mission, not on overhead.

So the work doesn’t get done by no one — it gets done by everyone, in slivers. The IT generalist absorbs the parts that are clearly technical. A keen programme officer takes the bits that touch their work. A vendor fills the gaps their product happens to cover. Each does their slice well. But architecture is precisely the thing that lives between the slices, and a responsibility split across five people who each own a fragment is, functionally, owned by no one. The org isn’t neglecting architecture out of carelessness. It’s neglecting it because the standard answers — hire a senior architect, or ignore it — are both wrong at this scale, and the third answer isn’t obvious.

What the architect actually owns

It helps to be concrete about the job, because “architecture” sounds grander and vaguer than the work really is. The missing architect owns a small number of unglamorous things that nobody else is positioned to hold:

• The target-state map. A plain picture of where the estate is going — what systems exist, what they’re for, which ones are sunsetting, what fills the gaps. Not a diagram for a slide; a reference that makes the next purchase decision obvious.
• The well-scoped no. The authority and the perspective to decline the tool that duplicates one you already have, the pilot you can’t govern, the integration that adds a door you’ll never close. Restraint is most of the value, and it only works when someone owns it.
• The governance baseline. Who can build, where data is allowed to flow, what happens to a leaver’s access, where the evidence lives. The dull controls that turn a recurring audit finding into a one-time fix.
• The hand-off discipline. The rule that no tool becomes load-bearing without an owner, a runbook, and a way to keep running when the enthusiast who built it moves on.
• The honest AI answer. Not a pilot to look busy, but a sober read of where the data, the governance, and the appetite actually are — and the sequencing that makes AI useful after the boring prep rather than expensive before it.

Notice that almost none of this is building. It’s deciding, writing down, and holding a line. That’s why it falls through the cracks: it produces no demo, and it’s invisible until the week it would have saved you.

Filling the gap without the hire

The good news is that the role is fractional by nature. The architect’s work is dense but not continuous — it’s concentrated in decisions, reviews, and a handful of written artifacts, not in a forty-hour week of presence. That’s exactly the shape that doesn’t justify a full-time hire and exactly the shape a fractional engagement fits: someone who owns the whole picture for the hours it actually takes, and writes it down so the org keeps the thinking even when the person isn’t in the room.

And the way to fill it is boring-first, deliberately. You don’t open with a transformation programme or a new platform — that’s how the mess got made. You open with the map, the baseline, the runbook, the well-scoped no. You shrink the estate before you grow it: the win is often deleting two tools, not adding one. When I built a multi-agency platform for a mission-driven org, the part that mattered most wasn’t the dashboard — it was deciding, up front and on paper, what it would and wouldn’t own, so it consolidated systems instead of becoming one more. That decision is architecture. It cost an afternoon and saved years.

The missing architect isn’t a person you can’t afford. It’s a small set of decisions nobody currently owns — and the moment someone does, written down and held to, the ceiling lifts. The org that maps its estate on a quiet Tuesday and says no on purpose will quietly outlast the one that keeps buying the loud new thing and wiring it on top of the last one. That’s the whole pattern. The boring move that makes it true is the page that doesn’t exist yet: write it down before you buy anything else.