Domain Coverage Explained

The Orthogramic Metamodel includes 24 domains, significantly more than traditional business architecture frameworks. This page explains the design rationale and how to approach this breadth of coverage.

Design Philosophy

Explicit Over Implicit

The Orthogramic design philosophy favors explicit domain modeling over implicit inclusion:

Approach	Trade-off
Explicit domains	More domains, clearer boundaries, specific schemas
Implicit inclusion	Fewer domains, embedded concepts, interpretive flexibility

Both approaches are valid. Orthogramic chose explicit domains to enable:

• Clear schema definitions for each concept
• Targeted tooling and automation
• Precise cross-domain relationships
• Specific attribute modeling

Coverage by Design

The 24 domains weren't arbitrary additions. Each domain was included based on:

1. Distinct entity types — Different attributes and behaviors
2. Relationship patterns — Unique connection patterns to other domains
3. Organizational ownership — Different teams typically responsible
4. Evolution patterns — Different change dynamics
5. Practical need — Observed requirements from real organizations

Domain Organization

Conceptual Layers

The 24 domains organize into conceptual layers:

Domain Categories

Category	Domains	Purpose
Strategic	Strategy, Performance, Risk Management	Direction and measurement
Core	Capabilities, Value Streams, Information, Organization, Stakeholder	Foundational business architecture
Delivery	Initiatives, Policy, Products, Services	How value is delivered
Operational	Technology, Finance, Customer, Market	Operational execution
Specialized	Supply Chain, Manufacturing, Channel, People	Industry/function specific
Extended	Innovation, Sustainability, Intelligence, Social Change	Emerging concerns

Why Specific Domains Exist

Traditional Core (5 domains)

These align with established business architecture practice:

Domain	Why Explicit
Capabilities	Central to all BA frameworks
Value Streams	End-to-end value delivery view
Information	Data as strategic asset
Organization	Structure and accountability
Stakeholder	Who cares about what

Strategic Layer (3 domains)

Domain	Why Explicit
Strategy	Strategic objectives need distinct modeling from capabilities
Performance	KPIs and metrics warrant dedicated schema
Risk Management	Risk has distinct taxonomy, controls, treatments

Delivery Layer (4 domains)

Domain	Why Explicit
Initiatives	Projects/programs have distinct lifecycle
Policy	Rules and compliance need formal structure
Products	Physical/digital products differ from services
Services	Services have distinct attributes (SLAs, channels)

Operational Layer (4 domains)

Domain	Why Explicit
Technology	Direct capability-technology linkage needed
Finance	Cost, revenue, budget deserve explicit modeling
Customer	Customer-specific attributes beyond stakeholder
Market	Market analysis distinct from customer data

Specialized Layer (4 domains)

Domain	Why Explicit
Supply Chain	Complex supplier/logistics relationships
Manufacturing	Production processes are distinct
Channel	Distribution channels need dedicated modeling
People	Workforce planning beyond organization structure

Extended Layer (4 domains)

Domain	Why Explicit
Innovation	Innovation pipeline management
Sustainability	ESG and environmental objectives
Intelligence	Business intelligence and analytics
Social Change	Social impact (unique to Orthogramic)

Selective Adoption

You Don't Need All 24

Organizations should adopt domains based on relevance:

Organization Type	Typical Domain Focus
Financial services	Core + Finance + Risk + Customer
Manufacturing	Core + Manufacturing + Supply Chain + Technology
Professional services	Core + People + Customer + Services
Government	Core + Policy + Stakeholder + Services
Healthcare	Core + Risk + Policy + Customer + Technology
Retail	Core + Products + Customer + Channel + Supply Chain

Coverage Templates

Orthogramic's Coverage Template extension helps organizations define which domains matter:

{
  "templateName": "Financial Services Enterprise",
  "domainCoverage": [
    {"domain": "capabilities", "requirement": "required", "targetCoverage": 90},
    {"domain": "value-stream", "requirement": "required", "targetCoverage": 85},
    {"domain": "risk-management", "requirement": "required", "targetCoverage": 95},
    {"domain": "finance", "requirement": "required", "targetCoverage": 80},
    {"domain": "manufacturing", "requirement": "excluded"},
    {"domain": "supply-chain", "requirement": "optional", "targetCoverage": 30}
  ]
}

Adoption Path

A typical adoption path:

Comparison to Traditional Approaches

Traditional 4-Domain Model

Traditional frameworks focus on:

1. Capability — What we do
2. Value Stream — How we deliver value
3. Information — What we know
4. Organization — How we're structured

This provides excellent focus but embeds other concepts:

Embedded Concept	Where Embedded
Strategy	Capability strategic alignment
Products/Services	Capability outputs
Technology	Capability enablement
Finance	Capability cost
Risk	Assessment attribute

Orthogramic Explicit Model

Orthogramic makes these explicit:

Embedded Concept	Explicit Domain	Benefit
Strategy	Strategy domain	Distinct objectives, dependencies
Products/Services	Products + Services domains	Different attributes, lifecycles
Technology	Technology domain	Direct modeling, integration
Finance	Finance domain	Cost, revenue, budget modeling
Risk	Risk Management domain	Taxonomy, controls, treatments

Benefits of Explicit Domains

Clear Ownership

Each domain maps to organizational ownership:

Domain	Typical Owner
Finance	CFO organization
Technology	CTO/CIO organization
Risk Management	CRO organization
People	CHRO organization
Customer	CMO/CCO organization

Targeted Automation

Explicit domains enable targeted tooling:

• Finance domain → ERP integration
• Technology domain → CMDB integration
• Customer domain → CRM integration
• Risk domain → GRC platform integration

Precise Relationships

Explicit domains allow precise relationship modeling:

Capability --enables--> Value Stream Stage
Capability --requires--> Technology Component
Initiative --funds--> Capability Development
Risk --mitigates--> Capability

Schema Specialization

Each domain has tailored attributes:

// Finance domain attributes
{
  "costCenter": "string",
  "budget": "number",
  "currency": "string",
  "fiscalYear": "string"
}

// Risk domain attributes  
{
  "riskCategory": "enum",
  "likelihood": "enum",
  "impact": "enum",
  "controlEffectiveness": "enum"
}

Managing Complexity

Start Simple

Begin with domains that matter most:

1. Minimum viable: Organization, Capabilities, Stakeholder
2. Add value delivery: Value Streams, Initiatives
3. Add measurement: Performance, Strategy
4. Add as needed: Other domains based on requirements

Use Templates

Coverage templates define what's relevant for your context.

Focus on Relationships

The value is in connections between domains, not domain count.

Automate Where Possible

Schema-defined domains enable automation that reduces manual effort.

Summary

Question	Answer
Why 24 domains?	Explicit modeling of distinct concepts
Do I need all 24?	No—adopt based on organizational needs
How do I start?	Begin with core domains, expand as needed
What's the benefit?	Clear schemas, ownership, tooling, relationships
Is it more complex?	More domains, but each is simpler and clearer

The 24-domain model trades breadth for depth within each domain. Organizations choose which domains matter for their context and adopt incrementally.

Related Documentation

• Summary Comparison — Framework comparison
• Complexity Explained — Managing metamodel complexity
• Coverage Template — Defining domain scope