Inter-unit domain relationships

1 Introduction
2 Role types for inter-unit domain relationships
3 Domain-specific relationship extensions
4 Defining relationships
5 Examples
6 Relationship Strength
7 Implementation Guidelines
8 Inter-unit Domain Relationships JSON Schema
9 Schema Reference

Introduction

Inter-unit domain relationships in the Orthogramic Metamodel provide a comprehensive framework for articulating how organizational units interact with and depend upon various domain entities—such as capabilities, information assets, services, value streams, initiatives, and products. This version includes additional relationship types to capture the full spectrum of organizational interdependencies.

The framework enables organizations to:

Clarify complex collaborative arrangements across units for specific domain entities
Model multi-party governance structures and approval workflows
Identify specialist advisory relationships and subject matter expertise dependencies
Track monitoring and oversight responsibilities separate from operational governance
Support escalation paths and exception handling processes
Facilitate coordination mechanisms for complex multi-unit initiatives

Each inter-unit domain relationship specifies:

The type of domain entity involved (e.g., Capability, Service)
The organizational unit participating in the relationship
The nature of the relationship using role definitions
The strength of the relationship, rated on a scale from 1 (very weak) to 5 (very strong)
Optional rationales explaining the relationship's strategic or operational justification

Role types for inter-unit domain relationships

Core operational relationships

Role Type	Definition	Usage Guidelines

Role Type	Definition	Usage Guidelines
`owning`	The unit accountable for the governance, lifecycle, and quality of the domain entity	There should be only one owning unit per entity. Ownership includes strategic alignment, funding decisions, and compliance responsibility
`providing`	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`	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
`contributing`	The unit that provides partial input, expertise, or resources to the domain entity without being the primary provider	Use for capabilities or services requiring collaborative delivery from multiple units. Distinguishes partial contribution from full provision

Stewardship and dependency relationships

Role Type	Definition	Usage Guidelines

Role Type	Definition	Usage Guidelines
`benefiting`	A 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
`custodian`	The unit responsible for maintaining integrity, accuracy, and compliance of an information or data entity	Commonly applied to information, records, and policies. Ensures content remains authoritative, secure, and consistent with standards
`dependent`	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
`supporting`	The unit that gives operational advantage or risk reduction to another unit's domain activity	Typically used where benefit is derived passively (e.g., safety improvement from policy implementation)

Governance and oversight relationships

Role Type	Definition	Usage Guidelines

Role Type	Definition	Usage Guidelines
`governing`	The unit responsible for setting rules, standards, or oversight mechanisms for the domain entity	Typically applies to policies, regulatory frameworks, or enterprise architecture standards. May audit, direct, or override other roles
`monitoring`	The unit that tracks performance, usage, or compliance of the domain entity without direct operational involvement	Use for oversight functions separate from governance. Focuses on measurement and reporting rather than rule-setting
`reviewing`	The unit responsible for validation, approval, or sign-off on domain entity outputs or changes	Common in regulated environments or where quality gates are required. Implies formal review authority

Coordination and advisory relationships

Role Type	Definition	Usage Guidelines

Role Type	Definition	Usage Guidelines
`coordinating`	The unit that facilitates collaboration between multiple units involved with the domain entity	Use for complex capabilities requiring orchestration across units. Does not imply operational responsibility for the entity itself
`consulting`	The unit that provides advisory input or specialist knowledge without operational responsibility	For subject matter expertise relationships. Input is advisory rather than directive
`escalatingTo`	The unit that receives escalated issues, exceptions, or decisions related to the domain entity	For hierarchical decision-making structures. Implies authority to resolve exceptions or make final decisions

Domain-specific relationship extensions

Value stream domain extensions

Role Type	Definition	Usage Guidelines

Role Type	Definition	Usage Guidelines
`participating`	The unit that contributes to specific steps or stages within the value stream	Use to model units involved in value stream execution without being the primary owner
`triggering`	The unit that initiates or activates value stream execution	Identifies units responsible for starting value stream processes

Initiative domain extensions

Role Type	Definition	Usage Guidelines

Role Type	Definition	Usage Guidelines
`sponsoring`	The unit providing funding, executive support, or strategic backing for the initiative	Distinguishes financial/executive support from operational ownership
`impactedBy`	The unit whose operations, processes, or outcomes are affected by initiative results	Use to track initiative impact scope and stakeholder management requirements

Defining relationships

inter-unit domain relationships describe the full spectrum of how specific business domains are supported, governed, consumed, coordinated, and otherwise utilized by different organizational units within the enterprise.

Valid domain types

The following domain types may be used as the focal point for inter-unit relationships:

Domain	Typical Relationship Usage	Notes

Domain	Typical Relationship Usage	Notes
Capability	owning, providing, consuming, contributing, supporting, governing, monitoring, consulting	Most commonly used; supports complex collaborative capabilities
Information	owning, custodian, consuming, reviewing, monitoring, governing	stewardship and compliance modeling
Service	providing, consuming, supporting, monitoring, escalatingTo	Comprehensive service relationship modeling
Value Stream	owning, participating, triggering, coordinating, monitoring	collaborative delivery modeling
Initiative	owning, sponsoring, contributing, impactedBy, governing	Comprehensive initiative stakeholder relationships
Product	owning, providing, consuming, supporting, reviewing	product lifecycle relationships

Recommendations

Start with Capability domain as the primary entry point for defining inter-unit relationships
Layer additional relationships to capture the full organizational complexity
Use contributing vs. providing to distinguish partial vs. full responsibility
Separate monitoring from governing to clarify oversight vs. rule-setting
Apply consulting relationships for subject matter expertise dependencies
Model escalation paths using "escalatingTo" relationships
Avoid relationship proliferation - only model relationships that provide analytical value

Examples

Capability Domain Example

The Risk Management capability demonstrates complex multi-unit relationships:

Owned by: Risk Division (strategic accountability)
Provided by: Risk Operations Team (day-to-day delivery)
Contributing: Legal, Finance, IT Security (specialist input)
Consuming: All business units (risk assessment services)
Governing: Risk Committee (policy setting)
Monitoring: Internal Audit (performance tracking)
Consulting: External Risk Advisors (specialist guidance)
Escalating to: Executive Committee (exception decisions)

Service Domain Example

The Data Analytics Platform service shows comprehensive service relationships:

Owned by: Data Office (strategic ownership)
Provided by: IT Operations (technical delivery)
Consuming: Marketing, Sales, Finance (analytics users)
Supporting: Data Engineering (data pipeline support)
Governing: Data Governance Board (usage policies)
Monitoring: Service Management (performance tracking)
Reviewing: Information Security (access approvals)
Escalating to: CTO Office (technical escalations)

Value Stream Example

The Customer Onboarding value stream demonstrates collaborative delivery:

Owned by: Customer Experience Division (end-to-end accountability)
Participating: Sales, Legal, IT, Operations (process steps)
Triggering: Sales (onboarding initiation)
Coordinating: Process Management Office (workflow orchestration)
Monitoring: Quality Assurance (process performance)
Supporting: Training Team (capability development)

Initiative Example

The Digital Transformation Initiative shows complex stakeholder relationships:

Owned by: Digital Transformation Office (delivery accountability)
Sponsoring: Executive Committee (funding and strategic support)
Contributing: IT, HR, Operations (capability delivery)
Impacted by: All business units (process changes)
Governing: Transformation Steering Committee (direction setting)
Consulting: External Digital Advisors (specialist guidance)
Monitoring: PMO (progress tracking)

Relationship Strength

The relationship strength scale remains unchanged but applies to all relationship types:

Value	Value title	Description

Value	Value title	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

Guidance: Consider relationship strength in the context of the specific role type. For example, a consulting relationship with strength 5 indicates mission-critical advisory input, while a monitoring relationship with strength 2 indicates routine oversight.

Implementation Guidelines

Phased Implementation Approach

Phase 1: Implement core operational relationships (Owning, Providing, Consuming)
Phase 2: Add governance relationships (Governing, Monitoring, Reviewing)
Phase 3: Introduce collaborative relationships (Contributing, Coordinating, Consulting)
Phase 4: Complete with specialized relationships (Escalating to, domain-specific types)

Relationship Selection Criteria

Analytical Value: Only model relationships that support specific analytical or governance needs
Operational Reality: Ensure relationships reflect actual organizational behavior
Maintenance Burden: Consider the effort required to keep relationship models current
Stakeholder Understanding: Use relationships that stakeholders can easily comprehend and validate

Quality Assurance

Avoid Redundancy: Ensure new relationship types don't duplicate existing coverage
Maintain Clarity: Keep role definitions distinct and non-overlapping
Validate Completeness: Test relationship models against real organizational scenarios
Regular Review: Periodically assess whether all relationship types remain relevant

Inter-unit Domain Relationships JSON Schema

Schema Properties

Field	Description	Example

Field	Description	Example
`entityName`	The name or title of the domain entity involved in the relationship	"Risk Management Capability"
`domainType`	The domain type to which the entity belongs	"Capability"
`relationshipRole`	The nature of the organization unit's role (using role types)	"Contributing"
`organizationUnit`	The name of the organization unit holding the relationship role	"Legal Division"
`relationshipDescription`	A description of how the unit is involved with the domain entity	"Provides regulatory compliance expertise for risk assessments"
`relationshipStrength`	Numeric value (1-5) indicating relationship intensity	4
`relationshipRationale`	Optional explanation for why this relationship exists	"Legal expertise required for regulatory risk assessment compliance"

JSON Example

{
  "interUnitDomainRelationships": [
    {
      "domainType": "Capability",
      "entityName": "Risk Management Capability",
      "relationshipRole": "Contributing",
      "organizationUnit": "Legal Division",
      "relationshipDescription": "Provides regulatory compliance expertise for risk assessments",
      "relationshipStrength": 4,
      "relationshipRationale": "Legal expertise required for regulatory risk assessment compliance"
    },
    {
      "domainType": "Value Stream",
      "entityName": "Customer Onboarding Value Stream",
      "relationshipRole": "Coordinating",
      "organizationUnit": "Process Management Office",
      "relationshipDescription": "Orchestrates workflow between participating units",
      "relationshipStrength": 5,
      "relationshipRationale": "Critical coordination required for seamless customer experience"
    }
  ]
}

Schema Reference

Schema file available on GitHub: https://github.com/Orthogramic/Orthogramic_Metamodel/blob/main/schemas/inter-unit-domain-relationships.schema.json