3. Architectural Views
Purpose
Section titled “Purpose”This page introduces the architectural views and explains how they relate to each other. Each view is detailed in the sub-pages that follow.
Now that the stakeholders and their concerns are identified (Section 2), the architectural views describe the solution that addresses those concerns. Each view speaks to different stakeholder groups.
View Model
Section titled “View Model”The ADS organises the solution architecture into six complementary views, each addressing a distinct set of stakeholder concerns. This approach is aligned with Kruchten’s 4+1 Architectural View Model, extended with dedicated Data and Security views.
No single view provides a complete picture of the architecture. Together, the views provide a holistic description that can be understood by all stakeholders.
The Views
Section titled “The Views”| # | View | Based On | Primary Stakeholders | Describes | |---|------|----------|---------------------|-----------| | 3.1 | Logical View | 4+1 Logical | Architects, Developers | Application components, services, patterns | | 3.2 | Integration & Data Flow View | 4+1 Process (adapted) | Integrators, Architects | Data flows, integrations, interfaces | | 3.3 | Physical View | 4+1 Physical | Infrastructure, DevOps, Cloud | All deployment infrastructure — physical, virtual, cloud, and serverless | | 3.4 | Data View | RM-ODP Information | Data Architects, DBA, Compliance | Data stores, classification, privacy, lifecycle | | 3.5 | Security View | Extended | Security, CISO, Compliance | IAM, encryption, monitoring, threat model | | 3.6 | Scenarios | 4+1 +1 | All Stakeholders | Use cases, architecture decision records |
Correspondences Between Views
Section titled “Correspondences Between Views”Views are not independent - they share correspondences (relationships between elements across views). Key correspondences include:
- Logical components (3.1) are deployed onto physical infrastructure (3.3)
- Data stores (3.4) are hosted within the physical environment (3.3)
- Integration flows (3.2) traverse network paths defined in the physical view (3.3)
- Security controls (3.5) are applied to components, data, and infrastructure across all views
- Scenarios (3.6) validate the design across all views
When documenting a view, cross-reference related elements in other views to maintain traceability.
Diagram Conventions
Section titled “Diagram Conventions”Each view should include at least one diagram. Follow these conventions:
- Use a consistent notation (e.g., UML, ArchiMate, C4 Model, or simple block diagrams)
- Label all components, connections, and boundaries clearly
- Show trust boundaries in security-relevant diagrams
- Include a legend if notation is not self-evident
- Ensure diagrams are at a resolution that allows text to be read