Introduction
Inter-unit domain relationships in the Orthogramic Metamodel articulate how organisational units interact with and depend upon various domain entities—such as capabilities, information assets, services, value streams, initiatives, and products. These relationships provide a structured means to model and analyse the distribution of responsibilities, dependencies, and collaborations across different parts of the organisation.
By explicitly defining these relationships, organisations can:
Clarify roles and responsibilities across units for specific domain entities.
Identify and manage dependencies, facilitating better coordination and risk mitigation.
Assess the strength of interactions, enabling prioritisation of governance and resource allocation.
Support strategic planning by understanding how organisational units contribute to and rely on key domain entities.
Each inter-unit domain relationship specifies:
The type of domain entity involved (e.g., Capability, Service).
The organisational unit participating in the relationship.
The nature of the relationship (e.g., Owning, Consuming).
The strength of the relationship, rated on a scale from 1 (very weak) to 5 (very strong), indicating the intensity or criticality of the interaction.
This structured approach facilitates a comprehensive understanding of organisational dynamics, supporting informed decision-making and effective enterprise architecture practices.
Role types for inter-unit domain relationships
Role type | Definition | Usage guidelines |
|---|---|---|
Owning unit | The unit accountable for the governance, lifecycle, and quality of the domain entity (e.g. capability, information asset, or policy). | There should be only one owning unit per entity. Ownership includes strategic alignment, funding decisions, and compliance responsibility. |
Providing unit | The unit that delivers the core functionality, service, or resource associated with the domain entity. | A unit may provide for multiple consuming units. May or may not be the same as the owning unit. Must coordinate service delivery or access management. |
Consuming unit | The unit that actively uses the outputs or results of the domain entity to perform its own operations. | Typically refers to service consumption or data usage. Consumption should be traceable to specific processes or value streams within the consuming unit. |
Utilising unit | A broader term than consuming, denoting any unit that benefits from the domain entity, even if indirectly (e.g. benefits from insight, capability). | Use when a unit depends on value derived from the entity but does not consume or operate it directly (e.g. using KPIs or policy effects). |
Custodian unit | The unit responsible for maintaining integrity, accuracy, and compliance of an information or data entity. | Commonly applied to information, records, and policies. The custodian ensures the content remains authoritative, secure, and consistent with standards. |
Dependent unit | The unit whose ability to achieve its objectives relies on the effective functioning of another unit’s domain entity. | Use to highlight indirect or downstream impacts, especially in strategic or compliance-sensitive environments. |
Supported unit | The unit that gains operational advantage or risk reduction as a result of another unit’s domain activity, but is not actively consuming it. | Typically used where benefit is derived passively (e.g. safety improvement from another unit's policy implementation or data cleansing initiative). |
Governing unit | The unit responsible for setting rules, standards, or oversight mechanisms for the domain entity and ensuring compliance across all related units. | Typically applies to policies, regulatory frameworks, or enterprise architecture standards. Governing units may audit, direct, or override other roles to ensure alignment. |
These roles allow for precise modelling of interdependencies, enabling traceability, governance, and impact analysis across organisational functions.
Defining relationships
Inter-unit domain relationships describe how specific business domains (such as Capabilities, Information, Services, or Value Streams) are supported, governed, consumed, or otherwise utilised by different organisational units within the enterprise. These relationships are used to clarify the operational and strategic dependencies across the business.
Valid domain types
The following domain types may be used as the focal point for inter-unit relationships:
Domain | Typical inter-unit relationship usage | Notes |
|---|---|---|
Capability | Owning, utilising, supporting, consuming, dependent, custodian | Most commonly used; a central anchor for inter-unit coordination |
Information | Providing, consuming, custodian, dependent | Typically shared across units with a clear lineage of stewardship |
Service | Owning, providing, consuming | Represents operational service dependencies between units |
Value stream | Shared, contributing, dependent | Highlights collaborative delivery of customer or internal value |
Initiative | Supported by, accountable to | May be indirectly implied rather than structurally modelled as a relationship |
Product | Supported, owned, developed by | Used sparingly in inter-unit context; product-level relationships tend to be value stream mediated |
Note: Not all domain types are suitable for direct inter-unit relationship modelling. For example, Strategy, Policy, and Performance are usually overarching or analytical and are more often linked to organisational roles or artefacts than mapped through inter-unit relationships.
Recommendations
The Capability domain should be the primary entry point for defining inter-unit relationships. It acts as a stable anchor and supports links to other domains such as Information and Services.
Consider cascading relationships. For example, an inter-unit relationship to a capability can imply indirect relationships to its supporting information or services.
Avoid over-modelling. Inter-unit relationships should reflect operational dependencies or governance needs, not every possible interaction.
Examples
Capability domain example
Capabilities may be shared, reused, or leveraged across the organisation. Clear designation of relationship roles supports investment planning, service level expectations, and architectural traceability.
Example:
The Workforce Planning capability is:
Owned by: People & Culture Division (owning unit)
Consumed by: Asset Management Division (consuming unit)
Supported by: Finance Division (supported unit)
This distinction provides a clear view of accountability (People & Culture), operational reliance (Asset Management), and enabling support (Finance).
Service domain example
Organisation-wide services are often designed and managed centrally but delivered to or used by many business units. Role clarity enables better service design, funding alignment, and continuous improvement.
Example:
The Learning and Development Service is:
Provided by: Learning Services Team (providing unit)
Consumed by: All departments (consuming units)
Governed by: People Strategy Group (governing unit)
Defining these relationships clarifies responsibility for experience quality, data, and outcomes.
Information domain example
Information assets typically flow between producing and consuming units. Assigning custodial and consumer roles ensures traceability and compliance.
Example:
The Employee Records Dataset is:
Maintained by: HR Operations Unit (custodian unit)
Consumed by: Payroll Unit (consuming unit)
Relied on by: Compliance Division (dependent unit)
This approach ensures that data stewardship is clearly defined and that consuming units know the appropriate contact points for change requests or data issues.
Relationship strength
To enhance the usefulness of inter-unit domain relationships in organisational analysis, a numeric relationship strength value may be added. This value provides a relative indication of the intensity, criticality, or frequency of interaction between an organisational unit and the domain entity. It is intended to assist in prioritising governance, resource allocation, or change management efforts.
Scale
Value | Description |
|---|---|
1 | Very weak – minor or occasional interaction |
2 | Weak – intermittent or low-impact interaction |
3 | Moderate – regular involvement or mutual dependence |
4 | Strong – frequent and important interaction |
5 | Very strong – mission-critical, embedded, or highly interdependent |
Note: Relationship strength is subjective and may vary by use case. It is often informed by data (e.g. usage frequency, support tickets, volume of transactions), expert judgement, or stakeholder interviews.
Relationship with Rationales
Rationales can support the understanding and maintenance of inter-unit dependencies by providing traceable justifications for why specific relationships exist or are being adjusted. For example, a rationale may clarify the strategic driver for one organisational unit depending on another for a critical capability, or explain a planned reduction in dependency due to capability duplication or risk.
Inter-unit domain relationships JSON
See: https://github.com/Orthogramic/Orthogramic_Metamodel
Schema fields
Field | Description | Example |
|---|---|---|
| The name or title of the domain entity involved in the relationship | Workforce Planning Capability |
| The domain type to which the entity belongs (e.g. Capability, Service, Policy) | Capability |
| The nature of the organisation unit’s role in relation to the domain entity | Owning unit |
| The name of the organisation unit holding the relationship role | Human Resources Division |
| A description of how the unit is involved with the domain entity | Responsible for workforce planning systems |