Mastering Software Architecture Diagrams: From 4+1 to C4 Views

What Is Architecture?

Architecture is an abstract representation of a system, defining the relationship between its functional and structural elements, as well as their interaction with the surrounding environment.

Architecture Layers in TOGAF

In TOGAF, architecture is refined from the strategic level down through Business Architecture, then Application, Data, and Technology Architecture. Practitioners usually focus on the Application/Data/Technology layers.

Types of Architecture

Business Architecture – defined by business architects; influences organization and technical design.

Application Architecture – designed by application architects; structures components, interfaces, and data exchange while controlling complexity and ensuring non‑functional requirements.

Technology Architecture – describes required services, technology components, and their interactions.

Data Architecture – defines data models, distribution, flow, lifecycle, and management.

Classification of Architecture Diagrams

4+1 View

Scenario View – depicts actors and use cases, usually with a use‑case diagram.

Logical View – shows component relationships and boundaries, often using UML component and class diagrams.

Physical View – maps software components to physical hardware nodes, guiding deployment.

Process View – describes component interaction sequences and data flow, typically with sequence or flow diagrams.

Development View – outlines module decomposition and package structure for developers.

C4 View

System Context Diagram – shows the system’s scope, users, and external dependencies.

Container Diagram – expands the context into containers (applications, databases, micro‑services) and their interactions, targeting developers and operations.

Component Diagram – breaks a container into components/services, showing internal structure for developers.

How to Draw Good Architecture Diagrams

Before drawing, identify the diagram’s audience and the information they need. A good diagram should be self‑describing, consistent, and accurate enough to align with the code base. Use distinct shapes, colors, and line styles to differentiate elements and avoid semantic confusion.