Architecture Diagram

The architecture diagram is the one-page answer to 'what are we actually building, and where does it live?'. Every serious proposal contains one; the skill — for executives — is reading it as a risk document rather than a decoration.

What It Is

An architecture diagram shows the major components of a system and how they connect: applications, databases, message queues, external services, and the boundaries between them. Better diagrams carry the details that determine operability — which parts run where (cloud regions, on-premise), where data is stored, which components are shared or duplicated, and where the dependencies on third parties sit. Architecture diagrams come in levels: a context diagram showing your system and its external actors, container diagrams showing deployable pieces, and component diagrams going deeper.

Why It Matters to You

Read an architecture diagram as a map of risk and control. Single arrows going out to external services are third-party dependencies — each one a potential point of failure and a data transfer. A diagram with no boundaries drawn between your data and the vendor's is telling you something. Redundancy visible (or absent) in the diagram predicts availability far better than the SLA page. And in an era where boards must attest to data residency and AI governance, the architecture diagram is the artefact those attestations rest on — you cannot govern what has never been drawn. When a vendor's proposal diagram is a logo collage instead of components and flows, that is not a style choice; it is a disclosure failure.

When You'll Meet It

In every technical proposal, design review, and due diligence. Make it standard that no architecture is approved that exists only in someone's head or in slideware logos.