I’ve spent a decade as the architect in the room where principles get written down. I’ve also spent a decade watching those principles ignored by delivery teams that route around the architecture function because routing around is the fastest path.
That gap — between the principle on the page and the deploy in production — is the entire job of the modern EA function. And most EA functions are still solving it with the same instruments we used in 2010: a steering committee, a slide pack, an architecture review board, and a quarterly principle refresh.
It doesn’t work. It hasn’t worked at any of the four banks I’ve worked inside. It works at exactly two kinds of place: the ones too small to need formal EA, and the ones whose platform team has quietly become the de-facto EA function.
What “encoded” means.
An architecture principle is encoded if a deploy that violates it gets blocked, automatically, before a human is involved. Everything else is rhetoric.
“All workloads must use workload identity, not static credentials” is a principle. An OPA policy that fails the Terraform plan when a service account key is created is the encoded version of that principle. The principle by itself produces a 70-page document. The encoded version produces a CI build failure with a link to the paved path.
Some principles are easy to encode. Most of them aren’t hard either — they’re uncomfortable, because encoding forces you to be precise about what the principle actually means. “Security must be considered at design time” isn’t encodable. “Every service with a public ingress must have a threat model attached to its ADR before merge” is.
TOGAF is a manual, not a mandate.
The most common mistake junior EA functions make: treating TOGAF as the work product, not the operating manual. The ADM cycle is a reference for the conversation; it’s not the conversation itself. The same is true of BIAN for banking and ArchiMate for modelling.
These frameworks exist so that you don’t have to invent the vocabulary, the artefact set, or the lifecycle. They’re cheat codes. Your actual job is to use them — sparingly, in the parts of the org that need them — to ship encoded decisions and a capability model.
Two specific TOGAF artefacts continue to earn their keep in 2026: Architecture Principles (when encoded) and the Architecture Repository (when it’s actually populated and searchable). Most of the rest can be replaced by an ADR repo and a living capability model in a tool people open daily.
The four moves that change an EA function in a year.
1. Switch from approval to enablement.
Approval queues breed resentment; enablement clinics breed adoption. The single highest-leverage change a struggling EA function can make is to replace its weekly “design review board” with a weekly office-hours clinic where the answer is never “no” — it’s either “here’s the template,” “here’s the ADR you should write,” or “here’s the exception process and what it costs you in regulatory risk.”
Boards that block decisions get routed around. Clinics that accelerate decisions get filled.
2. Federate by capability, not by project.
Central architecture teams scale to about 12 architects before they collapse under their own coordination overhead. Past that, the only stable shape is a small central function (3–5 architects) that owns cross-cutting concerns — capability model, principles, target-state, vendor strategy — plus federated architects embedded in the streams that need them most.
Team Topologies calls this an enabling team plus stream-aligned architects. The federation question is always: which streams actually need an architect? Usually it’s the 2–3 most-coupled domains (often payments, identity, and core data) plus any cross-stream initiative whose decisions will be hard to undo later.
3. Make ADRs the unit of work.
An Architecture Decision Record is a dated, short, durable document that captures one decision: context, options, decision and consequences. The format originated with Michael Nygard. The practice has been around for a decade. Almost nobody in regulated enterprises uses it consistently.
The discipline change is simple: refuse to discuss an architectural decision that doesn’t have a written ADR. If someone brings up a decision verbally, the response is “write it up as an ADR; we’ll discuss the document.” Within a quarter, the decision velocity in the org doubles, because the verbal re-litigation cycle ends.
ADRs in a repo (versioned, diffable, searchable) survive leadership change. Slide decks die in shared drives.
4. Encode the top three principles. Subtract the rest.
Pick your top 10 principles. Ask the test above. Encode the top three as policy-as-code (OPA, Kyverno), platform defaults (Terraform module choices), or paved-path templates (Backstage scaffolders). Then look at the remaining seven and ask honestly: which of these would the org notice if I deleted them tomorrow?
The answer for most is “none.” Those principles aren’t enforced and aren’t cited. They take up cognitive load and produce no behaviour change. Subtract them. The remaining encoded principles will be cited because every developer hits them weekly.
What the encoded EA function looks like.
Once these four moves land, the EA function changes shape. It becomes small (3–5 people centrally + embedded architects). It becomes mostly invisible to delivery teams because the platform enforces what it decided. The principles it writes are short, encoded, and cited. The capability model is a living artefact in a tool people open daily, not a wall-poster from 2022.
The function’s output stops being “architecture artefacts” and becomes “platform behaviour change.” You measure it by the same things you measure platform engineering by: time-to-first-audited-deploy, change-fail rate, time-from-decision-to-implementation, and the percent of services that inherit your principles by default rather than opting in.
The Chief Architect, in this model, becomes the person who can articulate which substrate investment buys the next compound gain across all four disciplines — not the person who chairs the design review board.
The 2026 version of the job.
Two forces have pulled the rug out from under the traditional EA function this year. The first is the EU AI Act and its peers, which make “decisions about AI systems” legally consequential in a way they weren’t a year ago — and which the EA function is nominally responsible for. The second is the rise of platform engineering as a discipline serious enough to absorb most of what EA used to claim ownership of (paved paths, principles encoded as templates, observability defaults, IAM patterns).
Both pressures push the EA function toward the same place: smaller, more federated, more substrate-aligned, more legibly accountable for compound outcomes than for individual artefacts. Architecture principles that aren’t encoded don’t exist. Architecture functions that don’t encode don’t last.
It’s also the most enjoyable shape the function has had in a decade. The work moves from writing about systems to changing how systems get built. The deliverable changes from a slide deck to a merged PR.
That is the job worth doing.