Architecture views and controlled interfaces
Use context, logical, deployment, trust, lifecycle, operational, and evidence views with consistent identifiers and contracts.
Before you start
Module prerequisites: SAI-100, SAI-110. Check the exercise-specific tools and environment before running commands.
Module outcomes: Select an appropriate deployment pattern; Document portability and concentration decisions; Place assurance points across the lifecycle. This lesson contributes to that sequence.
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?
Module worked example
The logical diagram shows a gateway, but the deployment view exposes a second model endpoint.
- Apply the control
- Draw the alternate route and close or govern it before accepting the architecture decision.
- Expected result
- Context, deployment and control views agree about reachable paths and owners.
- Troubleshooting
- Compare diagrams using the same actors, interfaces and resource identifiers; inconsistent names can hide a bypass.
Practice and completion check
Choose one control from this lesson. Identify its actor, target, enforcement point and expected result. Describe an allowed case and a denied or failed case. For a runnable exercise, retain observed output and separate it from expected output. Record unresolved limitations before marking the lesson complete.
Your lesson progress
Completion is self-reported learning progress; it does not certify practical competence.
Status: Not marked
Loading your learning record…