This series introduces a philosophy of design and architecture that carries the spirit of early software craftsmanship into today’s systems. ORA is about building software that can explain itself from the inside out, making behaviour observable by preserving the reasoning behind every state transition.
Observability, Reflectivity, and Architecture
ORA stands for Observable Reflective Architecture. It’s a way of designing and building systems that puts explainability at the centre. Each property in the name delivers something specific:
- Observability for insight, so we can see what the system did and why
- Reflectivity for intelligence, so the system can learn from its own behaviour and evolve
- Architecture for achievability, so that insight and intelligence are structurally possible rather than aspirational
Systems are now being designed where humans and autonomous agents operate side by side, sharing responsibilities, making decisions, and shaping outcomes together. Architectures must support this kind of co-evolution. ORA provides the principles needed to build systems that can meet this challenge.
Each of these properties addresses a different dimension of explainability.
Observability
See what the system did and why.
- How a system exposes its internal state and behaviour so that both humans and machines can understand it
- Without observability, there’s no shared context, no feedback loop, and no way to guide or trust autonomous decisions
- Insight is what you gain when the system can answer the question “what happened, and why?”
Reflectivity
Learn from the system's own behaviour over time.
- Where observability lets you peer into a system, reflectivity determines what the system does with that visibility
- A reflective system can explain what just happened, trace it back to its cause, and adjust how it responds in the future
- Intelligence is what you gain when a system stops discarding its past and starts learning from it
Architecture
Make insight and intelligence structurally possible.
- Like a bridge that maps physics, soil composition, and seismic risk to a design that gets people across the chasm
- Architecture takes the constraints of distributed systems, production realities, and domain requirements, then maps them to a structure that can deliver the goal
- Without it, observability and reflectivity remain aspirations rather than outcomes
What This Series Covers
The fundamental tenet of ORA is that your architecture must be designed for observability and reflectivity based on a set of specific architectural principles. This is what makes a system explainable. The next three chapters explore each property in depth.
- Observability for Insight explores how architecture can amplify what observability tooling achieves, giving platforms a richer substrate of structured, causally linked events to work with.
- Reflectivity for Intelligence introduces the idea that systems can learn from their own behaviour, building on event histories to train, fine-tune, and continuously improve decision-making. This connects to the CHAIN maturity model we explore later.
- Architecture for Achievability examines what architecture actually means across four perspectives, from leadership’s imagination to the operator’s lived experience, and how alignment across all four is what makes observability and reflectivity structurally achievable.
With those principles established, we define the layered model that organises ORA’s goals, capabilities, and pillars, then examine each of the three technical pillars in depth: event-sourced, message-driven, and read-write decoupled. The final chapter puts ORA in context by contrasting it against other common architectural styles, then transitions to CHAIN.
By the end of the series you’ll have a set of principles for building systems that are not only functional, but explainable. That prepares us for the formal model of explainability we will explore in CHAIN.