🧭 Architecture DNA Compass: Read Systems Beyond Pattern Labels

1. The Hook: an architecture is not a product label

Ask a team what architecture it runs and the answer often sounds like a technology catalog: microservices, event-driven, CQRS, Kubernetes, perhaps hexagonal architecture for good measure. The labels may all be true—and still explain surprisingly little.

A real system can be a modular monolith at the deployment boundary, hexagonal inside selected modules, event-driven across domains, and CQRS only where read and write pressures diverge. These terms do not compete on one axis. They describe different forces.

Architecture is not one pattern. It is the accumulated shape of decisions about boundaries, dependencies, communication, state, execution, deployment, policy, and change. Architecture DNA Compass is a proposed heuristic for reading that shape. It is not an industry standard, maturity score, or substitute for architectural judgment.

The metaphor matters: a compass supports judgment under pressure; it does not turn architecture into a single destination or score.

The framing complements established tools. The C4 model provides multiple zoom levels plus dynamic and deployment views. arc42 separates building-block, runtime, deployment, quality, risk, and decision concerns. The Compass comes earlier: it asks what to inspect before choosing how to document or evaluate it.

2. Core architecture: eight dimensions, not eight silos

Decomposition and dependency

Decomposition asks what exists: systems, services, modules, components, workers, and stores. A boundary is useful only when it contains responsibility and limits the blast radius of change. Folder count is not architecture.

Dependency asks who knows whom and how change propagates. Direction, fan-in, fan-out, cycles, shared contracts, and shared state often reveal more than a repository tree. A system with 100 modules and disciplined dependencies may be easier to change than one with 15 mutually importing modules.

Communication and data

Communication includes more than HTTP versus queues. It covers sync versus async behavior, delivery guarantees, ordering, timeouts, retries, idempotency, backpressure, schema compatibility, and failure semantics. Replacing a function call with an event bus changes the system’s relationship with time and partial failure.

Data begins with ownership, not storage location. Trace transaction boundaries, consistency, replication, derived state, caches, indexes, retention, migration, lineage, and synchronization. Shared databases frequently expose boundaries that exist in slides but not in operations.

Execution and deployment

Execution asks how work unfolds over time: request/response, scheduled jobs, consumers, workflows, retry loops, human approvals, long-running processes, or agent loops. Boxes alone cannot explain resumability, compensation, or recovery.

Deployment maps logical components to processes, containers, nodes, clusters, regions, and networks. A logical service is not necessarily one container, and a container is not an availability strategy.

Policy and evolution

Policy covers authentication, authorization, trust boundaries, tenant isolation, sandboxing, secrets, quotas, audit, approval, and cost limits. In banking, healthcare, multi-tenant cloud, or autonomous-agent platforms, policy can dominate the design.

Evolution tests whether today’s clean design survives tomorrow’s change: API and schema versioning, compatibility, extension points, feature flags, rolling migration, deprecation, and data migration. A diagram is a snapshot; architecture is a living constraint system.

3. The execution loop: how to read an unfamiliar codebase

Do not begin with random files. Build a hypothesis and force the repository and runtime to confirm or reject it.

A practical pass looks like this:

1. Define the system boundary, actors, and external systems.
2. Inventory the major building blocks without reading every implementation.
3. Build the dependency graph and identify cycles or shared state.
4. Trace communication across every meaningful boundary.
5. Follow one critical entity through creation, mutation, copying, indexing, and deletion.
6. Trace three to five flows, including failure recovery—not only the happy path.
7. Map logical components to runtime and regions.
8. Locate trust, tenant, secret, quota, audit, and approval boundaries.
9. Find everything versioned—or dangerously unversioned.

This workflow aligns with arc42’s advice to focus detail on important, surprising, risky, complex, or volatile building blocks rather than pursuing completeness for its own sake.

4. The nightmare: turning a compass into fake precision

Each dimension can be reviewed against three pressures on a 0–5 scale:

• Complexity: How many mechanisms, states, dependencies, and moving parts exist?
• Criticality: What is lost if this dimension fails—one job, money, data, trust, or the entire service?
• Change rate: How quickly do requirements, contracts, teams, or technologies move?

An optional triage heuristic is:

$$ \text{Attention} = \text{Criticality} \times \frac{\text{Complexity} + \text{Change Rate}}{2} $$

It ranks review attention; it does not measure architecture quality. A large radar is not automatically bad. Air-traffic control should carry more architectural pressure than a landing page.

The largest failure mode is score theatre: architects debate whether a cell is 3.7 or 4.1 without evidence. Every score needs a trail—dependency cycles, shared packages, trace spans, retry paths, incident data, schema churn, API versions, or Git change frequency.

The second failure mode is optimizing the fingerprint itself. Lower complexity can harm reliability; stronger isolation can raise latency and operating cost; faster evolution can weaken compatibility. The SEI Architecture Tradeoff Analysis Method evaluates architecture relative to quality-attribute goals and explicitly exposes risks and trade-offs. That is why the Compass needs a North Star outside the radar.

5. The architect’s fork: document, evaluate, or instrument?

Path A — a fast onboarding snapshot

Use the eight dimensions to compress what is known and unknown. This is appropriate during acquisition, incident handover, or entry into a large repository. The output is a question map, not a verdict.

Path B — a formal architecture review

Use the Compass to locate pressure, then switch to C4 or arc42 for documentation and ATAM for scenario-based quality trade-offs. ISO/IEC 25010:2023 supplies a standardized product-quality vocabulary; the Compass does not replace it.

Path C — architecture observability

Automate the evidence: dependency graphs and cycles for Dependency; service calls and event topics for Communication; schemas and lineage for Data; traces and workflow definitions for Execution; IaC and topology for Deployment; API versions and change frequency for Evolution.

The valuable end state is not a radar updated every six months. It is an instrument panel that changes with the system and makes drift visible.

For a practical walkthrough of how quality goals become evaluation questions, Felix Bachmann’s SEI webcast, Architecture Evaluation: A Tool for Designing Systems That Meet Users’ Needs, is worth watching. Its useful contribution is the bridge from a one-time ATAM review to continuous design feedback—the same bridge the Compass needs if it is to become instrumentation rather than workshop theatre.

The question that replaces the label

Two systems called “microservices” may have opposite DNA. Two systems built with different stacks may share the same pressure profile. The useful question is no longer “What is this architecture called?” It is:

Where is this system under pressure, what outcomes matter most, and what evidence says the architecture should evolve?

Sources

• Architecture DNA Compass — source document
• C4 model diagrams
• arc42 Building Block View
• SEI Architecture Tradeoff Analysis Method
• ISO/IEC 25010:2023 product quality model
• SEI webcast: Architecture Evaluation—A Tool for Designing Systems That Meet Users’ Needs