I used to think security architecture was mostly a paperwork problem. Diagrams in, risk score out. Tidy.
It isn't. It took me years of sitting with actual systems — not the diagrams of them, the actual things — to work that out properly.
Here's the tension I keep bumping into. Organisations want security architects to make sense of complicated systems. Fair enough. But then they hand us the system as a summary of itself. A diagram. An artefact. A PowerPoint slide with boxes and arrows that someone tidied up specifically so it would look presentable in a governance meeting.
You're meant to assess the risk inside the house. Nobody shows you the wiring behind the walls.
Earlier in my career, that didn't bother me. I was perfectly happy reasoning from diagrams. They were clean. They made sense. I could point at a box and say something sensible-sounding about it.
Then I spent enough time with real systems to find out how much those diagrams leave out.
It's not a small gap. It changes the quality of nearly every call a security architect makes. And it's got worse, not better, as everything's moved toward distributed, API-driven, cloud-native setups, where the actual behaviour of a system is emergent — meaning nobody fully designed it, it just sort of happened, and now you're meant to assess the risk of something that grew rather than something that was built.
Strip away the frameworks and the governance language and the job is much smaller and much more grounded than it sounds in a job description. It's: understand how software behaves when actual people build it, change it, half-fix it at 11pm, and then quietly rely on it for the next six years.
On paper, software is tidy. Boxes. Arrows. Labelled rectangles for the libraries. Failure modes get a footnote, if that.
Sit with the real thing — the logs, the quirks, the old patches nobody removed, the decisions that made sense in 2019 and haven't been touched since — and you start to see its actual shape. Like tree rings. Every awkward decision is still in there, preserved, waiting for someone to notice it.
You're asked to evaluate risk inside that mess. To do it properly you need at least a working feel for how the moving parts knock into each other. Not because you're going to rewrite the thing yourself. Because you're trying to guess where it's going to fall over before it does.
I genuinely struggle to reason about threats when I don't have some working sense of how the code behind a feature is actually stitched together. That's not me wanting to implement it myself — I don't need to. It's wanting to understand why something's fragile, or why a control that looks fine on paper might just fold the moment it meets the real environment.
Software hides its trouble in ordinary places. A framework behaves exactly as expected — right up until someone uses it in an edge case nobody designed for. Dependencies don't usually introduce risk through anything dramatic. It's accumulation. One version that never got bumped. One feature flag someone forgot was on. One patch applied slightly out of order, eighteen months ago, by someone who's since left.
You don't need to be an expert in every one of those layers. You do need enough familiarity to notice when something's off. A data flow taking a detour it has no business taking. An auth library being used in a way that quietly breaks its own assumptions. A design decision that creates a blind spot nobody clocks until it's already a problem.
None of that is exotic. It's just the stuff that decides whether an application is actually resilient, or only looks that way in the diagram.
Take a DAST report. On its own, it's not really telling you anything. It's a list of symptoms. To make sense of it, you need some idea of what's behind those symptoms — which findings are structural, which are just noise from the tool itself, and which ones are real and genuinely reachable.
Without that baseline of literacy, everything starts to look the same weight. Every finding feels urgent. Every risk feels abstract. You lose the one skill that actually matters here: telling signal from noise. And once that's gone, the whole exercise stops meaning much.
Good threat assessment isn't a cataloguing job. It's understanding why the problem exists and what it actually implies for the system around it.
A lot of this job is collaboration, whether the title makes that obvious or not. Developers need guidance that fits inside the actual constraints they're working with — time, complexity, the side effects nobody wants, the reality of shipping something this sprint rather than next year.
An architect with even a basic working grasp of that world gets two things out of it. First, they communicate properly — not by dumbing things down, but by tying their reasoning to how implementation actually works. Second, they stop proposing controls that are technically correct and practically dead on arrival.
That's where the trust comes from. And trust is what actually makes the security posture hold, not the framework.
None of this means every architect needs to be a software engineer. Related skill, not the same skill. But you do need enough technical grounding to spot patterns, anticipate where things break, and follow how a design decision ripples through a system long after the meeting where it got decided.
Without that grounding, the whole thing drifts into formality. Boxes ticked. Diagrams checked for completeness. Risk "documented" without ever being understood. And the gap between documented and understood doesn't stay invisible forever — it shows up later, in production, in incidents, in all the quiet places where someone's assumption finally gives out.
Technical literacy isn't a nice-to-have bolted onto the job description. It's the thing that lets you see the system as it actually is, rather than as the diagram politely suggests it should be.
At its core, this work is just understanding. You don't have to build the software. You do have to know enough about how it actually lives and breathes to protect it properly. That's what makes the analysis credible, the guidance usable, and the decisions worth trusting.