Follow the Money Patterns

Patterns / 2. Diagnosis

Pattern 2.8

Draw It, Don’t Present It

Have the people who build and run the system draw it from memory, rather than presenting the official architecture diagrams.

Draw It, Don't Present It
Draw It, Don't Present It

In This Context

Official architecture diagrams can be every bit as fictional as org charts. They are often drawn for a purpose unrelated to keeping an accurate internal record: to win approval for a project, to pass an audit, or to impress a vendor or a new CTO. They show the system as someone wanted it to be seen at the time, and then go stale. What people believe the system is, on the other hand, is what they make decisions on. The way they draw it is revealing too: which parts are drawn in detail, which are vague clouds labeled “the mainframe,” which nobody can place, and which get a knowing laugh.

  • A senior architect can steer a group toward the official story as easily as an executive can.
  • Too much detail (subnet ranges, every microservice) hides the question that matters.

Therefore

Ask the group to draw the major components and their connections from memory, at a coarse level: things that are deployed and run in their own right, or major components owned by a team. Then mark each component with the team that owns it, who funds that team, and whether its costs are CapEx or OpEx.

  • Ask what is running that wouldn’t appear on any official diagram.
  • Mark any component with no owner, or whose owner has no funding for it, as an orphan.
  • Say at the start that you are mapping the system, not judging the people who built it.

Consequently

  • The real system appears, including shadow IT and orphaned components.
  • Ownership and funding can be traced from components back to the money.
  • The ownership and funding step usually overruns, because nobody in the room knows who pays for something the whole business depends on. That conversation is worth having, so plan the time for it.

Seen In

Chapter 14, “Draw It, Don’t Present It”. Also: Chapter 14 “Running the Workshop”, Chapter 14, sidebar “Shadow IT Mapping”, and the same rule for org charts in Chapter 12, “Throw Away the Map and Make Your Own”.