Architecture views and controlled interfaces

Use multiple consistent views

One diagram cannot explain purpose, logical responsibilities, deployment, threats, lifecycle, operations, and evidence at the same time. Create a small set of views with consistent component, boundary, flow, and decision identifiers.

Required view set

System context view

Show users, affected parties, external systems, providers, owners, major inputs and outputs, and system scope. It should support intended-purpose review.

Logical responsibility view

Show reference-architecture layers, services, data responsibilities, policy decisions, and major contracts without tying every responsibility to a product.

Trust and data-flow view

Use the trust-boundary method. Number flows and show identities, data or artifact types, and policy points.

Deployment view

Show runtime environments, clusters or hosts, networks, storage, accelerators, control planes, administrative paths, keys, external services, and recovery locations.

Supply-chain and lifecycle view

Show how code, containers, packages, models, prompts, policies, evaluation data, and manifests move from source through verification, approval, promotion, deployment, update, rollback, and retirement.

Operations and evidence view

Show telemetry, evaluation, policy events, evidence stores, integrity controls, alerting, incident response, backup, restore, reporting, and review ownership.

Define controlled interfaces

For each material interface, record:

Interface and flow ID:
Source, destination, and owning teams:
Initiating and delegated identity:
Data, artifact, or command contract:
Classification and allowed purpose:
Authentication and authorization:
Validation and policy decisions:
Timeout, retry, rejection, and degraded behavior:
Versioning and compatibility:
Telemetry and evidence:

An interface is not controlled if a parallel administrative, diagnostic, batch, or emergency path bypasses the declared policy.

Maintain consistency

Use the same names and IDs across diagrams, ADRs, threat scenarios, control objectives, tests, evidence maps, and backlog items. When a component is decomposed in one view, preserve its connection to the higher-level element.

Review questions

• Can each requirement be traced to a component, interface, decision, or control?
• Are all external dependencies and administrative paths visible?
• Do failure and recovery paths appear, not only the success path?
• Can the deployed topology be connected to the approved logical design?
• Does evidence identify the relevant architecture and release version?