In the Orthogramic, relationships between business architecture elements are inherently directional, conveying the flow of influence, control, or dependency.
Cross domain relationships connect elements across different domains (e.g., Strategy, Capability, Initiative) within the same organizational context. These relationships are typically modeled from active domains—such as Strategy, Capability, Initiative, Policy, and Stakeholder—to passive domains like Information, Performance, Product, and Service. This directionality ensures semantic clarity and consistency in modeling, visualization, and reasoning.
Inter-domain relationships illustrate how elements from different domains interact across organizational units. While directionality remains important—indicating, for example, that a Capability in Unit A depends on a Service in Unit B—the strict active/passive domain distinction is less rigid. In this context, the focus shifts to organizational dependencies and the flow of responsibility between units, rather than solely on domain roles.
This page outlines the principles and best practices for modeling these directional relationships, helping you maintain structural integrity and enhance the interpretability of your business architecture.
Some domains are active — they initiate, drive, or own relationships (e.g. Strategy, Capability, Stakeholder).
Others are passive — they are typically referenced, used, governed, or measured. These domains do not initiate relationships.
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 |
These domains typically do not initiate relationships. For example:
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.
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.
Passive domains include:
Information
Policy
Performance
Product
Service
Correct examples:
Strategy → Capability
Capability → Service
Initiative → Performance
Stakeholder → 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.
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.
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).
These relationships retain directionality, such as:
depends on
is enabled by
is governed by
delivers to
However, in this context, directionality is more about organisational dependency and flow of responsibility than about whether the source domain is conceptually "active."
In cross-domain relationships:
Directionality is based on the structural logic of the metamodel.
Only active domains (e.g. Strategy, Initiative) should initiate relationships.
In inter-domain relationships:
A Capability (active) in Unit A might rely on a Service (passive) in Unit B → this direction is valid.
But you could also show a Service in Unit B delivering value to a Capability in Unit A → and this too would be correct.
So while directionality is present, the active/passive rule is relaxed because:
The organisational context adds nuance.
The focus is on who depends on whom across units, not just structural domain logic.
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.