Complexity Explained
The Triodian 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. Each expectation sets a targetCoverageLevel for a domain (none, minimal, documented, analysed, governed, optimised):
{
"coverageTemplateID": "CT-QUICKSTART-001",
"name": "Quick Start",
"description": "Minimum viable coverage for an organisation starting its business architecture practice",
"sector": "Any",
"sizeCategory": "medium",
"expectations": [
{"domain": "organization", "targetCoverageLevel": "documented"},
{"domain": "capability", "targetCoverageLevel": "documented"},
{"domain": "stakeholder", "targetCoverageLevel": "documented"},
{"domain": "valueStream", "targetCoverageLevel": "minimal"},
{"domain": "initiative", "targetCoverageLevel": "minimal"},
{"domain": "performance", "targetCoverageLevel": "none"}
],
"createdBy": "architecture.team@example.com",
"createdAt": "2025-06-01T12:00:00Z"
}
Simplification Techniques
Required vs. Optional Attributes
Each domain schema distinguishes required from optional:
Capability Domain Example:
| Attribute | Required | Optional |
|---|---|---|
capabilityID | ✓ | |
title | ✓ | |
description | ✓ | |
purpose | ✓ | |
owner | ✓ | |
parentCapabilityID | ✓ | |
maturityLevel | ✓ | |
performanceIndicators | ✓ | |
dependencies | ✓ | |
toolsAndTechnologies | ✓ |
Minimal valid capability:
{
"capabilityID": "CAP-ONB-001",
"title": "Customer Onboarding",
"description": "Register and verify new customers",
"purpose": "Bring new customers into the bank quickly and compliantly",
"owner": "Retail Banking"
}
Full capability (when needed):
{
"capabilityID": "CAP-ONB-001",
"title": "Customer Onboarding",
"description": "Register and verify new customers across all channels",
"purpose": "Bring new customers into the bank quickly and compliantly",
"owner": "Retail Banking",
"orgUnitTitle": "Retail Banking Operations",
"orgUnitID": "OU-RBO",
"parent": "Customer Management",
"parentCapabilityID": "CAP-CM-001",
"maturityLevel": "defined",
"targetMaturityLevel": "managed",
"performanceIndicators": "Onboarding completion rate (target 95%)",
"dependencies": "Identity Verification capability (CAP-IDV-001)",
"toolsAndTechnologies": "Digital 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 | Capability-Performance 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 |
| Repeatable | + 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:
- Map existing concepts to Triodian domains
- Export existing data to Triodian format
- Validate against schemas
- 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
# (-r loads the shared vocabulary that capability.schema.json references)
ajv validate -s schemas/capability.schema.json -r schemas/common.schema.json -d my-capability.json
# Result: Valid or specific error messages
Code Generation
Generate types for your language:
// Generated TypeScript interface
interface Capability {
capabilityID: string;
title: string;
description: string;
purpose: string;
owner: string;
parentCapabilityID?: string;
maturityLevel?: 'initial' | 'repeatable' | 'defined' | 'managed' | 'optimizing';
performanceIndicators?: string;
// ...
}
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:
- Define L1 capabilities (10-15)
- Add L2 capabilities for priority areas
- Link capabilities to organization
- Add value streams when needed
Pattern 2: Initiative-Driven
Let change programs drive adoption:
- Model initiative in Initiatives domain
- Add impacted capabilities
- Link to strategic objectives
- Add performance indicators
Pattern 3: Integration-First
Start where you can integrate:
- Connect to existing data sources
- Populate domains from source systems
- Add relationships progressively
- 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