8861 Lab (Page 2)

Sign in Subscribe

More issues

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

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

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

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

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

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