Functional Enterprise Architecture

It Wasn’t a Problem Until It Was.

Holding my build context loosely — in my head, in half-finished notes — had never been a problem. Then I spent a stretch tuning two Intel GPUs into one box, and the machine started rebooting on its own schedule, not mine — more than a dozen blue screens across the bring-up. The first few times a crash landed mid-build, I lost the thread completely. Where was the agent? What was half-finished? What was the next step? When the reboot isn’t optional, “I’ll remember where I was” stops being a plan.

Rehydrating that by hand after every crash is what forced the discipline. Not for tidiness — for recovery. A fresh session, or a fresh agent, should be able to open the repo cold and know exactly where the last one stopped.

The Formats That Kept Showing Up.

None of this fell out of the sky. The strategy was always deliberate — what took time was learning which pieces earned their place. Across a stack of projects, the same small set of document types kept showing up, each doing one job. They just needed a name.

Here they are:

Eleven types. Not one invented for this article — every one is a real file in a real repository, each traceable to a path and a date.

Role, and Status.

Forget the rows for a second. The architecture is in the two columns.

The first is role: each document does exactly one job. A vision is not a roadmap. A roadmap is not a spec. A spec is not a decision record. When every document has one job, you always know which one to open — and which one to update when reality moves.

The second is status: each document tells you, in its own header, where it is in its life. Stable. Living. Locked. A starting prompt, not a brief. You can glance at a page and know whether to trust it as settled or treat it as a question still open. Most architecture rots silently because nothing on the page admits it has gone stale. Here, the page says so.

The Lifecycle Is the Trick.

Roles and statuses are the snapshot. The motion between them is the method. The documents move in an order:

The load-bearing move is near the front: a prompt comes before a brief. One document holds the open questions; a different, later document holds the locked answers. You do not over-specify early. You commit in stages — and the document’s type tells everyone how committed you are.

That sounds minor. It is the difference between a plan that survives contact with reality and a fifty-page spec that was wrong before anyone built from it. The prompt-stage document says so in its own first line: “a starting prompt, not a finished brief — the open questions are the point.” The architecture has a place for “we haven’t decided yet,” and it is a different place from “this is settled.”

“Functional,” Twice.

This is functional enterprise architecture in two senses, and both matter.

It functions — it gets used. These documents are not a deliverable filed after a review; they are the surface the work runs on. People open them because they are the fastest way to remember what is true. An architecture that gets read stays current; an architecture that is filed rots. Use is the maintenance mechanism.

And it is organized by function — each type does one job, so the whole set stays legible as it grows.

Then there is the part that is new this year. The same documents that keep a person oriented are now what let an AI agent operate the system without having built it. Point a capable agent at a folder like this and it can act — because the judgment is written down where it can be read, not trapped in a head.

What This Is Not.

The honest limitations, because the limitations are where the truth is.

It is a practice, not a product. No tool enforces it. Nothing stops you from writing a “brief” that is really a prompt, or letting a “living” document die. The discipline is the product — and discipline is the thing that does not come in a box.

It does not replace judgment. The taxonomy tells you where a decision lives, not what to decide.

And it emerged tacitly. The discipline ran for months before it had a name. In hindsight it is a clean taxonomy — but the honest sequence was do the work, then notice the shape. Naming it is cheap. Running it, day after day, under deadline, is the cost.

Two Ways to Read This.

For engineers. Your ADRs, your manifests, your design briefs, your runbooks already are agent-readable architecture — you may just not be treating them that way. Two cheap upgrades: put a status header on every document so its stage is glanceable, and adopt the prompt-before-brief discipline so you stop over-specifying decisions you have not made yet. Both are free. Both compound.

For the people who run engineering organizations. This is key-person risk and audit cost, made concrete. Enterprise architecture usually fails not because people do not value it, but because the artifact is divorced from the work, so it rots. Architecture that is the operating surface gets maintained for free, because the team needs it to function. When the judgment lives in typed, current documents instead of one senior person’s head, a new hire — or a new agent — picks up the system in a session, not a quarter. In a regulated shop, “operable from the files alone” is not a nicety. It is the audit.

Where to Start — Smaller Than You Think.

Here is the honest advice, not the framework pitch: don’t adopt all eleven. You don’t need MCP servers or a database or session management to begin. You already know Git. You already know markdown. Build a system for yourself first — the right shape is different for every project, team, and size, and this is what works for me, not the one true way.

The smallest step that pays for itself immediately is the retrospective. At the end of a stretch of work, write a retro, update the README, and capture any real decisions as ADRs. That is one habit and three formats. I wrapped it in a single command — /retro — so the contract is standardized and the context overhead disappears; a sibling command, /sup, reads it all back when you sit down next. Do only that, and you are already ahead of most teams: a consistent bar to measure your own projects against, written down where you — or an agent — can pick it up cold.

What It Actually Takes.

It started as clues for myself — left without knowing what I’d need when I came back looking, only that I would.

Then producing code became effectively free, and the ability to generate outran the ability to remember. You know how that ends: you open something you built and ask — what is this, why did I build it like this, what was I thinking?

So the clues stopped being optional. A retro, a README, an ADR — notes to the next person who opens the repo. Most of the time that person is you, a month later, with no memory of the call you made.

The part I didn’t see coming: the things that helped me remember helped the agents remember too.

Is that “enterprise architecture”? Maybe. Mostly it is a documentation habit that scales. Start with the retro. Find the shape that works at your scale, and grow it only when a project asks. The expensive part was never the structure — it was deciding what’s worth keeping. You can start today, with the tools already on your machine.