If the seven structural systems (Value, Work, Organisation, Information, Technology, Economics, Governance) are the physics of the enterprise, and Capabilities are the vocabulary, then Domains and Views are how we organize and navigate this complexity without becoming paralyzed by it.
You cannot comprehend an entire enterprise at once. If you try to map every connection across a large organization, you end up with an unreadable diagram that is immediately out of date.
To make this architecture actionable for decision-makers, architects, and consumers, we must slice the enterprise logically (Domains) and look at it through specific lenses (Views).
1. Domains: The Boundaries of Cohesion
A Domain is a logically bounded context of the business. It is an area of cohesive capability, operating independently enough that it doesn’t require constant, synchronous entanglement with the rest of the enterprise.
Crucially, a Domain is not a department. A department (like “HR” or “IT”) is an artifact of the Organisation system. A Domain is a sphere of business reality—such as “Customer Identity & Access,” “Core Order Routing,” or “Infrastructure Provisioning.”
Within every single Domain, all seven structural systems exist.
Why Domains Matter: Controlling the Blast Radius
In traditional, tightly-coupled businesses, a change in one area breaks something seemingly unrelated. By organizing the enterprise into Domains, architects create clear boundaries.
- High Cohesion, Loose Coupling: Inside a Domain, the Work, Information, and Technology are deeply entangled (High Cohesion). Between Domains, they communicate only via strictly defined contracts or APIs (Loose Coupling).
- Autonomy of Change: If the “Secure Enterprise Connectivity” Domain needs to update its network routing Technology or its access Governance, it should be able to do so without requiring permission from the “Payroll” Domain, provided the external contracts remain intact.
2. Views: The Stakeholder Lenses
If you put a 300-page architectural schematic in front of a CEO, they will ignore it. If you put a one-page “Value Strategy” slide in front of a network engineer, they cannot build from it.
A View is a filter applied to the architecture. It acknowledges that different stakeholders need to see different intersections of the seven systems to make decisions. The underlying reality remains the same, but the lens changes.
The Executive View (The “Why” and “How Much”)
- Focal Systems: Value, Economics, Governance.
- What it shows: This view strips away Work and Technology to focus on outcomes. It shows what Value is being generated, the Economics required to fund it, and the Governance risk profile accepted to achieve it.
- Used by: C-Suite, Board, Investors.
The Operational View (The “Who” and “How”)
- Focal Systems: Work, Organisation, Information.
- What it shows: This view reveals the actual engine of the business. It shows how human and automated nodes (Organisation) process data (Information) through specific activities (Work). It highlights bottlenecks, manual workarounds, and friction.
- Used by: COOs, Process Engineers, Department Heads.
The Engineering & Security View (The “What” and “Where”)
- Focal Systems: Technology, Information, Governance.
- What it shows: This view maps the hard infrastructure. It details how data flows across networks, where strict security baselines are enforced, and how physical or cloud hardware is structured. It translates the Governance system’s rules into hard-coded constraints within the Technology system.
- Used by: Chief Architects, Network Engineers, CISOs.
3. How to Use This Architecture
Understanding the framework is only half the battle. Here is how architects and business leaders actually deploy it in the field.
A. Designing a Transformation (Impact Analysis)
When the business decides to introduce a massive change—such as rolling out a new product line or migrating thousands of users to a new secure network architecture—the framework acts as a checklist for reality.
- Define the Capability: What is the new vocabulary? (e.g., “Zero-Trust Remote Access”).
- Isolate the Domains: Which Domains will this touch?
- Cross the 7 Systems: For every affected Domain, you map the change.
- Work: Do user workflows change?
- Governance: How does this alter our compliance posture?
- Economics: What are the new licensing and operational costs?
- (Repeat for all 7)
If a transformation plan only has a budget (Economics) and a software vendor (Technology), the framework immediately flags it as guaranteed to fail upon colliding with Work and Organisation.
B. Diagnosing Failure (Root Cause Analysis)
When a critical failure occurs, natural instinct isolates the blame to the immediate symptom. If a secure connection drops, the blame falls on Technology. If a customer is angry, the blame falls on Work (a bad process).
Using the architecture, you trace the failure vertically. A catastrophic data breach might manifest in Technology, but the root cause trace usually reveals a failure in Governance (poor risk policy), which was caused by bad Information (no visibility into assets), driven by a flawed Organisation structure (security team lacked authority).
C. Communicating with Consumers and Stakeholders
Consumers (whether internal staff consuming IT services or external buyers) do not care about your Work, Information, or Technology. They only experience the Value and the Economics (price).
By using the right View, the business can translate complex backend realities into simple consumer promises. It prevents leaders from exposing their internal operational chaos (Systems 2 through 7) to the people who only care about System 1.