About — 8861 Lab
The essence of software systems is simple: convert business intent into outcomes. Start with an operating model. Use that to shape systems that reflect how the business actually works.
We think from the business inward to technology — not the inverse. That direction matters. Systems built the other way accumulate technical debt, unnecessary integrations, and years of patches and workarounds that make change expensive and risky. Systems built from a clear operating model stay aligned with the business that depends on them.
We believe this approach allows businesses to evolve into digital ecosystems — where external partners, in-house capabilities, and manual processes work together through shared contracts and events, each fulfilling its responsibilities on its own terms.
What we cover
Business architecture — how organisations model their operating model precisely enough that any capable team can implement it. The discipline of drawing the right boundaries before writing the first line of code.
Capability design — how responsibilities become software. The vocabulary of intents, events, domains, and contracts that lets business and engineering work from the same model rather than translating between two different ones.
Platform architecture — how capabilities connect into platforms that can evolve. Event contracts, orchestration, choreography, identity, trust — the patterns that make distributed systems manageable rather than chaotic.
Member and identity design — how the people who use a system are represented within it. Identity as a first-class architectural concern, not an afterthought bolted on at the end.
Working examples — we build things to prove the ideas. A fitness platform. A hotel check-in system. Real APIs, real event contracts, real code. Because architecture that cannot be demonstrated is just opinion.
Where this comes from
The ideas in this publication did not start in a classroom. They emerged from building a real platform — a fitness management system that required solving the hard problems of distributed architecture in practice. Boundaries that would not stay clean. Vendor integrations that coupled what should have been independent. Events that carried more meaning than any single framework could express.
The solutions drew from established disciplines — Domain-Driven Design for boundaries and vocabulary, CQRS for the separation of commands and queries, design by contract for formal boundary expression, event-driven and reactive design for communication patterns. Each discipline contributed something essential. None of them alone was sufficient.
Relative Architecture is the synthesis. A unified model that connects these disciplines into a single coherent view — one that a business architect and a developer can both work from, without either needing to be an expert in all of them.
The defining principle — self-similarity
The same architectural model applies at every level of decomposition. A module inside a capability follows the same pattern as a capability inside a domain, which follows the same pattern as a domain inside a platform. Decompose at any level and the structure repeats. This is the most important property the model has — it means the same vocabulary and the same boundary rules apply whether you are reasoning about an enterprise or a single capability.
At the capability level the boundary is determined by entity ownership. A capability owns one entity — or a set of entities so tightly bound that the same operator manages them and they change together. This is a more reliable test than any count of intents or lines of code. Scheduling and Reservations are never the same capability. They own different entities, serve different operators, and change for different reasons. They are always in the same domain — because a property manager thinks about availability and bookings as two sides of the same business concern.
At the domain level the boundary is determined by coherence. How many capabilities can a single person or team hold in their head simultaneously? Five to nine is the natural range — the point where one person can see the complete domain picture without losing track of the edges. Fewer often signals a boundary in the wrong place. More often signals a level of hierarchy that is missing.
The same reasoning applies at every level above. Intents follow the same self-similar pattern — each level exposes a curated set that represents meaningful outcomes at that level of abstraction. Not every intent at a lower level surfaces at a higher one. What bubbles up is what a caller at that level actually needs to express. The rest stays behind the boundary.
How we work
We leverage current tools — including artificial intelligence — to draw from a broader base of knowledge in our writing. Most of the concepts here are not brand new. They build on decades of thinking in software architecture, domain design, and systems theory. AI simply expands the range and depth of that foundation, the ideas, the judgment, and the point of view are ours.
Who writes here
8861lab is a growing body of work. New voices will join over time. If the ideas here resonate and you want to contribute, the door is open.
Start here
New to the publication? The Start Here series is nine short posts that cover the foundation. Begin with the manifesto and follow the thread. The rest of the publication builds from there. When you are ready, subscribe at the top of the page — it is free.