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 4+1 model is useful because it separates those concerns:

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 - the use cases that prove the views line up

The "+1" matters. Scenarios are where pretty architecture meets messy reality.

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. They are not just user stories. For security, they should include misuse and failure cases.

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.

How I Use 4+1 In Reviews

I do not try to document every system perfectly. I start with the highest-risk workflow and build just 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

Why It Helps

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.

Use 4+1 when the system is important enough that one view is not enough.