Designing, Building, and Maintaining Comprehensive and Usable Enterprise Capability Models

Best Practice: Never Use Hierarchical Position Identifiers as Durable Capability IDs

Description

Hierarchical position identifiers such as 1.0, 1.1, 1.1.1, or similar numbering schemes should not be used as durable capability IDs. They are useful for display, sorting, navigation, discussion, and printed or published views, but they reflect a capability’s current position in the hierarchy rather than its durable identity.

Figure: Hierarchy position identifiers are useful for display, navigation, and sorting, but they can change when capabilities are inserted, moved, split, merged, or reorganized. Semantic IDs provide durable capability identity, allowing applications, documents, risks, controls, dashboards, knowledge pages, and other Enterprise Model relationships to remain stable even when the hierarchy changes.

Position identifiers change when a capability is inserted, deleted, moved, split, merged, or reorganized. A capability may retain its meaning even when its position changes. Therefore, position and identity must be separated. It is for this reason that it is recommended a modeler always use Semantic IDs that describe the capability with some context.

A common means of generating a semantic identifier is to use the full path down to the capability name. For example…

• “/Enterprise/IT Capabilities/Service Management/Service Request Intake”

• “/Enterprise/IT Capabilities/Application Management/Application Operations/Incident Management/Incident Investigation”

• /Enterprise/Core Business Capabilities/Customer Acquisition/Lead Capture and Qualification”

While these identifiers seem unreasonably long, consider that limitations on length and legality of characters come from legacy tools and technologies that have always had significant limitations. AI does not have such limitations and works off Natural Language. Long semantic identifiers with semantic context are far more meaningful and useful when using AI to model and develop things from your model(s). If required, system-friendly GUIDs can also be created, used, and maintained in addition to semantic identifiers — specifically for compliance with technologies that can’t handle such semantic IDs.

Benefit(s)

Using hierarchy position as durable identity creates fragile references. If applications, risks, controls, initiatives, value chain stages, knowledge pages, or dashboards reference a position number, those references can become wrong when the hierarchy changes.

Avoiding this practice protects referential integrity and makes the model safer to evolve over time.

Best Practice: Use Semantic IDs for Durable Identity

Description

Each capability should have a stable Semantic ID that identifies the capability as a durable enterprise concept. A Semantic ID should be human-readable, AI-friendly, unique within the Enterprise Capability Model (ECM), and stable enough to support long-term references.

Semantic IDs may be seeded from the capability path or meaningful name, but they should not be treated as temporary positional labels. Once assigned and approved, a Semantic ID should remain associated with the same capability meaning unless the capability is materially redefined.

Benefit(s)

Semantic IDs preserve referential integrity across the Enterprise Model. Applications, value chain stages, processes, data, risks, controls, initiatives, generated pages, dashboards, and AI-assisted queries can reference the same durable capability even when its display name or hierarchy position changes.

This also improves machine readability. AI agents and automation tools can reason over stable identifiers more reliably than over ambiguous names or shifting hierarchy numbers.

Best Practice: Preserve Semantic Identity Through Reorganization

Description

When the hierarchy is reorganized, the enterprise should preserve a capability’s Semantic ID when the capability’s meaning remains substantially the same. Moving a capability to a different parent, renaming it for clarity, or changing its hierarchy position should not automatically create a new identity.

New Semantic IDs should be created when a capability is materially split, merged, narrowed, broadened, or redefined in a way that changes its governed meaning. In those cases, the model should preserve history through status, change notes, predecessor-successor references, and governance records.

Benefit(s)

Preserving Semantic ID continuity protects historical analysis, relationship integrity, generated knowledge pages, and stakeholder trust. It allows the model to evolve without invalidating every downstream reference.

This practice also supports auditability. Reviewers can understand what changed, why it changed, and whether the capability identity remained stable or was intentionally replaced.