Blog

Process architecture: from the diagram to the repository

“Show me your process architecture.” What appears is almost always a drawing: the process map with its bands — core, support, management — perhaps backed by a folder of BPMN diagrams. It is a good start, and in many contexts a required one. But it is worth being precise about what that drawing can do: a map answers one question — what processes exist and how they are grouped.

An architecture has to answer harder questions:

  • Which business capability does this process operate, and which other processes operate the same one?
  • Which services stop being delivered if this process stops?
  • Which data does it consume, which rules does it apply, and what evidence does each decision leave?
  • Which indicator demonstrates its outcome — and against what target?
  • If I change this rule, this data element or this owner, what else is affected?

A diagram cannot answer them, however good it is, because its elements are shapes with names, not objects with relationships. The arrow joining two boxes knows nothing; it only suggests. That is the real difference between drawing processes and having process architecture — and it does not depend on the drawing tool, but on whether there is a repository behind the drawing.

The four heights

A complete process architecture is not one large drawing: it is four levels, each made of objects that relate to the objects of the next.

Height Artefact What it declares
1 Value chain How the organization produces value, end to end
2 Capability map What it must know how to do — the stable abstraction, independent of org charts and systems
3 Process record Each process’s verifiable objective, owners, data, risks and indicators
4 BPMN diagram The executable coordination of activities, decisions, data and rules

The most common failure is having only height 4 — hundreds of diagrams — or only height 2 — a capability map made for a committee. The architecture lives in the relationships between heights: this BPMN implements this record, which operates this capability, which sustains this link of the chain. When those relationships exist as data, they can be queried; when they exist as the memory of the consultant who drew the map, they leave with him.

What changes when there is a repository

In a repository, every element of the drawing is an object with attributes and relationships subject to integrity constraints: no process exists without a service it delivers, no approved process lacks a verifiable objective and an achievement indicator, no change is approved without assessing its impact. Three practical consequences:

Conformance is queried, not opined. Asking “which processes have no anchored indicator?” stops being a weeks-long documentation review and becomes a query with an immediate answer — and every finding points at the exact object to complete.

Impact is known before touching anything. Changing a rule, a data element or an owner shows which processes, services and indicators depend on it. Impact analysis stops being a meeting of experts and becomes a property of the architecture.

The diagram becomes a view. BPMN remains the language — that does not change — but it stops being the primary artefact: it is the visual projection of objects that also execute, get measured and get versioned. The model and reality cannot diverge, because they are the same thing.

The practical test

If you want to know which side your process architecture is on, do not review the drawing: ask it a question. “Which processes operate the supplier-management capability?” If the answer comes from a query, you have an architecture. If it comes from opening diagrams one by one — or from calling whoever drew them — you have an inventory of drawings. Valuable, but something else.

The full traceability chain — from strategy to indicator — is developed on the executable business architecture page, and the four heights, as they are configured on the platform, on the Dexon Architect page. The metamodel with its fifteen integrity constraints is in the Dexon BPM V8 methodology, downloadable without a form. And if you prefer the test to the reading: bring us your process map and we will show you, on one of your own processes, which questions it would start answering.

← All articles

Walk it through a process of yours

Everything on this blog comes from the published methodology. In a working session we show it running on one of your processes.

Book a technical session