Most of what goes wrong with a system was decided in its first fortnight, by someone who did not know they were deciding it.
Architecture is the set of choices that are cheap to make and expensive to revisit: where data lives, who is authoritative for it, what the system is permitted to assume, and where the boundaries fall. Made deliberately, they become the reason a system is still serving the business in a decade. Made by default, they become the reason it is replaced in three years.
What the work involves
- Data and ownership. What the system holds, where it is authoritative, and who is accountable for it.
- Boundaries. Which parts of the system are allowed to know about each other, and which must not.
- Infrastructure shape. What runs where, what it costs at rest and under load, and what happens when a component fails.
- Integration surfaces. How the system speaks to the software you already run, and how it will speak to whatever you buy next.
- Build against buy. An honest reckoning of which parts should be written and which should be licensed.
- Sequencing. What must be settled now, and what can be deferred without penalty.
Architecture is the part of the work that is cheapest to change and most expensive to get wrong.
What you receive
A written architecture rather than a slide deck: the decisions, the reasoning behind each one, and the options that were rejected and why they were rejected. Diagrams where a diagram is clearer than a paragraph. A sequence for the build, so the order of the work reflects the order of the risk.
It is written to be read by your team, by your board, and by whoever inherits the system long after we have gone.