| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Introduction
In the Orthogramic, relationships between business architecture elements are inherently directional, conveying the flow of influence, control, or dependency.
...
The following Orthogramic domains are considered passive:
Domain | Typical Role in Relationships |
|---|---|
Information | Referenced by, used by, governed by |
Performance | Measured by, contributed to, indicator of |
Product | Delivered by, enabled by, rarely strategic |
Service | Implements, delivers, used in context |
...
It’s more accurate to say a Capability uses Information than to say Information informs Capability.
A Policy governs Information — not the other way around.
A Performance metric is influenced by Initiatives, not vice versa.
Directionality
Cross domain
...
Passive domains must not initiate cross domain relationships
Applies to: Cross domain relationship definition and visualisation
Definition:
Cross domain relationships must be modelled with active domains as the source and passive domains as the target. Passive domains must not initiate outbound relationships.
...
relationships
In Orthogramic, cross domain relationships connect elements across different business architecture domains—for example, a Strategy influencing a Capability, or an Initiative delivering a Service. These relationships are directional, meaning they have a clear source and target. This direction helps you understand how one domain element affects or supports another.
To keep relationships meaningful and easy to interpret, Orthogramic follows a simple modelling approach:
Start from domains that drive change or define intent, and point towards those that describe supporting structures or results.
Common examples
Strategy → Capability — A strategy defines the direction that capabilities must support.
Capability → Value Stream — Capabilities enable specific value-creating activities.
Initiative → Performance — Initiatives aim to influence performance measures.
Stakeholder → Policy — A stakeholder is responsible for a policy.
Tip: think in terms of action
Ask yourself: “Which element is driving or shaping the other?”
If you're not sure, try framing the relationship as a sentence:
“This strategy influences the capability.”
“This initiative delivers the service.”
This helps ensure you’re modelling the direction correctly.
Relationship direction in visualisation
When exploring relationships in Insights:
Arrows point from the source (driver) to the target (effect)
This helps you follow the flow from strategic intent down to execution and results
Passive domains include
InformationPolicyPerformanceProductService
Correct examples
...
Strategy → CapabilityCapability → ServiceInitiative → PerformanceStakeholder → Policy
Incorrect examples
...
Information → Capability : informs❌Performance → Initiative : measured by❌Policy → Stakeholder : constrains❌
Implementation guidance:
In diagrams, passive domains only appear as targets.
In JSON or RDF representations, relationships originate from active domains.
Verbs such as informs, measures, or describes are used only in documentation, not as relationship types sourced from passive domains.
Reasoning
...
This ensures semantic clarity, avoids visual clutter, and supports reasoning engines that depend on clear relationship directionality.
Inter-domain
...
relationships
Directionality does apply to inter-domain relationships, but the active/passive domain distinction used in cross-domain relationships must be interpreted differently in an inter-domain context.
Overview
Inter-domain relationships show how elements of different domains are related across organisational units (e.g. how a Capability in Unit A relies on a Service in Unit B).
...
However, in this context, directionality is more about organisational dependency and flow of responsibility than about whether the source domain is conceptually "active."
Active/Passive domain roles are less rigid here
In cross-domain relationships:
...
The organisational context adds nuance.
The focus is on who depends on whom across units, not just structural domain logic.
Conclusion
Directionality is essential in inter-domain relationships.
Active/passive modelling constraints do not strictly apply — a passive domain element may be the source of an inter-unit relationship if it represents an organisational responsibility.