6.1 Why Multiple Views?

A software system is too complex to capture in a single diagram. Trying to show everything at once — components, data flows, deployment nodes, interactions — creates an incomprehensible mess. The solution is multiple views, each showing the system from a different perspective.

Think of it like an architect designing a building. They don't create one drawing — they create floor plans, electrical diagrams, plumbing layouts, and structural engineering drawings. Each view shows the same building but highlights different concerns for different audiences. The building hasn't changed — only the lens through which you look at it.

This is not just a documentation trick. Views help architects think clearly. When you draw the deployment view, you're forced to think about infrastructure, networks, and operations. When you draw the runtime view, you're forced to think about timing, concurrency, and failure modes. Each view surfaces different risks and design decisions.

6.2 Kruchten's 4+1 View Model

Philippe Kruchten's 4+1 model (1995) is the most widely cited view model. It defines four structural views plus one that ties them together:

6.3 The Four Core iSAQB Views

The iSAQB curriculum focuses on four essential views that every architect should be able to create and explain. These are not just academic artifacts — they are practical tools that help you communicate with different audiences.

Context View

Shows the system as a black box within its environment. It answers: "What are the external actors, systems, and interfaces that our system interacts with?" This is typically the first view you create — and often the most important for stakeholder communication.

The context view forces you to define the system boundary: what is "inside" (what you build) and what is "outside" (what you integrate with). This seemingly simple distinction is often the source of heated debates and misunderstandings in projects.

Building Block View

Shows the static decomposition of the system into its building blocks and their relationships. This is the most important structural view — it answers "what is the system made of?"

Building block views are typically organized as a hierarchy of levels:

• Level 0: The context view (system as a whole)
• Level 1: Top-level decomposition — the major building blocks
• Level 2: Decomposition of individual Level 1 blocks
• Level 3+: Further refinement (only for complex or critical areas)

For each building block, document: Name, Responsibility (what it does and why), Interfaces (provided and required), Quality considerations (performance hotspot? security-critical?), and Open issues/risks.

Runtime View

Shows dynamic behavior — how building blocks interact at runtime for important scenarios. While the building block view is static (like a photograph), the runtime view is dynamic (like a video). It answers: "How do the parts work together when this scenario executes?"

Typically uses sequence diagrams or activity diagrams. Focus on the most important scenarios:

• Happy paths — The most common and business-critical flows
• Error scenarios — What happens when a downstream service fails?
• Concurrency — Where do race conditions or deadlocks lurk?
• Performance-critical paths — The hot paths that need optimization

Deployment View

Shows the physical infrastructure — nodes, networks, and how building blocks are mapped to them. Answers: "Where does each component run? How do they communicate over the network? What hardware/cloud resources are needed?"

This view is critical for operations, capacity planning, cost estimation, and security (network segmentation). In the cloud era, it often maps to infrastructure-as-code configurations.

Key information to include in a deployment view:

Summary