What is the difference between a business capability and a business process, and why does it matter when drawing service boundaries?

What is being tested

Whether you know which business abstraction is stable enough to build boundaries on.

The distinction

A capability is an ability: "accept payment", "fulfil an order", "assess credit risk". Verb plus noun, no technology, no team, no sequence.

A process is a sequence of activities producing an outcome: order-to-cash, quote-to-policy. It crosses several capabilities and changes whenever the business redesigns how it works.

Why capabilities make better boundaries

They are the most stable thing in an organisation. Processes get redesigned, teams reorganise, systems get replaced — but a retailer has been "managing inventory" for a century and will continue to.

A service organised around "accept payment" survives the reorganisation, the vendor change and the process redesign. A service organised around the current process is invalidated by the next process improvement, and one organised around the current org chart is invalidated by the next reorganisation — which is why "which capability does this belong to?" is a better design-review question than "which team owns this?"

Why processes still matter to an architect

Capabilities tell you where to draw boundaries. Processes tell you what crosses them, and the crossings are where the architecture is actually decided:

• Handoffs — every transfer between teams or systems accumulates latency, error and lost context. The number of handoffs predicts cycle time better than the work does.
• Manual steps — someone rekeying data between systems is an integration requirement in disguise, invisible on any system diagram.
• Wait states — usually where the elapsed time actually goes.
• Exception paths — the 15% of cases off the happy path frequently consume 80% of the effort, and architectures designed only for the happy path fail exactly here.

The test for a good capability statement

Verb plus noun; no technology; consistent level; non-overlapping. If a system name appears in the box, it is not a capability — it is an application inventory with different labels, which is the most common form the artefact takes.

What a strong answer adds

That the same reasoning produces the bounded-context test: listen for a word whose meaning changes. "Customer" in sales, fulfilment and finance are genuinely different concepts sharing a name, and forcing them into one model produces an entity nobody can change.