How to Create Effective Software System Architecture Diagrams: 4+1 View, 4R Method, and Common Diagram Types

4+1 View

When you think of software architecture diagrams, the 4+1 view often comes to mind as a standard, but it is not the only way to draw them.

Kruchten (1995) observed that a single view cannot describe all concerns of a software system and proposed using several concurrent views, each solving a specific set of problems.

The relationship among the views is shown in the diagram below.

The core idea of the 4+1 view is to analyze the system from different angles:

Logical View : From the end‑user perspective, shows the functionality (UML class and state diagrams).

Process View : From a dynamic perspective, shows processing (UML sequence and activity diagrams).

Development View : From the programmer perspective, shows logical decomposition (UML package diagrams).

Physical View : From the system‑engineer perspective, shows physical deployment (UML deployment diagrams).

Scenario View : From the user perspective, shows requirements (UML use‑case diagrams).

Although comprehensive, many teams do not follow the 4+1 standard in practice for three main reasons:

Increased complexity : Modern distributed systems (e.g., micro‑services) make the Development view hard to represent.

UML constraints : UML diagrams often look unattractive and have limited expressive power.

Understanding difficulty : Logical, Development, and Process views are easily confused.

Core Guiding Idea: 4R Architecture Definition

The main difficulty in drawing good architecture diagrams is deciding what content to include. The 4R method provides a clear standard.

Software architecture defines the top‑level (Rank) structure of a system, specifying which Roles exist, how they relate (Relation), and the governing Rules.

4R consists of four keywords: Rank, Role, Relation, Rule. The steps are:

Step 1 – Clarify Rank : Choose the level (L0‑L4) you want to describe and limit the diagram to that scope.

Step 2 – Identify Roles : Decompose the system into roles, each represented by a block, icon, or node.

Step 3 – Define Relations : Connect the roles with lines that indicate different kinds of relationships.

Step 4 – Add Rules : Select core scenarios and illustrate how roles collaborate, typically using a sequence diagram.

The diagram that shows Roles and Relations is called a static architecture diagram, while the diagram that shows Rules (sequence) is a dynamic architecture diagram.

Common Architecture Diagrams

Using different ways to partition the system yields various diagram types.

1. Business Architecture Diagram

Definition: Shows what business functions the system provides, similar to the Scenario view of 4+1.

Use cases:

Product planning and reporting.

High‑level business briefings for senior leadership.

New‑employee training.

Drawing tips:

Use colors to indicate business status (e.g., active, planned, stable).

Group related business items with dashed boxes or background shading.

Align blocks for visual neatness.

Reference case: AlipayHK business architecture diagram.

2. Client / Frontend Architecture Diagram

Definition: Describes the domain‑logic architecture of a client or frontend application.

Use cases:

Overall architecture design by a frontend architect.

Architecture training.

Drawing tips:

Color‑code different roles.

Use varied line styles to distinguish direct calls from event notifications.

Layer or group similar roles.

Reference case: WeChat client 3.x architecture diagram.

3. System Architecture Diagram

Definition: Describes the backend logical architecture (also called technical architecture).

Use cases:

Overall system design.

Architecture training.

Drawing tips:

Color‑code different roles.

Show relationships with connecting lines.

Group logically related components.

Reference cases:

Simple system – MongoDB Sharding architecture:

Complex system – payment middle‑platform architecture (roles and relations):

4. Application Architecture Diagram

Definition: Shows which deployable applications compose the backend system.

Use cases:

Project development and testing.

Operations deployment.

Sub‑domain architecture design.

Drawing tips:

Color‑code different roles.

Use lines to indicate relationships.

Separate domains for large systems.

Reference case: Simple system – MongoDB Sharding application diagram:

Complex system – payment middle‑platform member domain application diagram:

5. Deployment Architecture Diagram

Definition: Shows how the backend system is physically deployed, including data‑center, network, and hardware details.

Use cases:

Overall architecture design.

Operations planning and optimization.

Drawing tip: Use icons instead of plain blocks for better readability.

Reference case: Simple payment system deployment diagram:

6. System Sequence Diagram

Definition: Describes how system roles cooperate to fulfill a business scenario.

Use case: Combined with system, application, and deployment diagrams.

Drawing tip: Use UML sequence diagrams.

Reference case: Scan‑code payment core scenario sequence diagram:

Supplementary Notes

If you have studied architecture standards, you may also have encountered TOGAF (business, data, application, and technology architecture) or the C4 model (Context, Container, Component, Code). However, industry consensus on a single standard is lacking; TOGAF is typically used at the CTO level, while C4’s expressive power is limited.

Summary

The article presented an overall approach to drawing software system architecture diagrams, listed common diagram types, their application scenarios, and practical drawing tips, and summarized the key points in the final diagram.