Every ServiceNow shop I've worked in has the same folder. It's called something like Architecture — CURRENT, it's full of Visio and Lucidchart exports, and every file in it is a small historical fiction. The diagram of the order platform shows a service that was decommissioned in March. The integration map is missing the two APIs that went live last quarter. Everyone knows this, nobody says it in the meeting, and the diagram gets shown anyway — because it's the only picture anyone has.
Here's the uncomfortable part: this is not a discipline problem. You cannot fix it with a better process, a diagram owner, or a quarterly "architecture refresh" task. It drifts because of how the artifact is built.
The three structural reasons
1. The diagram and the record have no connection. The CMDB knows the truth — that's its whole job, and after years of CSDM work, most estates' CMDBs are decent. But the diagram is a copy of that truth, made by hand, at a point in time. A copy with no link back to its source starts aging the moment it's saved. The half-life of an accurate architecture diagram is roughly one change window.
2. The diagram is a picture, not a document. Visio files and canvas tools store geometry — boxes and coordinates. You can't diff two versions and see what actually changed in the architecture. You can't review a diagram change the way you review a code change. So updates are wholesale redraws, redraws are expensive, and expensive things get deferred. Drift is just deferred maintenance you can see.
3. Nobody's job depends on the diagram being right. The CMDB has data certification, audits, and an owner. The diagram has none of that. When the pressure is on, the record gets updated (something breaks if it isn't) and the picture doesn't (nothing breaks — until the day someone designs on top of the fiction).
Native tools help less than you'd hope here. Dependency Views and EA Workspace will show you what the CMDB knows, live — genuinely useful. But they render the current state inside the platform. The moment you want to design what comes next, annotate a proposal, or hand a reviewable artifact to a change board, you're back to exporting a picture, and the picture starts drifting.
What actually fixes it
Change what the artifact is. Three properties, and drift stops being a fact of life:
Generated, not drawn. The current state should come from the CMDB — walk the relationships from a business application, and every node on the canvas carries the class and sys_id of the record behind it. When the estate changes, you refresh and see what moved. Nobody redraws anything, because nobody drew it in the first place.
Text, not geometry. If the diagram's source of truth is a readable DSL — nodes, edges, groups, one concept per line — then a change to the architecture is a change to a text file. It diffs. It reviews. It versions. The layout is still there, still draggable, but it's a projection of the document, not the document itself.
Maintained by whatever maintains the system. This is the 2026 part. Your pipelines and coding agents already know when a service was added or an integration changed — they did it. Give them a typed, safe way to edit the diagram (optimistic concurrency, so a stale write gets a 412 instead of silently clobbering a human's edit) and the artifact stops depending on anyone's memory. The diagram gets the same maintenance story as the code.
And once current-state is generated and future-state is a layer over it, the change request stops being a Word document with screenshots: it's the diff, with the affected CIs listed by sys_id, and the architecture decision record linked to the exact change it justifies.
That's the design behind [ArchTruth](https://archtruth.app) — read-only against your instance, everything exports as plain text, and your agents keep it honest. But whether or not you use my tool: stop scheduling redraws. The folder full of fiction isn't a discipline problem, and no amount of discipline will fix it.