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

Best Practice: Design the Hierarchy Around Stable Enterprise Abilities

Description

The capability hierarchy should be organized around stable enterprise abilities rather than current organizational units, applications, projects, processes, or technologies. A capability should describe what the enterprise must be able to do, not who currently does it, which system supports it, or which project is changing it.

Modelers should test every proposed capability name against this principle. If the proposed node sounds like a department, a workflow step, an application module, a technology product, a role, or an initiative, it may not be a capability. It may still be important, but it should usually be modeled as a related Noun Type rather than as a capability.

Benefit(s)

Designing around stable enterprise abilities makes the model durable. The model remains useful when organizations reorganize, applications are replaced, processes are redesigned, vendors change, or technology platforms are modernized.

This also improves Enterprise Model integrity. Stable capabilities can act as long-lived anchors for relationships to applications, value chain stages, processes, data, risks, controls, regulatory obligations, investments, and initiatives.

Best Practice: Use Practical Hierarchy Depth Guidelines

Description

Most useful Enterprise Capability Models (ECMs) are at least three levels deep (beyond the categorization level of (Industry-specific, Core, or IT) and typically no more than five levels deep (beyond the same categorization level). Three levels usually provide enough structure for broad planning, executive navigation, and high-level ownership. Four to five levels often provide enough specificity for assessment, application mapping, EDMS classification, knowledge-page publishing, and capability improvement planning.

Figure: An Enterprise Capability Model can be represented as a taxonomy tree that decomposes broad enterprise capability domains into progressively more specific branch and leaf capabilities. Most models use at least three levels (beyond the 1.0, 2.0, and 3.0 categorization nodes) and typically no more than five levels, while allowing additional customization where enterprise-specific complexity, regulation, or analytical needs justify deeper decomposition.

This guidance is a practical design guardrail, not a rigid rule. The enterprise may customize model depth based on industry complexity, regulatory exposure, operational specificity, maturity, and analytical needs. Some branches may stop at Level 3, while others may extend to Level 5 when the additional detail creates measurable value.

Important Note: Hierarchy identifiers (e.g., 1.1, 1.1.1, 1.2.2.3, etc.) should never be used as identifiers for the capability. As a capability model improves and matures, there may be cases where you might move things around in the model, add new capabilities, or delete existing capabilities. This will automatically change hierarchical identifiers. If other people, documentation, and systems point to these hierarchical identifiers, it will become a challenge to go change all those dependencies.

Benefit(s)

Practical depth guidance helps modelers avoid both under-modeling and over-modeling. Models that are too shallow cannot support meaningful assessment, ownership, knowledge publishing, or application mapping. Models that are too deep become difficult to govern, explain, validate, and maintain.

The purpose of levels is to support decision-making, navigation, assessment, and knowledge sharing. Depth should be justified by practical use cases such as ownership, maturity scoring, application support analysis, risk exposure, EDMS classification, or capability-based planning.

The following table provides practical guidance for how levels are often used. The example is illustrative; enterprises should adapt labels, depth, and decomposition patterns to fit their own needs.

Best Practice: Extend Deeper Only When There Is Analytical Value

Description

Deeper decomposition should be used only when it creates clear analytical, operational, regulatory, governance, or planning value. Most ECMs should resist going beyond five levels unless the additional depth supports distinct ownership, assessment, control, document classification, application mapping, or operational decision-making.

Before extending the hierarchy, modelers should ask what decision the additional level will support. If the lower-level node will not have distinct ownership, assessment, application support, risk, investment, performance, or governance implications, the extra decomposition may not be worth maintaining.

Benefit(s)

This practice prevents over-modeling. It keeps the model usable, easier to review, easier to publish, and easier to govern.

It also allows the enterprise to invest modeling effort where it matters most. Complex or high-risk capability areas can be decomposed more deeply, while stable or lower-priority areas can remain at a practical level of abstraction.

Best Practice: Use Clear Parent-Child Rules

Description

Every capability except the root should have exactly one parent capability in the primary hierarchy. A capability may have zero, one, or many child capabilities. This creates a clear tree structure that supports navigation, rollups, analysis, publishing, and governance.

This does not mean that a capability can only relate to one other concept. A capability can have many relationships outside the hierarchy. It can enable multiple value chain stages, be supported by multiple applications, be performed by multiple organizations, and be affected by multiple risks. The one-parent rule applies to the primary hierarchy, not to the broader Enterprise Model graph.

Benefit(s)

Clear parent-child rules preserve hierarchy integrity. Users can reliably determine a capability’s parent, children, siblings, ancestors, descendants, level, and full path.

This also improves generated pages, dashboards, heatmaps, and AI-assisted traversal. Systems and AI agents can navigate the hierarchy predictably while still using graph relationships for richer analysis.