8861 Lab (Page 1)

Sign in Subscribe

Latest — 16 Mar 2026

The Relative Architecture Manifesto

Ten principles. The foundation everything else builds on. 1. Organizations deliver value by fulfilling responsibilities. 2. Responsibilities originate in the business or product domain, not in technology. 3. Architecture should model responsibilities before modeling systems. 4. Responsibilities may be fulfilled by people, partners, manual processes, or software capabilities. 5. Capabilities

More issues

Organizations deliver value by fulfilling responsibilities

A business does not deliver value by running software. It delivers value by fulfilling responsibilities — to customers, to partners, to staff. Software is one way of fulfilling those responsibilities. So are people. So are partners. So are manual processes. This distinction matters because it changes where architecture starts. Architecture that

Architecture should model responsibilities before modeling systems

Most architecture diagrams show systems. Boxes labeled with technology — the booking service, the payments database, the notification queue. These diagrams describe what exists. They do not describe why it exists or what it is responsible for. Relative Architecture starts differently. Before a system is named, a responsibility is named. What

A responsibility does not have to be software

Line four of the manifesto is the one most architecture writing skips. Responsibilities may be fulfilled by people, partners, manual processes, or software capabilities. This is not a concession. It is a design choice. When you model a responsibility before deciding how to fulfil it, you have options. A concierge

Intent requests outcomes. Events share facts.

Responsibilities collaborate in exactly two ways. When one responsibility needs another to produce an outcome, it expresses intent. Book this room. Process this payment. Assign this coach. Intent is a request — it names the desired outcome and leaves the how to the responsibility that owns it. The requesting party does

System behavior emerges. It is not designed top-down

No single person designed how a city works. The traffic patterns, the economic flows, the way neighbourhoods develop character — these emerge from millions of individual decisions made by people and organisations operating within their own domains, reacting to facts, expressing intent. A well-designed distributed system works the same way. Consider

The same model, all the way down

A single booking at one gym. A gym chain operating across twenty locations. A fitness network connecting hundreds of operators. A global platform serving millions of members. The same model applies at every level. Each level has responsibilities. Each fulfils them through capabilities. Each communicates through intent and events. Each

A domain owns its vocabulary. It never borrows from its callers

Manifesto line eight — domains organize responsibilities and their vocabulary — carries a consequence that is easy to miss. The vocabulary a domain uses to describe its work is not negotiable with its callers. A domain that names things the way its consumers name them loses its own identity. It becomes pulled

What you will leave with

Four roles. Four different reasons to be here. If you are a business leader You will understand why your technology investments keep producing systems that are hard to change — and what a different approach looks like. You will be able to have an informed conversation with your architects and engineers