Architecture & operational improvement
The diagram is not the system
A process diagram is useful. The danger begins when everyone quietly agrees to treat it as a complete description of how the organisation actually works.
People make imperfect systems work
Real organisations accumulate history. Systems overlap. Ownership moves. Suppliers change. Temporary workarounds survive for years. A spreadsheet becomes part of a control because everybody knows which column not to trust. An approval happens through a conversation because the formal workflow never fitted the exception.
People compensate for those gaps continuously. They remember that one record is stale, that a certain customer needs different handling, that a particular failure means the next system has not caught up yet, or that the documented owner is not the person who can actually make the decision.
Most of that knowledge never appears on the clean process diagram.
Automating the imagined process creates a faster problem
If a transformation team automates only the documented happy path, it can remove the very human judgement and informal correction that kept the old process functioning.
The result may look successful in a demonstration because the demonstration follows the same diagram used to design the solution. Production is where the exceptions, timing differences, duplicate records and contradictory ownership arrive.
AI does not remove this problem. In some cases it makes it more important because an apparently capable system can progress further through a broken process before a human notices what has happened.
Never automate the imagined process. Discover the real system first, then decide where intelligence belongs.
Discover the operation, not just the workflow
Useful discovery follows the work across organisational and technical boundaries. It asks what outcome the process exists to produce, who is involved, which systems hold authoritative state, where information is duplicated, how decisions are made and what happens when the normal path fails.
The map should include the informal parts precisely because they are informal. A workaround may represent technical debt that should be removed, but it may also be compensating for an important business rule nobody wrote down.
- Outcome and business purpose
- Actors, owners, consumers and suppliers
- Systems, integrations and systems of record
- Data movement and duplicated state
- Decision points and approval authority
- Exceptions, retries and manual workarounds
- Failure modes and recovery paths
- Controls, permissions and audit requirements
- Measures that show whether the process is actually better afterwards
Not all friction is waste
A slow step may be pointless duplication. It may also be where somebody notices a bad assumption before it becomes an expensive commitment. A manual hand-off may be poor integration, or it may separate two duties deliberately.
The job is not to preserve every existing control. It is to understand why it exists before removing it. Once the purpose is clear, the control can often be implemented more cleanly, automated deterministically or placed at a better point in the process.
The principle applies well beyond AI
The same failure appears in cloud migrations, operating-model changes, supplier transitions, resilience programmes and application modernisation. A target architecture based on an incomplete current-state model inherits surprises into delivery.
Good architecture reduces that uncertainty. It connects the technical environment to the way the organisation actually operates, makes important dependencies and trade-offs visible, and creates transition states that delivery teams can realistically execute.
The output may include diagrams, but the value comes from the shared understanding behind them.
Keep the map alive
Discovery should not be a ceremony completed at the beginning of a programme and then archived. Delivery changes the environment. New constraints appear. Operational evidence proves some assumptions wrong.
A useful map evolves with the work. Incidents, service data, implementation decisions and changing business direction should feed back into it. That keeps architecture connected to reality rather than turning it into documentation of a system that no longer exists.
The diagram is still useful. It just needs to remain a representation of the system, not a substitute for understanding it.