Method
Architecture on demand.
This practice's method is older than this website and simpler than it sounds: architectural effort is a cost, so we spend it only where it reduces a risk the organisation cannot afford to carry. The rest of the effort goes into building the working system. Its continuous variant, architecture as a service, means architectural oversight bought when a decision worth overseeing appears, instead of a staff position that has to justify itself.
Four rules of dosage
- 01
Proportional to risk
The measure of how much architecture is needed is the cost of reversing the decision, not the size of the project. System boundaries, the data model, identity, integrations, these are expensive to reverse, and they get analysis, a record and a review. At the bank that meant a full architecture board over a core system replacement; on a product build, one decision log and a one-page sketch of boundaries. Both were the right amount, because both were proportional.
- 02
The last responsible moment
We defer a decision until further delay would start removing options, because the most expensive architectures are built from answers to questions nobody has asked yet. In practice: foundations that cannot be added cheaply later go in from the first migration; features wait for proof of need; and every deferred decision has a written retreat path, down to fallback versions of dependencies.
- 03
Executable architecture
A standard no machine checks is an opinion with good meeting attendance. The architecture model lives in the repository, validation returns an exit code and works as a pipeline gate, and deviations exist only as dispensations with expiry dates. This is what evolutionary architecture calls fitness functions, except ours actually stops the build.
- 04
The minimal artifact: a decision
If one thing is to survive out of all architecture documentation, let it be the decision log: context, options considered, why the others were rejected. We also keep build-vs-buy tables with a verdict on every rejected option. Diagrams go stale; the reasons for decisions do not.
Lineage
We did not invent these rules, we assembled them from things others tested and named. Proportionality to risk is the thesis of George Fairbanks's Just Enough Software Architecture. Executable architecture is the fitness functions of Neal Ford and Rebecca Parsons's Building Evolutionary Architectures. The decision log in this form was described by Michael Nygard. The last responsible moment comes from Mary and Tom Poppendieck's lean software development, and the figure of the architect who writes code rather than judging it from above, from Martin Fowler's essay on architectus oryzus. Our contribution is elsewhere: in the discipline of applying these rules in environments that usually consider them too light, a bank, a regulated fintech, a plant floor.
How it runs
No two engagements are identical, but the order is usually the same.
- 01
Conversation
No deck and no commitment. What interests us is what specifically hurts and what happens if nothing changes. If that conversation shows we are not the right address, we say so immediately.
- 02
Reconnaissance
A few days spent seeing the actual state of things: the architecture, the process or the code, depending on the problem. We talk to the people who maintain the system, not only to those who commissioned it.
- 03
Diagnosis and direction
A report that works in the boardroom and in the engineering team: what is a risk, what can be left alone, what should be done in what order and roughly what it costs. Always with options rather than a single recommendation.
- 04
Delivery or oversight
Either we build, or we steer decisions alongside the client's team. In both cases documentation and decision records are written with the work, not after it.
- 05
Handover
Runbooks, an environment reproducible from the repository, and a walkthrough with the team taking over. We consider an engagement successful when it can be ended without harming the client.
AI in our own work
We use AI agents in day-to-day software delivery, one reason a small practice can keep more than a dozen production repositories moving at once. Exactly the same rule applies as with clients: the model proposes, tests and deterministic validation rule, a person answers for the result. Specifications and decision records are the source of truth; the code is their consequence.