Capability Mapping

"Business capability" is one of the most abused terms in enterprise architecture because it is easy to confuse with the things that sit next to it in an org chart: **processes**, **functions**, and **departments**. Getting the distinction right is the entire point of capability mapping, so it is worth being precise about the mechanism. ## What a capability is A capability answers the question "what is the organization able to do?" - stated as a **noun phrase**, not a verb phrase: "Customer Relationship Management," "Inventory Management," "Regulatory Reporting." It is defined by three properties: 1. it names an **ability to produce a business outcome**; 2. it is **stable over multi-year horizons**; 3. it is deliberately **silent on how** the ability is exercised, who exercises it, or what system supports it. A capability model is typically expressed as a hierarchy (L1 domains like "Customer Management," decomposed into L2 capabilities like "Customer Onboarding," further into L3 like "KYC Verification") built once, then revised only when the fundamental business model changes - not when a reorg happens or a new CRM is purchased. ## What a process is A process, by contrast, answers "how do we do it, in what order, involving which roles and systems?" It is a **verb-oriented sequence**: "receive order, validate credit, allocate inventory, ship, invoice." Processes are the concrete choreography that realizes one or more capabilities at a point in time, and they are expected to change - through automation, outsourcing, system migration, or regulatory change - far more often than the capability they realize. The same capability, "Payment Processing," might be executed by a manual process in one region and a fully automated one in another; the capability description does not change, only the process does. ## What a function or department is A function or department is an **organizational construct** - "Finance," "Marketing," "Operations" - a grouping of people and budget under management accountability. Capabilities deliberately cut across functions: "Customer Onboarding" typically spans Sales, Legal/Compliance, and IT, and no single department owns it end to end. This is precisely why capability maps are useful for EA: they give you a decomposition of the business that is orthogonal to the org chart, so you can talk about what needs investment without first resolving whose budget pays for it. | Capability | Process | Function or department | |---|---|---| | "what is the organization able to do?" | "how do we do it, in what order, involving which roles and systems?" | a grouping of people and budget under management accountability | | a noun phrase, stable over multi-year horizons, silent on how | a verb-oriented sequence, expected to change | an organizational construct on the org chart | ## Why the separation is a discipline Why does this separation exist as a discipline rather than just being pedantry? Because each of the three views answers a different governance question, and conflating them breaks all three. - **Plan IT investment against processes** and your roadmap becomes obsolete every time a process is redesigned or a BPO contract changes hands, even though the underlying business ability did not change - you are rebuilding your investment case on a moving target. - **Plan investment against departments** and you get siloed funding decisions that duplicate capability delivery, because no one has an org-independent view of what already exists. Capabilities give you a map stable enough to accumulate multi-year investment history against, and abstract enough to reveal duplication and gaps that process or org views hide. ## The trade-off The trade-off is that capabilities are more abstract and therefore harder to validate and easier to get wrong. A capability model built by a small architecture team in a workshop, without validation against how the business actually operates, tends to drift into either: - a **restatement of the org chart** with capability-sounding names, or - a **restatement of the process flows** one level up. Both failure modes destroy the value of the exercise: if capability just means department, you have bought nothing over the existing org chart; if it just means coarse-grained process, it will need updating every time a process changes, defeating the stability that justified building it in the first place. ## A concrete example A concrete example: a retail bank's capability map lists "Loan Origination" as an L2 capability under "Lending." Over five years the bank might replace its loan-origination system three times, outsource underwriting to a third party, and redesign the origination process twice to comply with new lending regulation - the process diagrams and the application landscape churn constantly. But "Loan Origination" as a capability - the ability to take a loan application and decide whether and on what terms to extend credit - remains a single, unchanged line in the capability map throughout, and every one of those process and system changes gets tracked as investment against this capability rather than as unrelated, disconnected projects. That continuity is what lets a CIO answer how much has been spent on lending capability over five years, and whether it is still underinvested relative to its strategic importance - a question a process inventory or an org chart cannot answer on its own.