4+1 Architecture Views For Security Reviews

One architecture diagram cannot do every job.

Executives need scope and risk. Developers need module boundaries. Operators need deployment and runtime behavior. Security teams need all of those, plus enough detail to see where trust is granted and where evidence is produced.

Philippe Kruchten's 1995 paper on the 4+1 view model separates the architecture into concurrent views and uses scenarios to connect them. The security questions below are my application of that model:

1. Logical view - what the system does
2. Development view - how the software is organized
3. Process view - how it behaves at runtime
4. Physical view - where it runs
5. Scenarios - use cases that help check whether the views line up

The scenario matters because it lets the team follow one operation across views. A consistent drawing is useful, but it still needs implementation and runtime checks.

Logical View: Security Requirements

The logical view describes capabilities and business concepts. For security, I use it to capture:

• user roles
• protected data types
• authorization rules
• audit requirements
• privacy and retention expectations

Example:

[Identity] --> [Access Control] --> [Business Action]
     |                |                    |
     v                v                    v
[User Store]     [Policy Store]       [Audit Event]

The useful question is simple: what security decision is the system supposed to make before the business action happens?

Development View: Where The Code Lives

The development view shows modules, libraries, packages, and dependencies.

Security questions here are different:

• Is auth code duplicated across services?
• Are crypto utilities isolated and reviewed?
• Can business modules bypass policy checks?
• Which third-party libraries sit on sensitive paths?
• Where do secrets enter the application?

This view helps prevent "security by convention," where every team is expected to remember the right pattern manually.

Process View: Runtime Behavior

The process view shows what happens when the system is running:

• concurrent processes
• queues
• retries
• timeouts
• background jobs
• event flows

Security problems often live here. A design may look safe statically but fail under retry, race, queue replay, or timeout behavior.

For example:

[Login Event] --> [Risk Scoring] --> [Policy Decision] --> [Session Issued]
      |                 |                   |                    |
      v                 v                   v                    v
 [Event Log]       [Device Signal]      [Audit Log]         [Session Store]

Questions to ask:

• What happens if risk scoring times out?
• Are denied actions logged?
• Can stale device posture still issue a session?
• Is the policy decision replayable after an incident?

Physical View: Deployment And Exposure

The physical view maps software to infrastructure:

• networks and zones
• cloud accounts
• regions
• hosts
• firewalls
• identity boundaries
• backup paths

This is where a lot of security diagrams finally become honest. If the database is reachable from three places, draw all three. If a management plane is reachable from a VPN, show it. If logs leave the environment, show the processor.

Example:

[Internet]
    |
    v
[Edge / WAF] --> [App Subnet] --> [Data Subnet]
                      |
                      v
                [Logging Account]

The physical view should make blast radius easier to reason about.

Scenarios: The Reality Check

Scenarios connect the four views. For a security review, include misuse and failure cases alongside intended user workflows.

Good scenarios:

• privileged user performs an admin action
• vendor access is granted and later revoked
• customer data export is requested
• suspicious login is blocked
• production secret is rotated
• incident responder isolates a compromised host

Walk the scenario through each view:

• logical: what rule applies?
• development: which module enforces it?
• process: what happens at runtime?
• physical: where does it run and what can it reach?

If the answers disagree, the architecture is not understood.

Applying 4+1 In A Review

I would start with the highest-risk workflow and build enough view coverage to answer the review questions.

For a payment system, that might mean:

• logical view for payment states and authorization
• development view for payment, fraud, and audit modules
• process view for checkout, retry, and refund flows
• physical view for PCI boundary and data stores
• scenarios for charge, refund, dispute, and failed authorization

That is more useful than a complete diagram nobody reads.

Common Mistakes

• treating the views as paperwork instead of review tools
• creating views that cannot be tied to a real scenario
• ignoring process behavior because static diagrams are easier
• hiding infrastructure complexity behind a single cloud icon
• failing to update scenarios after incidents

Maintaining The Views

The model forces different kinds of questions:

• What should the system do?
• Where is the security logic?
• How does it behave under pressure?
• Where is it exposed?
• Can we prove the story with a scenario?

Security reviews get better when those questions are separated. Otherwise every diagram turns into a crowded box of arrows and nobody trusts it.

For the next review, choose a scenario with a failure path, such as a refund retried after a timeout. Record which view explains idempotency, which module enforces it, and which runtime artifact confirms the result. A gap there gives the team a specific correction to make.