Capability Model vs. Operating Model: The Enterprise Architect's Dilemma
Two essential artifacts for enterprise transformation — and a surprisingly common source of confusion about which to build first, which to use when, and how they relate to each other.
Enterprise architects are frequently asked to choose between building a capability model and designing a target operating model — as if these were competing approaches to the same problem. They are not. A capability model and a target operating model answer fundamentally different questions, operate at different levels of abstraction, and are most powerful when used together. This guide explains the relationship, the differences, and the practical decision framework for knowing when to use each.
Business Capability Model
A stable, hierarchical representation of what the organization needs to be able to do — independent of organizational structure, processes, or technology.
Best for
- Establishing a stable strategic vocabulary
- IT portfolio rationalization
- Investment prioritization
- M&A capability overlap analysis
- Vendor and technology evaluation
- Architecture governance
Target Operating Model
A blueprint describing how the organization will organize its people, processes, technology, data, and governance to execute its strategy in a desired future state.
Best for
- Transformation program design
- Organizational redesign
- Technology architecture decisions
- Governance model design
- Change management planning
- Executive alignment on future state
Business Capability Model vs. Target Operating Model: Side-by-Side
| Dimension | Business Capability Model | Target Operating Model | Insight |
|---|---|---|---|
| Primary question answered | 'What does the organization need to be able to do?' | 'How will the organization be organized to do it?' | The capability model defines the 'what'; the TOM defines the 'how' |
| Scope | Capabilities only — independent of structure, process, and technology | People, process, technology, data, governance — the full operating design | The TOM is broader; the capability model is a key input to it |
| Time horizon | Stable across multiple years — capabilities change slowly | Describes a specific future state — typically 2–5 years out | The capability model is more stable; the TOM is more time-bound |
| Relationship to strategy | Translates strategy into capability requirements | Translates strategy into organizational design choices | Both are strategy-execution tools — at different levels of detail |
| Primary audience | Enterprise architects, IT leaders, strategy teams | C-suite, transformation leaders, HR, operations | The TOM reaches a broader executive audience |
| Typical output format | Hierarchical capability map (visual diagram) | Multi-page design document with diagrams, decision matrices, and roadmaps | The capability map is more concise; the TOM is more comprehensive |
| Change frequency | Updated annually or when strategy changes significantly | Updated as transformation milestones are achieved or strategy shifts | Both require regular maintenance — neither is a one-time deliverable |
When to Use Each
- You are starting a new transformation program and need to establish a common language
- Start with the capability model. The capability model provides the stable vocabulary that all subsequent design work — including the TOM — will use. Building the TOM before the capability model is established leads to design decisions that are not grounded in a shared understanding of what the organization needs to do.
- You need to communicate the transformation vision to the board and C-suite
- Use the target operating model. The TOM is the executive communication artifact — it shows the full picture of how the organization will change. The capability model is too abstract for board-level communication; the TOM provides the concrete design choices that executives can evaluate and approve.
- You are evaluating a technology platform and need to assess fit
- Use the capability model. Technology evaluation should be grounded in capability requirements — which capabilities does the platform need to support, and how well does it support them? The TOM provides context, but the capability model provides the specific evaluation criteria.
- You are designing the organizational structure for a new business unit
- Use the target operating model. Organizational design is a TOM-level decision — it involves choices about structure, roles, governance, and accountabilities that go beyond the capability model. The capability model informs the design (by defining what capabilities the unit needs), but the TOM is the design artifact.
The Common Mistake
The most common mistake enterprise architects make is building a capability model and a target operating model as separate, disconnected artifacts — developed by different teams, using different vocabularies, and serving different audiences. The result is two artifacts that cannot be reconciled, and a transformation program that lacks coherence. The most effective approach is to build the capability model first, use it as the foundation for the TOM, and maintain explicit traceability between the two — ensuring that every design decision in the TOM can be traced back to a specific capability requirement.
Bottom Line
Build the capability model first — it provides the stable foundation and shared vocabulary for all subsequent design work. Build the target operating model second — it translates the capability requirements into concrete organizational design choices. Maintain explicit traceability between the two throughout the transformation program.