Process Model

A capability is what the business does; a process is how it currently does it. The distinction matters because capabilities are stable for decades and processes change constantly — and confusing them produces architecture that is coupled to a way of working rather than to the business.

The rule that follows: build systems around capabilities, configure them around processes. A system whose structure encodes the current approval sequence must be rebuilt when the sequence changes, which it will.

What a process model should capture to be useful for architecture: the actors and where work changes hands; the decision points and who owns each; the systems touched at each step; and the handoff delays, which are usually where the elapsed time actually goes.

The distinction between as-is and to-be models must be explicit and labelled. An aspirational process presented as current is the most common defect in this kind of documentation, and it misleads exactly the people relying on it to plan.

The finding that recurs when a real process is mapped for the first time: the documented process and the actual process differ substantially, because people have routed around a step that does not work. That divergence is data, not non-compliance — it usually indicates where the process or the system is wrong.