| Table of Contents | ||
|---|---|---|
|
...
Source domain (e.g. Strategy)
Target domain (e.g. Capabilities)
Relationship type (e.g. influencesfunds, enables, supportssupported)
Directionality (uni- or bi-directional)
Examples:
Strategy → Capabilities (influences)
Capabilities → Value Stream (enables)
Value Stream → Initiative (delivers)
Stakeholders → Services (owns)
Policy → Information (governs)
These are maintained within the metamodel and visualised within Orthogramic Insights to support exploration and navigation.
Relationship type list
...
Node
...
Role type
...
consuming
...
supported
...
governing
...
constrains
...
enables
...
mitigates
...
monitors
...
drives_demand
...
responds_to
...
aligns_with
...
oversight_of
...
accountable_to
...
forecasts_for
...
funds
...
quantifies
...
reports_on
Directionality
Term | Description | Example |
|---|---|---|
Outbound | The entity initiates or points to another entity | A Capability enables a Value Stream |
Inbound | The entity is the target or receiving end of a relationship | A Capability is influenced by a Strategy |
Bidirectional | Both entities relate mutually or have reciprocal influence | A Policy both governs and is shaped by an Initiative |
For modelling clarity, relationships should originate from active domains and target passive ones.
For guidance on relationship directionality, see: Directionality in cross domain relationships
Example
This example that represents cross-domain relationships, organised logically from strategy to execution and support domains.
...
This diagram models how business architecture elements are linked across domains rather than across business units.
Description
Strategy → Capability: Strategic objective shapes capability investment.
Capability → Value Stream → Initiative → Service → Product: Core delivery chain.
Initiative → Performance: Execution linked to measurable outcomes.
Policy and Information: Support governance and data dependency relationships.
Stakeholder: Shows ownership and accountability.
Relationship type list
Icon | Relationship Type | Description |
|---|---|---|
 |
| Finance provides financial resources to another domain entity to enable its development, operation, or enhancement. |
 |
| Finance expresses the activities, outputs, or outcomes of another domain entity in measurable financial terms. |
 |
| Finance produces formal reports capturing the financial performance, costs, or returns associated with another domain entity. |
 |
| Finance projects future financial needs, costs, or revenues associated with another domain entity. |
 |
| One domain entity receives necessary resources, services, or capabilities from another domain entity to deliver its intended outputs or outcomes. |
 |
| One domain entity imposes limitations, standards, or compliance requirements on another domain entity’s design, operation, or evolution. |
 |
| One domain entity is essential for the successful implementation, operationalisation, or fulfilment of another domain entity. |
 |
| One domain entity actively reduces the risks or vulnerabilities associated with another domain entity. |
 |
| One domain entity oversees, measures, or evaluates the performance or effectiveness of another domain entity. |
 |
| One domain entity defines policies, standards, or decision rights that control the operation of another domain entity. |
 |
| One domain entity generates, influences, or amplifies the demand for another domain entity’s outputs, services, or capabilities. |
 |
| One domain entity is triggered, adapted, or activated in response to changes in another domain entity or external event. |
 |
| One domain entity uses, relies upon, or draws from the resources, outputs, or services of another domain entity. |
 |
| One domain entity is intentionally coordinated or harmonised with another domain entity in purpose, direction, or design without establishing a direct dependency. |
 |
| For systematic traceability of oversight responsibilities. |
 |
| For a clear line of responsibility between entities |
Use in document analysis
When documents are parsed, relationships between domains are inferred based on sentence structure, contextual clues, and declared associations (e.g. “This initiative improves customer engagement by enhancing CRM capabilities”).
...
Show how elements from different domains relate visually
Allow users to follow logical chains from Strategy through to Initiatives and Performance
Enable dynamic exploration of organisational alignment
Use in recommendations
Orthogramic uses cross domain relationships to:
Identify capability gaps blocking strategic goals
Recommend services or stakeholders needed for an initiative
Highlight policies or information dependencies that require attention
| Info |
|---|
Difference from inter-domain relationshipsCross domain relationships describe the conceptual and operational connections between different types of elements across domains (e.g. a Strategy influencing a Capability). They are structural to the metamodel and are not confined to any particular organisational unit. By contrast, inter-domain relationships focus on how these cross-domain connections manifest across different organisational units—for instance, how a Capability in one unit depends on a Service or Initiative governed by another. Inter-unit domain relationships are thus a subset of cross domain relationships, contextualised to show organisational span, dependency, and potential silos |
...
Extensibility
New relationship types can be added over time as the metamodel evolves. User feedback and document analysis are both sources for suggesting and validating additional relationship types
. |