The Analog Architecture Cabinet: Building a Physical Filing System for Living System Diagrams

Digital tools dominate architecture documentation, but there’s a surprising power in going analog. A well-designed architecture cabinet—a physical filing cabinet dedicated to system diagrams—can become a thinking tool, a collaboration hub, and a living record of how your system has evolved.

This isn’t nostalgia for paper. It’s about using physical constraints and affordances to design better architecture thinking. Done right, your cabinet becomes a tangible form of your documentation strategy: structured, navigable, evolvable.

In this post, we’ll walk through how to design a physical filing system for evolving system diagrams that:

• Treats architecture as both structure and story
• Mirrors real system arrangements (hardware, software, interactions)
• Handles evolution and versioning without chaos
• Borrows patterns from modern documentation tools (tagging, indexing, navigation)
• Aligns with architecture documentation best practices
• Supports collaboration and shared understanding

1. Architecture as Structure and Story

Most architecture diagrams focus on structure: components, relationships, boundaries. But real systems are also stories: how they came to be, how they change, and how they interact with the outside world.

Design your cabinet to honor both:

Structure: The Static Views

These are the diagrams we’re used to:

• Components and connectors
• Data flows
• Deployment topologies
• Interfaces and protocols

Your cabinet should make it easy to see how the system fits together at any point in time.

Story: The Evolution and Context

This is what often gets lost in digital tools:

• Why a boundary was drawn this way
• What the previous version looked like
• How external constraints (regulation, customers, incidents) shaped the design

Build this into your filing design:

• Narrative sheets: For key diagrams, include a 1-page story: purpose, constraints, key decisions.
• Timeline folders: For major subsystems, keep a chronological set of diagrams showing how they evolved.
• Context dividers: Separate diagrams not only by subsystem, but sometimes by era (e.g., "Pre-cloud migration", "Post V2 refactor").

The cabinet should let you literally flip through the history of your system.

2. Mirroring Real Allocations: Hardware, Software, Interactions

Your cabinet becomes far more useful when its structure mirrors the actual architecture of your system. Think about how you allocate responsibilities:

• To hardware (servers, devices, networks)
• To software (services, modules, libraries)
• To interactions (user flows, external integrations, business processes)

Use these as the top-level organizing principles in your drawers.

Example Layout

Drawer 1: Hardware & Infrastructure

• Networks & zones
• Data centers / regions
• Edge devices and gateways

Drawer 2: Software & Services

• Core services
• Supporting services
• Shared platforms/components

Drawer 3: Interactions & Flows

• User journeys
• External systems integrations
• Business process diagrams

Within each drawer, use folders and subfolders to map to architectural views:

• By subsystem (e.g., Payments, Identity, Search)
• By environment (e.g., Production, Staging, Local Dev)

When someone asks, "Where is the diagram of our production network layout?" the filing logic should make the answer obvious.

3. Designing for Evolution: Versions, Space, and Cross-References

Architecture that doesn’t show its own evolution quickly becomes misleading. The analog cabinet must be version-aware by design.

Reserve Space for Growth

Don’t over-pack folders. Assume some areas of the system will change more than others:

• Leave empty folders labeled for future subsystems you know are coming.
• In fast-moving areas, keep thin folders for each major iteration (Payments v1, Payments v2, Payments v3...).

The physical space required becomes an early signal of where complexity is growing.

Versioning Practices

Treat each diagram like a code artifact:

• Add a version stamp: Service X – Logical View – v3 – 2025-05-12 – Author: A.B.
• Keep superseded diagrams behind the current version in the same folder, never thrown away—just marked as "replaced by vX".
• For major redesigns, introduce a new folder (e.g., Legacy Payments (pre-2025) vs Payments Platform (post-2025)).

Cross-Reference Cards

Use index cards or half-sheets as cross-reference cards:

• "This diagram is updated in: Drawer 2 / Software / Payments / v4"
• "For deployment details, see: Drawer 1 / Infra / Region EU / Node Layout"

These cards help you maintain navigability across changing diagrams without losing the old ones.

4. Borrowing from Modern Documentation Tooling

Think of your cabinet like a physical version of a good documentation system. Many digital patterns translate surprisingly well to paper.

Tagging (Physical Metadata)

Use coloured stickers or small label codes on diagram sheets and folder tabs:

• Blue dot = security-relevant
• Green stripe = customer-facing component
• Red star = high-risk or critical path

You can also use short tag codes on the top-right of sheets: SEC, PERF, PRIV, OPS.

Indexing and Table of Contents

At the front of each drawer, keep a drawer index sheet:

• Listing all folders in order
• Brief description of what each contains
• Version or last-updated date for critical folders

At the very front of the cabinet, keep a master table of contents:

• Drawers
• Sections
• Key diagrams and where to find them

This is your analog equivalent of a landing page.

Navigation Paths

Create guided navigation sheets for common questions:

• "To understand how a request flows from the mobile app to the database, start in: Drawer 3 > User Journeys > Mobile Checkout, then continue to Drawer 2 > Services > Checkout Service, then Drawer 1 > Production Infra > DB Cluster."

These can be printed flowcharts or simple checklists that act like documented exploration paths.

5. Aligning with Architecture Documentation Best Practices

Your cabinet should reflect well-known architecture views to avoid mixing different concerns in one messy pile.

Create clearly labeled sections (dividers or colored folders) for:

1. Conceptual Diagrams

   • High-level business capabilities
   • Domain maps and bounded contexts
   • Audience: stakeholders, product, leadership

2. Logical Diagrams

   • Services and modules
   • Key interfaces, data contracts
   • Audience: architects, senior engineers

3. Physical Diagrams

   • Deployment diagrams (nodes, clusters, regions)
   • Network layouts, firewalls, load balancers
   • Audience: infra/ops, security, SRE

4. Operational Diagrams

   • Runbooks and incident flows
   • Monitoring, alerting, failover paths
   • Audience: on-call engineers, SRE, support

Within each subsystem’s folder, maintain these sections consistently:

[Subsystem: Payments]
  01 – Conceptual
  02 – Logical
  03 – Physical
  04 – Operational

This standardization makes navigation predictable and reduces cognitive load.

6. The Cabinet as a Collaboration Surface

A physical cabinet is inherently shared. Design it as a collaboration space, not a personal stash.

Contribution Rules

Post a one-page "Cabinet Contribution Guide" on the inside of the cabinet door:

• How to label new diagrams
• Where to file specific types of diagrams
• How to mark drafts vs approved versions
• Who can archive or retire diagrams

Annotation and Feedback

Encourage teams to annotate diagrams directly:

• Use sticky notes for questions and suggestions
• Use a different pen colour for review comments
• Add date and initials to significant annotations

For major decisions, add a decision slip to the folder:

• Decision summary
• Alternatives considered
• Date, participants
• Diagram(s) this decision affects

Workshops Around the Cabinet

Treat the cabinet as a physical anchor for workshops:

• Pull out all the diagrams for a subsystem and lay them out on a table
• Ask: "Does this still reflect reality?" and "Where are the gaps?"
• Update or redraw diagrams on the spot and refile them according to the agreed structure

The goal is to make the cabinet the single shared place where architectural understanding lives in tangible form.

7. Using Physical Constraints as a Design Aid

The obvious downside of paper—limited space and friction of changes—is also its greatest strength.

Forced Clarity

You can’t just keep zooming or toggling layers. That forces discipline:

• You must choose the scope of each diagram carefully.
• You must define what is inside vs outside a boundary.
• You notice when a single sheet is trying to show too many concerns at once.

If a diagram becomes unreadable, that’s a signal to split it into clearer views.

Bounded Complexity

Drawers and folders have finite capacity:

• If one subsystem’s folder is overflowing, that’s a sign of excess complexity or churn.
• If you can’t easily trace a flow across more than a handful of folders, your system may be too entangled.

The cabinet becomes a physical mirror of complexity that’s often harder to ignore than cluttered digital repos.

Conclusion: A Living, Tangible Architecture Practice

An analog architecture cabinet is more than a nostalgic filing system. It’s a way to:

• Treat architecture as both structure and story
• Mirror how your system is actually built and used
• Make evolution and history first-class citizens
• Bring the best of digital documentation design into the physical world
• Provide a shared, collaborative space for thinking about systems
• Use physical limits to drive clarity and better design

You don’t need to abandon digital tools; the cabinet complements them. Start small: one drawer, one subsystem, one set of diagrams organized with intent. Over time, your analog architecture cabinet can become a powerful, living artifact of how your system—and your understanding of it—grows and changes.