When your diagrams are drawings and you need models
A drawing tool will happily let you connect two boxes that have nothing to do with each other, because it does not know what a box is. That is fine for a slide and expensive for an architecture.
The situation
The estate is documented in Visio or Lucidchart. The diagrams look fine. The problem shows up when someone asks a question of them — what depends on this, which of these are in scope, what changed since the last review — and the only way to answer is for a person to read the picture.
The second problem is drift. A general-purpose diagram has no relationship to the system, so it is correct on the day it is drawn and degrades from there with nothing to signal it.
The case for moving is not that the new drawings are prettier. It is that a connector becomes a recorded relationship, which is what makes the diagram answerable and what makes staleness detectable.
You are here if
- Answering "what depends on this" means opening a diagram and tracing lines by eye.
- The same system is drawn three times in three decks, and they disagree.
- Nobody knows which diagram is current.
- Diagram maintenance is a task somebody is assigned rather than a by-product of the work.
How the work gets done
Bring the existing diagrams in rather than redrawing them
Import the Lucidchart or Visio files directly. Not everything survives a format conversion, and the geometry that does come through will need tidying — but importing a hundred diagrams and correcting them is a different order of work from redrawing a hundred diagrams.
Diagram ▸ Import Lucidchart (.vsdx)Diagram ▸ Open Format File
Turn the lines into relationships
An imported line is still a line. The work that changes what the diagram can do is labelling the connections for what they are and giving the shapes a type, so that a component is a component and a table is a table.
This is the step people want to skip and the step the entire benefit depends on. A tidy import with untyped shapes is the old situation in a new tool.
Page ▸ ConnectorPage ▸ Entity / Table
Prove the difference on one real question
Pick a question that used to require tracing lines by eye and answer it from the model instead. Impact analysis over one migrated diagram does more to make the case internally than any amount of explanation.
Data ▸ Impact AnalysisArch ▸ Platform Lens
Stop the drift from restarting
Put the diagrams under version history and, where it fits, in the repository alongside the code they describe. Drift is not prevented by discipline; it is prevented by the diagram being somewhere a change has to pass through.
Presentation and export still exist for the audiences that want a picture, so moving does not cost you the deck.
Diagram ▸ Version historyArch ▸ GitHubDiagram ▸ Export Center
What you end up holding
- The existing diagram estate imported rather than redrawn, with a known list of what did not survive.
- Typed shapes and labelled connections, so the diagrams answer dependency questions.
- Version history on every diagram, and exports for the audiences that want a picture.
Not this, if
- Your diagrams are org charts, floor plans or process maps. Those are drawings, and a drawing tool is the right tool for them.
- You need pixel-faithful conversion of a large Visio estate. Import is good enough to build on, not good enough to be invisible; budget for correction.
- The team draws two diagrams a year. The modelling overhead will not pay for itself.