Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 6 Next »

Introduction

In the Orthogramic, cross domain relationships are directional, typically flowing 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.

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.

Passive domains

Passive and Active domain concepts

  • 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.

Directionality of cross domain relationships

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.

Inter-domain 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.

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).

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."

Active/Passive domain roles are less rigid here

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.

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.

  • No labels