Observability reveals what happened. Reflectivity enables learning from what happened. But neither is possible without architecture that supports them. This chapter examines what architecture actually means, why most definitions are incomplete, and how ORA treats architecture as a measurable, first-class concern.
Defining Architecture
We often act like we all agree on what architecture means. We don’t. Here’s the problem: most definitions of software architecture are incomplete. They describe structure, or tooling, or intent, but not behaviour, drift, or entropy.
In most organizations, architecture lives in four overlapping states.
- As Imagined: What leadership believes exists, usually based on strategy decks and hope.
- As Prescribed: What architects claim should exist, captured in diagrams and documents.
- As Disclosed: What the system appears to be doing, according to dashboards and metrics.
- As Done: What the architecture actually is, as observed in production under pressure.
Let’s dig into the meaning of each.
As Imagined
How leadership believes the system is built, usually from strategy decks and other static artefacts.
- Vision may exceed implementation, and in some organizations, cultural dynamics can obscure the gap
- Divergence here is the origin of most strategic surprises, like failing an audit
- Only culture can align imagination with reality
As Prescribed
How architects say the system should be built, defined in documents and diagrams.
- Assumes alignment between design and execution
- Often clean, elegant, and aspirational
- Can devolve into the ivory tower cliche
- Some organizations lack architectural planning altogether
As Disclosed
What dashboards, metrics, and diagrams suggest the system is doing.
- Reflects what’s observable, but not necessarily what’s true
- Depends on the quality of signals that the system emits
- Easy to game, like low performers self-reporting “elite” metrics
As Done
What the system actually is: warts, drift, hacks, and all. Ask your operators and support engineers.
- Reality lives here: what’s deployed and how it behaves under pressure
- This is the only version of architecture that matters on rota at 3am
- This drives customer and employee experience, shaping long term outcomes
When architecture looks completely different depending on the window you’re looking through, systems become hard to reason about, hard to trust, and harder still to change. Real architecture lives inside the system, but it also depends on who you ask (like an operator after a long and painful support shift).
We’re all looking at the same moon, just from different windows.
The real danger begins when what is imagined and what is prescribed look solid, but developers, tech leads, support engineers, and SREs experience something completely different. When the people doing the work are building and operating a system that behaves nothing like what leadership believes it to be, the disconnect becomes dangerous.
Architecture must be restored as a first-class concern. Architecture revealed through telemetry and lived experience must align with the version described in planning sessions and design documents. When that alignment breaks, trust breaks with it. And without trust, neither observability nor reflectivity can exist.
ORA as a Unified Practice
Observable Reflective Architecture (ORA, pronounced aura) is an architectural practice rooted in the principle that system behaviour must be understandable at every level and across every phase of the development lifecycle: during design, at runtime, and post-hoc for analysis, audits, or postmortems.
The philosophy behind this approach draws inspiration from Leslie Lamport’s foundational work on distributed systems, among other researchers and practitioners in this space. Specifically, Lamport demonstrated through TLA+ that a bug is nothing more than an invalid or unexpected state.1
By discarding detailed state-change data, systems lose the evidence needed to understand not just that a bug occurred, but why and how it happened. ORA addresses this directly by treating state transitions as a core architectural concern. It ensures that systems retain and explicitly record these transitions, turning runtime behaviour into durable evidence of correctness or failure.
This points to a deeper idea I want to explore with you. Correctness is not only something to verify during design or at compile time, it must also be observable during runtime. As Lamport wrote, “The question of whether a program behaves correctly is really the question of whether it satisfies its specification.”.2
Let me posit the following:
- An effective architecture brings specifications to life.
- Implementation then transforms static architecture into a continuous stream of verifiable facts, which are easily verified against the specification.
- That stream becomes the ground truth for understanding behaviour, uncovering root causes, and building confidence in complex, asynchronous systems. It not only enables verification of correctness, it also resolves the drift between architecture as imagined, prescribed, disclosed, and done.
As Ciancia et al. put it in their 2022 experience report: “observability makes architectures explainable, and should become a first-class citizen, especially in systems which demand increasingly the need to explain and expose their operations to the outside world”.3
Leslie Lamport, Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers, Addison-Wesley, 2002. https://lamport.azurewebsites.net/tla/book-21-07-04.pdf ↩︎
Leslie Lamport, How to Write a 21st Century Proof, 2012. https://lamport.azurewebsites.net/pubs/proof.pdf ↩︎
Ciancia et al., Event-Sourced, Observable Software Architectures: an Experience Report, 2022. https://doi.org/10.1002/spe.3116 ↩︎