R&D Management 13 min read

Business Capability vs. Business Process: TOGAF 10 Clarifies the Relationship

This article distinguishes business capabilities (what an enterprise can do) from business processes (how work gets done) using TOGAF 10's metamodel, showing capabilities as stable abstractions while processes operationalize them in variable workflows.

Architecture Practice Methods
Architecture Practice Methods
Architecture Practice Methods
Business Capability vs. Business Process: TOGAF 10 Clarifies the Relationship

The article opens with a common confusion in business architecture: practitioners often mix business capabilities, business processes, organizational responsibilities, and system functions. The core distinction is summarized in one sentence: business capability answers "what the enterprise can do," while business process answers "how the enterprise gets things done."

1. In the TOGAF 10 Metamodel, Capability and Process Are Separate Entities

TOGAF 10's architecture content framework defines a metamodel where Business Capability and Process are two independent entity types.

TOGAF defines Business Capability as:

Business Capability is a particular ability that an organization may possess or exchange to achieve a specific purpose.

TOGAF defines Process as:

Process is a sequence of activities that together achieve a specific result; it can be decomposed into sub‑processes or show how a business capability or service operates at the next level of detail.

Together these definitions make clear: capability emphasizes what abilities the enterprise possesses ; process emphasizes how a set of activities is organized to deliver a result .

Example comparison:

Business Capability : Contract Management — Enterprise needs abilities for drafting, reviewing, signing, executing, amending, archiving contracts

Business Process : Contract Approval Process — Describes the concrete flow from initiation, review, countersign, approval to archiving

Thus "Contract Management" fits as a capability; "Contract Approval" fits as a process. Putting "Contract Approval" as a top‑level capability turns the capability map into a process checklist.

2. Capability Focuses on What, Not How

The TOGAF Series Guide: Business Architecture states that a capability can be understood as "the ability to do something." Crucially, it stresses that business capability describes what the enterprise does, without explaining how, why, or where it is done.

A detailed comparison from the guide:

Core Question : Business Capability Architecture — "What can the enterprise do?"; Business Process Architecture — "How does the enterprise get things done?"

Keyword : Capability — What; Process — How

Expression Focus : Capability — Capability boundaries, decomposition, maturity; Process — Activity sequence, role collaboration, inputs/outputs, control rules

Typical Form : Capability — Capability map, decomposition, heat map; Process — End‑to‑end process diagram, decomposition, activity model

Stability : Capability — Relatively stable; Process — Relatively volatile

Primary Use : Capability — Capability inventory, planning, investment prioritization; Process — Process optimization, responsibility clarification, system requirements analysis

Naming heuristic: capabilities use nouns or noun phrases (e.g., Project Management, Strategic Planning); verb‑style names usually indicate processes because they describe "how."

Practical examples:

More Like a Capability: Customer Management, Contract Management, Order Fulfillment, Supplier Management, Invoice Management

More Like a Process/Activity: Add Customer, Contract Approval, Create Order, Supplier Qualification Review, Issue Invoice

Capability names may contain "management," "operations," "service," but they denote a stable business ability, not a single execution step.

3. They Are Not Isolated — Capability Is Operationalized by Process

The TOGAF 10 metamodel explicitly relates the two:

Business Capability — Process: Is operationalized by — the capability is realized through processes.

Process — Business Capability: Operationalizes — the process operationalizes the capability.

In plain language: capability defines boundaries; process organizes execution.

Example: "Customer Management Capability" appears as a single capability unit on a map. In reality it materializes as multiple processes — customer onboarding, tiering, service, complaint handling, renewal.

Another example: "Contract Management Capability" manifests as drafting, approval, signing, amendment, archiving processes.

The relationship is many‑to‑many:

One capability → multiple processes : Customer management capability appears in acquisition, service, complaint, renewal processes

One process → multiple capabilities : Lead‑to‑cash process involves customer, opportunity, quoting, contract, fulfillment, invoicing capabilities

Capability relatively stable : Enterprise long‑term needs customer, contract, fulfillment capabilities

Process relatively volatile : Processes change with org structure, rules, systems, approval authorities

Core logic: Process is not a synonym for capability; it is the way capability runs. Capability is not a collection of processes; it is a stable abstraction of business ability.

4. Why Neither Capability‑Only Nor Process‑Only Works

Two common biases in practice:

Only capability maps — looks complete but cannot answer which capabilities are invoked in which scenarios, where handoffs break, which departments collaborate poorly, or which systems lack support.

Only process diagrams — shows every step, approver, executor, archiver, but risks local optimization without seeing reusable capabilities, duplicate construction, or capabilities that should be governed centrally.

Recommended approach: first use business capability architecture to clarify what capabilities the enterprise needs, then use business process architecture to show how those capabilities are invoked, combined, and executed in concrete scenarios. This aligns with the TOGAF Business Capability Guide: the capability model provides a stable business view to manage complexity; roles, processes, information, and resources behind capabilities supply the business context for those supporting elements.

5. Final Conclusion

Returning to the opening question: Is there a logical relationship between business capability architecture and business process architecture?

Answer: Yes, and it is explicit.

From the TOGAF 10 metamodel: they are two distinct business architecture objects.

From TOGAF's capability definition: capability stresses "what," not "how."

From the metamodel relationship: capability is operationalized by process; process operationalizes capability.

One‑sentence summary: Business capability architecture defines what the enterprise can do; business process architecture explains how the enterprise gets things done. Capability provides boundaries for processes; processes make capabilities run in specific scenarios.

Reference: TOGAF Series Guide: Business Capability .

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Process ModelingBusiness ArchitectureEnterprise ArchitectureTOGAFbusiness processBusiness CapabilityCapability Modeling
Architecture Practice Methods
Written by

Architecture Practice Methods

Frontline architect. Sharing knowledge and insights in enterprise architecture.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.