Building Blocks Overview

The O-AA perspectives introduced in O-AA Building Blocks are not layers; they are views that translate into the concerns of Building Blocks Logic. The “Experience” and “Product” concerns relate to the “Experience Perspective”, the “Operations” concern relates to the “Work System Perspective”, and the “Software and Hardware” concern relates to the “Technical System Perspective”. The concerns are focused upon:

  • Experience, to target the right customers and identify unserved needs

  • Product, to deliver the value proposition and the customer experience

  • Operations, to design the value stream and operating model that produces or operates the product

  • Software and Hardware, to automate the product and the operations that support it

Building Blocks Logic

Building Blocks Logic also highlights a fifth concern, Organization, which belongs to the “Work System Perspective” and is related to the other concerns via the Inverse Conway Maneuver; see Axiom 12. Organization Mirroring Architecture.

The Experience concern provides an outside-in view that informs product development. “Value-Driven” implies that unlike some Agile methods that prioritize features, this document prioritizes business objectives and outcomes. Features must solve business objectives, measured by Key Performance Indicators (KPIs).

Figure 1. Building Blocks Logic

In alignment with Learnings from Socio-Technical Systems, this document recommends developing concurrently the technical and social systems of the enterprise. This document is not about aligning the “Information System” layer with the “Business” layer. Business decisions impact all concerns, including software and hardware concerns. For example, when Jeff Bezos issued his mandate, he made a software architecture decision and a business decision to impact Amazon’s organization and strategy:

  • All teams will henceforth expose their data and functionality through service interfaces

  • Teams must communicate with each other through these interfaces

  • There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever

  • The only communication allowed is via service interface calls over the network

  • All service interfaces, without exception, must be designed from the ground up to be externalizable

By prohibiting any form of inter-process communication other than a service call, Jeff Bezos laid the foundation of what would become “microservices” (Technical System Perspective). He also created the conditions for increased team autonomy by reducing inter-team dependencies (Work System Perspective). By requesting that all service interfaces be externalizable, Jeff Bezos enabled the creation of a third-party vendors market. This was instrumental in helping Amazon compete against eBay based on a two-sided market business model.

Now it is clear that the building blocks do not represent layers, the relationships that link them can be reviewed; see Building Blocks Dependencies.

Figure 2. Building Blocks Dependencies

The arrows in the diagram represent preconditions. For example, the arrow that links "Customer Research" to "Product Architecture" represents that the outcome of "Customer Research" is a precondition to starting "Product Architecture".

  1. “Agile Strategy” is deployed within the “Agile Organization”, which also influences strategy in a bottom-up manner.

  2. “Customer Research” feeds “Product Architecture”.

  3. “Customer Research” creates experience maps, which are then translated into journey maps by “Journey Mapping”.

  4. “Value Stream Mapping” models and improves the value streams that deliver products. When value streams have steps with customer interactions, they are mapped to the corresponding journey maps.

  5. “Product Architecture” may require new operational capabilities that “Operations Architecture” should deliver.

  6. “Product Architecture” is developed concurrently with “Software Architecture”, and incorporates software functionalities.

  7. “Operations Architecture” is developed concurrently with “Software Architecture”, and incorporates software functionalities.

  8. Applying the Inverse Conway Maneuver (see Axiom 12. Organization Mirroring Architecture), the organization is shaped to mirror the enterprise’s intentional architecture.

The building blocks are generic. They are applied at different levels of granularity.

Enterprise Decomposition

How to decompose an enterprise is a key architecture decision.

“Hierarchy, I shall argue, is one of the central structural schemes that the architect of complexity uses.” (Herbert Simon)

Simon observes that the word “hierarchy” usually refers to situations in which each of the sub-systems is subordinated by an authority in relation to the system it belongs to: “We shall want to consider systems in which the relations among sub-systems are more complex than the formal organizational hierarchy just described” [Simon 1962].

This is illustrated here using a banking example. At the top level, this universal bank is composed of three business lines: retail banking, wholesale banking, and global markets.

At the second level, the retail bank could be decomposed along a customer segment logic: consumer, small business, and enterprise.

Retail Banking Segmentation Example represents a third level of decomposition that mixes customer segments and product logic. This example illustrates that levels should not be confused with layers.

How retail banking is decomposed matters. Each bubble represents a modular part of the business which can operate in relative autonomy vis-à-vis other parts of the business. The fewer dependencies that remain are identified, standardized, and managed. For example, “Consumer Prospect On-Boarding” will order credit cards for new customers.

Figure 3. Retail Banking Segmentation Example

Segmentation Approach

Enterprise Segmentation Approach illustrates the O-AA segmentation approach, which is described in more detail below.

Figure 4. Enterprise Segmentation Approach

The highlighted rectangles represent building blocks, and the arrows represent direct links between the building blocks and work products.

“Agile Strategy” influences the definition of the enterprise’s “Top-Level Organization” (a). Business lines and corporate functions are defined or adjusted to support the enterprise’s strategic direction.

“Experience Design” discovers the products that meet the needs of client segments. “Product Architecture” explores the modularity–integrality trade-off, defines how to decompose products into “Modular Components” (b), and identifies product platforms.

“Operations Architecture” specifies the “Value Streams & Processes” that deliver products and design the target “Operating Model” (c).

“Domain-Driven Design” drives the decomposition of the domain into bounded contexts which are organized into “Context Maps” (d). Context maps (see Context Map) define the patterns that link bounded contexts; see Domain-Driven Design Context Map Upstream Patterns, Midway Patterns, and Downstream Patterns.

The “Modular Components” that compose products, the “Operating Model”, and the “Context Maps” are inputs to “Agile Organization”, which decompose the top-level organization into a “Teams of Teams” (e); guided by:

  • The “Inverse Conway Maneuver”, which advocates shaping the organization so that communication lines mirror intentional architecture boundaries; see Axiom 12. Organization Mirroring Architecture

  • “Socio-Technical System Design”, which advocates designing the technical and social sub-systems concurrently

  • Cognitive limits to the number of people with whom stable social relationships can be maintained (“Dunbar Number”), and the amount of information that working memory can hold at one time (“Cognitive Load”)

Mental Model Shifts

Summary of Mental Shifts lists the shifts that Agile Architecture requires.

Figure 5. Summary of Mental Shifts

Navigation Table

For supporting media, the Navigation Table contains hyperlinks to the other chapters of this document, which provide additional content to the materials covered in this chapter. The Part 2 hyperlinks follow the structure of O-AA Building Blocks.

Table 1. Navigation Table

Part 1. The O-AA Core:
A Dual Transformation
Architecture Development
Intentional Architecture
Continuous Architectural Refactoring
Architecting the Agile Transformation
Agile Governance
Axioms for the Practice of Agile Architecture

Part 2. The O-AA Building Blocks:
Agile Strategy
Agile Organization
Data Information and Artificial Intelligence (AI)
Software Architecture
Software Defined Infrastructure


What the Enterprise “Does”

What the Enterprise “Is”


Experience Design
Journey Mapping

Product Architecture

Work System

Lean Value Stream Mapping

Operations Architecture

Technical System

Event Storming

Domain-Driven Design: Strategic Patterns