Complexity Explained

The Orthogramic Metamodel is comprehensive by design. This page addresses common concerns about complexity and provides practical guidance for adoption.

Understanding the Complexity

Perceived vs. Actual Complexity

Perception	Reality
"24 domains is overwhelming"	Most organizations use 8-12 domains
"The schemas are too detailed"	Only required fields are mandatory
"It's too much for our team"	Adopt incrementally, not all at once
"We can't maintain this"	Schema validation reduces maintenance burden

Sources of Complexity

Source	Mitigation
Number of domains	Selective adoption via coverage templates
Attribute depth	Use only required attributes initially
Relationship types	Start with primary relationships
Schema formality	Leverage tooling for validation

Practical Adoption Strategies

Strategy 1: Start Minimal

Begin with the minimum viable model:

Phase 1 (Weeks 1-4): Organization, Capabilities, Stakeholder

• Establish who does what
• Map key capabilities
• Identify stakeholders

Phase 2 (Weeks 5-8): Value Streams, Initiatives

• Map value delivery
• Connect to change programs

Phase 3 (Weeks 9-12): Performance, Strategy

• Add measurement
• Link to strategic objectives

Strategy 2: Use Case Driven

Start with a specific use case and add domains as needed:

Use Case	Starting Domains	Add When Needed
Regulatory mapping	Organization, Capabilities, Policy	Risk Management, Information
Digital transformation	Capabilities, Technology, Initiatives	Performance, Value Streams
Customer experience	Customer, Value Streams, Capabilities	Products, Services, Channel
Cost optimization	Finance, Capabilities, Organization	Performance, Initiatives

Strategy 3: Template-Based

Use coverage templates to define scope:

{
  "templateName": "Quick Start",
  "templateType": "minimum-viable",
  "domainCoverage": [
    {"domain": "organization", "requirement": "required"},
    {"domain": "capabilities", "requirement": "required"},
    {"domain": "stakeholder", "requirement": "required"},
    {"domain": "value-stream", "requirement": "recommended"},
    {"domain": "initiatives", "requirement": "recommended"},
    {"domain": "performance", "requirement": "optional"}
  ]
}

Simplification Techniques

Required vs. Optional Attributes

Each domain schema distinguishes required from optional:

Capability Domain Example:

Attribute	Required	Optional
title	✓
description	✓
owner	✓
capabilityLevel		✓
maturityLevel		✓
performanceIndicators		✓
dependencies		✓
technology		✓

Minimal valid capability:

{
  "title": "Customer Onboarding",
  "description": "Register and verify new customers",
  "owner": "Retail Banking"
}

Full capability (when needed):

{
  "title": "Customer Onboarding",
  "description": "Register and verify new customers across all channels",
  "owner": "Retail Banking",
  "capabilityLevel": 2,
  "maturityLevel": "defined",
  "performanceIndicators": [
    {"name": "Completion Rate", "target": 95, "unit": "percent"}
  ],
  "dependencies": ["cap-identity-verification"],
  "technology": ["tech-onboarding-platform"]
}

Relationship Prioritization

Not all relationships need immediate modeling:

Priority	Relationship Type	When to Add
High	Capability-Organization ownership	Foundation
High	Value Stream-Capability enabling	Value mapping
Medium	Initiative-Capability transformation	Change programs
Medium	Performance-Capability measurement	Measurement phase
Lower	Cross-domain detailed relationships	Mature practice

Progressive Detail

Add detail progressively, not all at once:

Maturity Stage	Attribute Depth	Relationship Depth
Initial	Required only	Primary relationships
Developing	+ Key optional	+ Secondary relationships
Defined	+ Most optional	+ Cross-domain
Managed	Full attributes	Full relationship model

Common Concerns Addressed

"Our team doesn't have time for this"

Response: The schema approach reduces time:

Without Schema	With Schema
Define your own structure	Use provided structure
Manual consistency checking	Automated validation
Document format variations	Consistent JSON format
Integration effort	API-ready definitions

"We already have our own models"

Response: Migration path available:

1. Map existing concepts to Orthogramic domains
2. Export existing data to Orthogramic format
3. Validate against schemas
4. Maintain both during transition

"The executives won't understand this"

Response: Visualize, don't schema:

• Executives see capability maps, not JSON
• Schemas are implementation detail
• Business value is in the views and insights
• Technical rigor enables reliable reporting

"We don't need all these domains"

Response: Don't use them:

• Coverage templates define what's relevant
• Excluded domains have zero overhead
• Add domains only when value is clear
• The metamodel is a menu, not a mandate

Tooling Reduces Complexity

Schema Validation

Automated validation catches errors:

# Validate capability against schema
ajv validate -s capability.schema.json -d my-capability.json

# Result: Valid or specific error messages

Code Generation

Generate types for your language:

// Generated TypeScript interface
interface Capability {
  title: string;
  description: string;
  owner: string;
  capabilityLevel?: number;
  maturityLevel?: 'initial' | 'developing' | 'defined' | 'managed' | 'optimizing';
  performanceIndicators?: PerformanceIndicator[];
}

IDE Support

Schema-aware editors provide:

• Autocomplete for attributes
• Validation as you type
• Documentation on hover
• Error highlighting

API Integration

Schema-defined APIs enable:

• Consistent data exchange
• Integration with enterprise tools
• Automated documentation
• Contract testing

Success Patterns

Pattern 1: Capability-First

Organizations often succeed by starting with capabilities:

1. Define L1 capabilities (10-15)
2. Add L2 capabilities for priority areas
3. Link capabilities to organization
4. Add value streams when needed

Pattern 2: Initiative-Driven

Let change programs drive adoption:

1. Model initiative in Initiatives domain
2. Add impacted capabilities
3. Link to strategic objectives
4. Add performance indicators

Pattern 3: Integration-First

Start where you can integrate:

1. Connect to existing data sources
2. Populate domains from source systems
3. Add relationships progressively
4. Build views for stakeholders

Complexity Management Summary

Challenge	Solution
Too many domains	Use coverage templates
Too many attributes	Start with required only
Too many relationships	Prioritize primary relationships
Too much to maintain	Leverage schema validation
Too hard to understand	Visualize for stakeholders
Too hard to implement	Use generated types and tooling

Adoption Checklist

Getting Started

• Identify 3-5 priority domains
• Create coverage template for scope
• Document only required attributes initially
• Model primary relationships only
• Use schema validation from day one

Scaling Up

• Add domains based on use cases
• Expand attribute depth progressively
• Add relationship types as needed
• Integrate with enterprise tools
• Build stakeholder-appropriate views

Mature Practice

• Full domain coverage where relevant
• Comprehensive relationship modeling
• Automated validation and quality
• Integrated with data platforms
• Real-time architecture views

Related Documentation

• Coverage Template — Define adoption scope
• Domain Coverage Explained — Why 24 domains
• Getting Started — Adoption guidance