Executable architecture, in practice
Working notes from the methodology and the platform: how processes, data, indicators and risks behave when the architecture actually executes.
The objective is the specification: objective-driven design and adaptive process orchestration
Forrester's adaptive process orchestration assumes the route can vary. What holds the process accountable then is a formal objective: targets, tolerances, sources and constraints an engine can check.
Maturity is demonstrated, not declared
An organization is not at the maturity level it declares: it is at the level it can demonstrate with evidence from its platform. The five Dexon levels and the criterion between them.
What it means for a BPM to be quantum-resistant (and what it does not)
The threat is not in the future: it is capturing today and decrypting later. What really protects core business data, what a quantum computer breaks, and how to read any vendor's claim.
Total alignment: why alignment is a set of relationships, not fields on a form
Objective, initiative, process, capability and risk: if an indicator's alignment is typed into fields, it degrades unnoticed. If it is a set of relationships, it can be queried.
The KRI is a relationship, not a checkbox
The same indicator can carry a target — making it a KPI — and a link to a risk — making it a KRI — without duplicating anything. And the register's early-warning signals are its natural seedbed.
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.