Every architecture discussion eventually arrives at the same three words. People. Process. Technology. The framework has been around long enough that people quote it without remembering where they heard it. It’s a useful shorthand, and one of the most misleading frameworks in common use.

The misleading part isn’t what it includes — people, process, and technology are real things real organizations are made of. The misleading part is what it implies: that mapping these three layers means you’ve mapped the organization. You’ve mapped a snapshot. What changes the snapshot from one frame to the next is decisions. In most organizations, decisions are uncounted, unmapped, and unowned.

A framework that describes won’t direct

PPT is all nouns. You can put each of them in a box on a slide. That’s why the framework persists — it’s easy to draw.

Architecture, done well, is the work of choosing what to change. A framework made entirely of nouns can describe the current state. It can’t direct the next action. The thing that directs the next action is a verb. Should we keep this system or retire it? Should we centralize this team or split it? Should we expose this capability as an API or keep it internal? These are the questions architects spend most of their time on. None are visible on a PPT map.

Decisions are layered too

At the operational layer are the hundred decisions made daily — which alert is urgent, which lead to call first, which deploy goes to which environment. Most are encoded in tooling and routines; the architecture work is making those defaults good.

At the tactical layer are decisions made every few months: which CRM to keep after an acquisition, which queue to use, which framework to standardize on. Real consequences, and the ones most likely to be forgotten because nobody wrote down why.

At the strategic layer are the decisions that shape what the organization is — markets to serve, build versus buy, platforms to commit to for the next five years. These happen rarely, but each one constrains every tactical and operational decision underneath it. When the strategic layer is vague, the tactical layer fills the gap with improvisation, and that improvisation is what most “process problems” actually are.

flowchart TD
    S["<b>Strategic</b><br/>Markets, platforms, build vs buy"] -->|"sets the frame for"| T["<b>Tactical</b><br/>Which CRM, queue, framework"]
    T -->|"sets the frame for"| O["<b>Operational</b><br/>Which alert, which lead, which deploy"]
    O -.->|"improvisation fills the gap<br/>when the layer above is vague"| T
    T -.-> S

Every system is a decision someone made

Pick any system in your organization and trace it backwards. Someone decided it should exist, chose the technology, assigned the team. Each moment was a decision with reasons. Where are those reasons written down? In most organizations, nowhere.

A decision without a record decays into folklore within months. “We use Postgres because… I think Mark wanted it?” Two years later, someone proposes replacing it and nobody can argue against the idea on the original grounds because the grounds were never written down. Architecture decision records are the response — not part of the system, not in the pipeline, but the part that determines whether anyone in the future can reason about the choices. What was decided, what was considered, what the reasoning was. The format barely matters. The discipline does.

Decisions queue, and the queue is invisible

In most organizations there’s a stack of pending decisions nobody has formally committed to making. Should we retire this system? Should we deprecate this API? Each has been raised, informally discussed, and never resolved. They sit in a queue with no name, no owner, no deadline.

flowchart LR
    P["Decision pending"] -->|"owned"| M["Decision made"]
    P -->|"avoided"| I["Decided by inaction"]
    M -->|"recorded"| A["Becomes a known constraint"]
    M -->|"not recorded"| F["Becomes folklore"]

This queue is invisible on any architecture diagram, but its effects are everywhere. Teams build around the assumption the decision will go one way. Other teams build around the opposite. The system accumulates inconsistencies that aren’t bugs — they’re the visible record of decisions that never got made.

What this means for architecture

Architecture documents should include a decisions section, not just a components section. The components are what exists. The decisions are why it exists. A document with components only is a map of a city that doesn’t tell you why the streets are where they are.

The inventory of pending decisions is as important as the inventory of systems. When someone asks for an architecture review, half the value is often in surfacing decisions that have been quietly avoided. “We’ve been talking about retiring this system for two years. Is this the meeting where we actually decide?” That question is worth more than any diagram.

PPT will tell you what your organization is made of. It won’t tell you what to do next.

What to do next comes from looking at the decisions — the ones already made, the ones still pending, and the ones that have been made implicitly by nobody making them. That layer doesn’t fit in a three-letter framework. It’s the verb the nouns are waiting for.