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.

We don’t know who owns or uses what across the business.

Problem: 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:

• List major business units and what they are responsible for.

• Define a few key capabilities (e.g. Procurement, Customer Service).

• Map who owns, uses, or supports each capability using standard roles (e.g. owning unit, consuming unit).

• Visualise overlaps and gaps to clarify responsibility.

We’re running too many disconnected projects.

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

Start with:

• Initiatives, Strategy, and Capabilities

Steps:

• List current initiatives or projects.

• Link each initiative to a strategic objective and at least one capability it is meant to improve or enable.

• Identify where initiatives are not clearly aligned—flag for review.

• Use this map to support investment decisions and consolidate effort.

We’re making decisions without understanding the flow of value.

Problem: 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:

• Identify a major product, service, or customer journey.

• Model the stages from start to finish (value stream stages).

• Link stages to supporting capabilities and responsible business units.

• Use this to identify bottlenecks, duplication, or misalignment.

We’re struggling to respond to external changes.

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

Start with:

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

Steps:

• Identify recent business pressures (e.g. new law, technology change).

• Document them as Triggers.

• Link each trigger to one or more Rationales for change.

• Show which strategies, initiatives, or policies have been activated in response.

• Use this to improve visibility and coordination across responses.

Our documentation is inconsistent and hard to analyse.

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

Start with:

• Capabilities, Information, and Performance

Steps:

• Pick one function (e.g. Incident Management, Onboarding).

• Model it as a capability, identifying the supporting data and performance indicators.

• Use the structured fields in the schema to describe it consistently (inputs, outputs, owner, compliance).

• Use this approach to begin replacing ad hoc documentation with structured, analysable assets.