Introduction: Why Big Systems Need Small Drawings

Most large software systems don’t fall apart because of bad code. They fall apart because no one can see how the pieces fit together anymore.

Confluence pages go stale. Formal architecture documents become shelfware. Diagrams are created once for a presentation and then abandoned. The system keeps evolving, but the visual understanding of it does not.

There’s a surprisingly simple antidote: tiny, disposable-looking paper diagrams that you treat as anything but disposable.

Think of your architecture as a garden. If you only landscape once at project kick-off and never tend it again, you get weeds. If instead you keep a handful of small, easy-to-change sketches on hand, you can prune, re-plant, and reorganize as the system grows.

This post explores how a “sticky architecture garden” works in practice:

• Starting with hand-drawn paper diagrams
• Turning those sketches into living, traceable artifacts
• Linking diagrams, decisions, and code for better reviews
• Using standard modeling languages (like UML) as a shared visual vocabulary
• Combining lightweight visuals with refactoring, patterns, and SOLID
• Practicing regular visual gardening so diagrams stay aligned with reality

Small Paper Diagrams: The Low-Friction Start

Whiteboard sessions feel productive because they’re quick and social. Paper diagrams are the same—but portable and persistent.

Why start on paper?

• Low friction: No tooling, no permissions, no formatting worries. Just draw.
• Low intimidation: People who “hate UML” will still sketch boxes and arrows.
• High signal: Constraints of space force you to capture only the essentials.

A few powerful patterns for small diagrams:

• Context sketch (1 page): Who uses the system? What external systems exist? What are the main boundaries?
• Core components (1–2 pages): Major services, databases, and flows between them.
• One feature, one diagram: The minimal structure needed to implement a new capability.

At this stage, treat diagrams as thinking tools, not documentation. The value is in the conversation they trigger: “Wait, where does this service validate the request?” or “Why does the frontend talk directly to that database?”

The twist is what comes next: you don’t throw these diagrams away.

From Sketches to Living Architecture Artifacts

Most diagrams die because they’re treated as static deliverables. Once the feature ships, the drawing is “done.”

Instead, treat each diagram as a living artifact:

• It has a clear purpose (what question it answers).
• It has owners (who updates it when things change).
• It is easy to revise (not trapped in a heavyweight tool or format).

Over time, these become breadcrumbs of architecture knowledge:

• How did we get from a simple monolith to multiple services?
• Why does this module still exist when everything else moved to event-based flows?
• What constraints were we obeying when we made that strange-seeming decision?

Because the diagrams are small and focused, updating them is feasible:

• A new endpoint? Update the feature-level sketch.
• New service boundary? Redraw that part of the context diagram.

Each update is a tiny gardening action—pulling a weed, trimming a branch, planting a new shrub. The garden stays healthy because maintenance is continuous and lightweight.

Making Architecture Traceable: Diagrams, Decisions, and Code

Architecture only becomes truly useful when you can connect three things:

1. How the system looks (diagrams)
2. Why it looks that way (decisions)
3. Where it actually lives (code)

This traceability is what makes architecture “sticky”—developers keep coming back to the diagrams because they help answer real questions.

A simple but powerful practice:

• Every architectural-scale change gets a small decision record (ADR or similar):
  • Context: what problem we’re solving
  • Decision: what we chose
  • Consequences: trade-offs, risks, impacts
• Each decision references specific diagrams it affects.
• Each diagram references specific code artifacts (modules, services, repos).

Examples of links:

• In the ADR: “See service-split-v2.png for the new service boundary.”
• On the diagram: “Implements ADR-017: Split billing from order management.”
• In the code (e.g., README or comments): “This module reflects the ‘Billing Context’ in diagram system-context-2025-01.”

This allows:

• Impact analysis: “If we change this service API, which diagrams and decisions are affected?”
• Design reviews: “Show me the diagram and the ADR for this new event bus.”
• Audits and assessments: “How did you ensure separation of concerns in this layer?”

Instead of isolated artifacts, you have a woven fabric of visuals, rationale, and implementation.

A Shared Visual Language: From Scribbles to UML (Lightly)

Hand-drawn boxes and arrows are great—until different people interpret them differently.

This is where a standard modeling language like UML (or C4, SysML, ArchiMate, etc.) is useful. Not for heavyweight modeling, but as a shared visual vocabulary.

You don’t need the entire UML specification. You need just enough:

• Simple class or component diagrams for structure
• Sequence diagrams for key interactions
• Maybe deployment diagrams for where things run

Benefits of this light standardization:

• New team members can read old diagrams without a legend.
• Teams can refine and extend each other’s diagrams without confusion.
• Visuals can be translated between tools when needed.

A practical approach:

1. Start sketches on paper using UML-ish shapes: boxes for components, arrows for calls, stick figures for actors.
2. For diagrams that prove durable or high-value, digitize them using a lightweight tool.
3. Keep a 1-page “visual style guide”: what symbols mean, naming conventions, and typical levels of detail.

The goal isn’t formality. It’s shared meaning.

Connecting Code Changes to Architecture Intent

Your architecture garden becomes even more powerful when you link it to familiar code-level concepts:

• Refactoring: When you refactor a module (e.g., extract a class, introduce an interface), update the corresponding structural diagram.
• Design patterns: When applying a pattern (e.g., Strategy, Adapter, CQRS), show it explicitly on the diagram.
• SOLID principles: Use diagrams to visualize where responsibilities live, where dependencies point, and where abstractions sit.

Examples:

• Before a large refactor, sketch the current design and the target design side by side.
• When adopting a design pattern, add a small annotation: “Strategy pattern here to isolate pricing rules.”
• When enforcing SOLID, use diagrams to highlight violations (e.g., a class with arrows from everywhere; a service owning unrelated responsibilities).

This creates a feedback loop:

1. High-level intent captured visually.
2. Code changes implemented and refactored.
3. Diagrams updated to match reality.

Developers begin to think architecturally as they code, because the architecture is something they see and shape every day—not just in sporadic “architecture meetings.”

Visual Gardening: Prune, Refactor, Reorganize

Gardening is a helpful metaphor because architecture work is never done. The key is to make the upkeep small and routine.

Some practical “visual gardening” habits:

• Weekly pruning: Spend 15–30 minutes in a team meeting reviewing 1–2 core diagrams.
  • Remove obsolete elements.
  • Add missing components.
  • Fix misleading or outdated labels.
• Refactor diagrams when they get messy:
  • Split a sprawling diagram into two more focused views.
  • Change the layout to emphasize the main flow and hide incidental complexity.
  • Extract repeated structures into a shared “pattern sketch.”
• Reorganize the diagram set occasionally:
  • Archive truly obsolete diagrams into a clearly marked “history” area.
  • Promote frequently used diagrams to a “front page.”
  • Add tags or folders by feature, domain, or system boundary.

The point is not to be perfectly up-to-date at all times. The point is to be close enough that diagrams are useful:

• For onboarding
• For debugging cross-cutting issues
• For planning major changes or migrations

If developers see that diagrams are mostly accurate and easy to adjust, they will actually use and update them.

That’s what makes architecture sticky.

Building a Sticky Architecture Practice

A “sticky” architecture practice is one that people keep coming back to because it helps them do their daily work better.

To get there:

1. Start tiny: One paper diagram per important feature or service.
2. Make updating diagrams part of the Definition of Done for architectural changes.
3. Record decisions in a lightweight way and link them to diagrams.
4. Adopt a minimal shared notation so diagrams are consistent and readable.
5. Schedule regular gardening—short sessions, small improvements.

You don’t need a massive modeling repository or a dedicated “architecture team” to start. You need:

• A pen, some paper or sticky notes
• A shared folder or board
• A bit of discipline around linking diagrams, decisions, and code

Over time, these tiny habits grow into a rich, navigable architecture garden. New developers can walk its paths. Experienced developers can prune and extend it. And when the system inevitably changes, your visual understanding changes with it.

That’s how big systems grow safely—from tiny paper diagrams, tended regularly, and kept just sticky enough that no one ever has to say, “We have no idea how this thing really fits together.”