The Principles That Make a Business Capability Model Hold Up

Key Takeaways

• A capability that changes name every time the org chart changes was never really a capability; stability against structural change is the property that makes it worth mapping in the first place.
• Capability definitions belong to business subject matter experts, not to IT or enterprise architecture; a definition that references a specific system or department has already broken the technology-agnostic principle.
• Capability, process, and function describe three different things: what the business does, how it does it, and who currently does it. Confusing any two of these is the most common defect in a first-draft model.
• Overlap between capabilities, two entries that describe the same underlying ability, is a more common defect than missing capabilities, and it's usually the reason investment decisions made against the model don't add up.
• Every capability needs exactly one accountable owner, distinct from any application owner or business unit head, or disagreements about its scope and performance have nowhere to land.

Principle One: Capabilities Are Stable, Not Structural

A capability should describe something that stays true even after a reorganization or a system migration.

Order Management stays Order Management whether it's delivered by a single centralized team or split across three regional ones, whether it runs on one ERP system or three. What changes when the org chart or the technology changes is how the capability is delivered, not whether the organization still needs to be able to do it. If a capability's name or definition has to be rewritten every time there's a reorganization, it was describing a department, not a capability, and it should be renamed accordingly. This stability is also what makes a capability model worth the effort to build. A map of departments goes out of date the next time the org chart changes. A map of capabilities, done correctly, still describes the business accurately years later, even though almost everything about how those capabilities are delivered has changed underneath it.

Principle Two: Capabilities Are Business-Owned and Technology-Agnostic

A capability's name and definition shouldn't reference a specific system, tool, or department.

A capability called CRM Management is a warning sign; it's naming the system, not the ability. The underlying capability is closer to Customer Relationship Management or Customer Engagement, something the business would still need even if it replaced the CRM platform entirely tomorrow. The same test applies to department names: a capability called Marketing Department Activities is describing an org chart entry, not a capability. This principle is also about who writes the definition. When IT or enterprise architecture drafts capability definitions without business subject matter experts in the room, the definitions tend to drift toward what the systems do rather than what the business needs, and the business stops recognizing the model as describing its own work.

Principle Three: Capability, Process, and Function Are Different Things

These three get confused more than any other pair of concepts in business architecture, and the confusion shows up in how things get named.

A capability describes what the business needs to be able to do, and it's typically named as a noun phrase: Order Management, Customer Onboarding. A process describes how that capability gets executed, a sequence of activities with a start and an end, and it's typically named with a verb and an object: Process Customer Order, Onboard New Customer. A function is an organizational grouping, a department or team that exists in the org chart today and may deliver all, part, or none of a given capability. The practical test: if you can point to where it sits on an org chart, it's a function. If you can describe it as a sequence of steps with a clear start and finish, it's a process. If it survives both the org chart and the process changing and still describes something true about the business, it's a capability.

Principle Four: Capabilities Should Be Discrete, Not Overlapping

Two capabilities that describe the same underlying ability are a more common defect than a missing capability.

Overlap usually shows up when a model has both Customer Service and Customer Support as separate entries, or Risk Management and Compliance Management defined broadly enough that half their scope is identical. Neither error is obvious from the name alone; it takes someone testing each capability's definition against the others to catch it, which is exactly why this principle gets skipped under deadline pressure. The right level of abstraction matters here too. Too broad, and a capability like Operations stops meaning anything specific enough to inform an investment decision. Too granular, and the model turns into a task list, with dozens of near-duplicate entries that differ only in a detail that belongs at the process level, not the capability level.

Principle Five: Every Capability Needs a Single Accountable Owner

Shared use of a capability is normal. Shared ownership usually means no one is actually accountable.

The owner should be a named business role, not a department, and not the person who happens to own the application currently used to deliver the capability. An application owner is accountable for a system; a capability owner is accountable for whether the business's ability to do the thing is actually adequate, regardless of what system delivers it. Without a named owner, a capability's definition and scope drift the first time two departments disagree about it, because there's no one whose job it is to settle the disagreement. Assigning ownership is the cheapest of the five principles to apply and the one most often skipped, usually because nobody wants to be the tiebreaker.

Applying These Principles When Reviewing an Existing Model

These principles work as a review checklist just as well as a design checklist.

Walking an existing model against them one capability at a time usually surfaces the same handful of problems: entries that are really processes or org chart names, definitions written by IT without business input, overlapping pairs that should be merged, and capabilities with no named owner. None of these fixes require rebuilding the model from scratch; they require a working session with the right people and the discipline to actually rename or merge entries rather than leaving them as a compromise.

Frequently Asked Questions

Q: What's the difference between a business capability and a business process? A: A capability describes what the business needs to be able to do, independent of sequence or timing. A process describes how that capability gets carried out, as an ordered set of activities with a defined start and end. The same capability can be delivered by more than one process, and a process can change completely while the capability underneath it stays the same. Q: Why does capability ownership matter so much? A: Without a single accountable owner, there's no one positioned to resolve disagreements about a capability's scope, definition, or performance. Ownership is what turns a capability from a label on a diagram into something someone is actually answerable for. Q: How do you know if a capability model has too much overlap? A: If two entries can each absorb most of the other's definition without losing meaning, they overlap. A practical test is asking whether an initiative or investment could plausibly be charged to either one; if reviewers routinely disagree about which capability an initiative touches, that's a sign of overlap. Q: Should capability names reference specific systems or software? A: No. A capability name that references a system, like CRM Management, is naming the tool rather than the ability. The capability should be named for what the business needs regardless of which system currently delivers it. Q: Who should define a business capability, IT or the business? A: The business should define it, working with enterprise architecture. When IT drafts the definitions alone, they tend to drift toward describing what current systems do rather than what the business actually needs, which undermines the entire point of a technology-agnostic model.

Pro Tips

• When you're unsure whether something is a capability or a process, ask whether it has a start and an end. A process does; a capability doesn't, it's always ongoing.
• Run a quick overlap test on any new capability before adding it: try to state its definition without using any word from an existing capability's definition. If you can't, they probably overlap.
• Assign an owner the same day a capability is added to the model, not after the fact. An unowned capability tends to stay unowned until a dispute forces the question, which is the worst time to be deciding it.