A travel platform's teams describe their work as "search", "book", "pay", "support". Are these capabilities or processes, and why does the distinction matter architecturally?
Show the full answer Hide the answer
The distinction
A capability is what the business can do, stated as a stable noun: inventory management, pricing, payment processing, fraud detection, customer communication. It answers "what", is stable over years, and does not change when the business changes how it works.
A process is how a capability is exercised in sequence: search → select → book → pay → confirm. It answers "how and in what order", and it changes constantly as the product evolves.
The list in the question is a mix. "Payment processing" is a capability. "Book" is a step in a process.
Why it matters architecturally
Capabilities make durable boundaries; processes do not.
A service organised around a process step is coupled to the current sequence. When the product introduces instant booking, or splits payment from confirmation, or adds a hold-then-confirm flow, the service boundary is wrong and everything must move.
A service organised around a capability — payment processing, exposing authorise, capture, refund, and enquire — survives every re-sequencing, because the capability did not change even though the process did.
This is the same reasoning that makes bounded contexts stable: boundaries drawn around what something is outlive boundaries drawn around when it happens.
The practical test
For each proposed boundary, ask: would this still exist if the product flow changed completely?
- Pricing would still exist. Capability.
- Checkout step two would not. Process step.
- Inventory availability would. Capability.
- Post-booking confirmation email would not — it is one use of a customer communication capability.
The nuance worth stating
Processes still matter enormously — they are how value reaches the customer, and value-stream mapping is how you find where time is lost. The error is not caring about processes; it is building service boundaries around them.
The workable arrangement is capabilities as services and processes as orchestration across them: a booking workflow that sequences capability calls. When the process changes, the orchestration changes and the capabilities do not — which is exactly the property you wanted.