Getting Started by Problem Examples

Here are five "Getting started by problem" examples designed to help non-architects begin using the Orthogramic Metamodel in a practical, problem-led way. Each one identifies a common business issue, suggests a starting domain, and outlines a simple modelling pathway that builds confidence and momentum.

---

Problem 1: We Don't Know Who Owns What

"There's confusion about accountability, duplicated effort, or finger-pointing when services break down or decisions stall."

Start With

• Organization and Capabilities
• Use Inter-unit Domain Relationships

Steps

1. List major business units and what they are responsible for
2. Define a few key capabilities (e.g., Procurement, Customer Service)
3. Map who owns, uses, or supports each capability using standard roles:
   • Owning unit
   • Consuming unit
   • Supporting unit
4. Visualise overlaps and gaps to clarify responsibility

Example Output

For Data Engineers

This pattern maps directly to data ownership in your catalog:

• Owning unit → Data Domain Owner
• Consuming unit → Data Consumers
• Supporting unit → Data Stewards

---

Problem 2: Too Many Disconnected Projects

"Initiatives are not aligned to strategy or capabilities, leading to wasted effort and missed outcomes."

Start With

• Initiatives, Strategy, and Capabilities

Steps

1. List current initiatives or projects
2. Link each initiative to:
   • A strategic objective it supports
   • At least one capability it is meant to improve or enable
3. Identify where initiatives are not clearly aligned — flag for review
4. Use this map to support investment decisions and consolidate effort

Example Table

Initiative	Strategic Objective	Target Capability	Alignment Status
CRM Upgrade	Customer Experience	Customer Relationship Management	✅ Aligned
Legacy Migration	Cost Reduction	Data Center Operations	✅ Aligned
Innovation Lab	Digital Transformation	Innovation Management	⚠️ Needs Review
Office Renovation	—	—	❌ No Link

---

Problem 3: Decisions Without Understanding Value Flow

"Decisions about processes, teams, or systems are made in isolation without seeing how they contribute to end-to-end outcomes."

Start With

• Value Streams and Capabilities

Steps

1. Identify a major product, service, or customer journey
2. Model the stages from start to finish (value stream stages)
3. Link stages to supporting capabilities and responsible business units
4. Use this to identify bottlenecks, duplication, or misalignment

Example: Order-to-Cash Value Stream

For Data Engineers

Value streams map directly to data pipelines. Each stage can be linked to:

• Data inputs and outputs
• Data quality checkpoints
• Pipeline stages in Airflow, dbt, or similar tools

See Value Stream to Pipeline Mapping.

---

Problem 4: Struggling to Respond to External Changes

"External events (regulatory shifts, market changes, customer demands) trigger uncoordinated, reactive responses."

Start With

• Strategic Response Model (SRM), Triggers, and Initiatives

Steps

1. Identify recent business pressures (e.g., new law, technology change)
2. Document them as Triggers in the SRM
3. Link each trigger to one or more Rationales for change
4. Show which strategies, initiatives, or policies have been activated in response
5. Use this to improve visibility and coordination across responses

Example: Regulatory Response

{
  "triggerID": "TRG-REG-2024-001",
  "title": "GDPR Article 17 Update",
  "triggerType": "Regulatory",
  "source": "EU Data Protection Authority",
  "detectedDate": "2024-06-15",
  "response": {
    "rationales": ["RAT-COMP-2024-001"],
    "affectedCapabilities": ["Data Retention", "Customer Data Management"],
    "activatedInitiatives": ["INIT-PRIVACY-2024"]
  }
}

---

Problem 5: Inconsistent and Unanalysable Documentation

"Information about how the business operates is locked in slide decks, spreadsheets, and people's heads."

Start With

• Capabilities, Information, and Performance

Steps

1. Pick one function (e.g., Incident Management, Onboarding)
2. Model it as a capability, identifying:
   • Supporting data
   • Performance indicators
3. Use the structured fields in the schema to describe it consistently:
   • Inputs
   • Outputs
   • Owner
   • Compliance requirements
4. Use this approach to begin replacing ad hoc documentation with structured, analysable assets

Example: Capability Definition

{
  "capabilityID": "CAP-IM-001",
  "title": "Incident Management",
  "description": "Ability to detect, respond to, and resolve operational incidents",
  "capabilityCategory": "Operational",
  "owner": "IT Operations Manager",
  "orgUnitTitle": "IT Service Desk",
  "inputs": ["Incident Reports", "Monitoring Alerts", "User Tickets"],
  "outputs": ["Resolution Records", "Post-Incident Reports", "SLA Metrics"],
  "performanceIndicators": [
    "Mean Time to Resolution (MTTR)",
    "First Call Resolution Rate",
    "Customer Satisfaction Score"
  ],
  "maturityLevel": "Level 3 - Defined",
  "complianceRequirements": ["ITIL", "ISO 20000"]
}

For Data Engineers

This structured approach means you can:

• Validate capability definitions against the JSON schema
• Query capabilities by owner, maturity, or compliance
• Link capabilities to data assets in your catalog
• Track performance metrics in your BI tools

---

Choose Your Starting Point

Problem	Recommended Domains	First Action
Unclear ownership	Organization, Capabilities	Map 5 key capabilities with owners
Disconnected projects	Initiatives, Strategy	Link 10 initiatives to objectives
No value visibility	Value Streams	Model one end-to-end journey
Reactive to change	SRM, Triggers	Document one recent external pressure
Inconsistent docs	Capabilities, Information	Structure one function as a capability

---

Ready to apply these patterns? Complete the Getting Started Worksheet to document your first domain.