Supportability is an architecture decision

There's a particular kind of confidence that comes from having designed a system you never had to support. It looks clean on a whiteboard, it satisfies the requirements document, and it's someone else's problem the moment the project closes out. That's not an accusation — most architecture is written by people who genuinely believe the design is sound. But belief and evidence aren't the same thing, and the difference tends to show up eighteen months later, in a change window, at a time nobody chose on purpose.

I spent the earlier part of my career on the other side of that gap — supporting systems I had no part in designing, working out why a "resilient" setup didn't fail over the way the diagram implied it would, or why nobody could explain what a particular firewall rule was actually for. That experience left me with a fairly specific opinion: supportability isn't a quality you inspect for after a system is built. It's a design decision, made or missed at the same time as every other architectural choice, and it's usually invisible until the exact moment it matters.

What “supportable” actually means

It's tempting to treat supportability as a synonym for documentation — write it down clearly enough, and the job's done. Documentation matters, but it's downstream of the actual decision, which is about how much a system expects from the person operating it day-to-day.

A supportable design assumes the person troubleshooting it at 2am wasn't in the design meetings, doesn't have the same context the designer did, and is working from whatever's actually left behind — not what should have been left behind. It fails in ways that are diagnosable rather than mysterious. It has fewer special cases that only the original designer understood. And critically, it doesn't rely on tribal knowledge surviving staff turnover, because it never does, not completely, not forever.

None of that shows up in a requirements document, because nobody writes "and it should be easy to fix when it breaks" as a formal requirement. It's assumed. It's also one of the first things dropped under time pressure, because unsupportable systems and supportable ones can look identical in a demo.

Why this is architectural, not operational

There's a common framing where architecture is the clever part and support is the unglamorous part that happens afterwards, handled by a different team, considered separately, sometimes considered barely at all. That framing is backwards, or at least badly incomplete.

Decisions made at the architecture stage — how systems are segmented, how failure is meant to be detected, how much complexity is centralised versus distributed, how much a design depends on components understanding each other correctly — are exactly the decisions that determine whether a system is supportable later. By the time it's live, those choices are baked in. Operations teams can compensate for a genuinely bad design with enough manual effort and institutional memory, but that's a tax paid indefinitely, not a fix.

Treating supportability as architecture means asking a different set of questions early: not just "does this meet the requirement," but "what does this look like to troubleshoot without the context I currently have," and "what happens when the person who built this isn't the one supporting it." Those questions change designs. They tend to push toward fewer bespoke exceptions, clearer failure modes, and documentation that's a byproduct of a well-structured design rather than a separate deliverable trying to compensate for a poorly-structured one.

Where this comes from, practically

This perspective isn't available to everyone equally, and that's not really anyone's fault. If your entire career has been architecture and design, it's genuinely difficult to know what a design actually looks like from inside an incident, at 2am, with a system that isn't behaving the way the documentation says it should. That knowledge mostly comes from having been there — which is a slightly roundabout argument for why progressing from support into design, rather than starting in design, tends to produce a particular kind of practical caution that's hard to acquire any other way.

It's not a claim that support experience is a prerequisite for good architecture — plenty of architects design supportable systems without it, through discipline and good judgement. It's a narrower claim: that having personally supported bad decisions is a fairly efficient way to stop making them, and that the resulting instinct — design for the person who inherits this, not just for the requirement — is worth deliberately keeping once you're the one holding the pen.