3.1 Logical View
Purpose
Section titled “Purpose”The Logical View describes the solution’s functional structure - the application components, how they relate to each other, and how they map to business services and capabilities. It addresses the concerns of solution architects and developers.
3.1.1 Application Architecture Diagram
Section titled “3.1.1 Application Architecture Diagram”Provide a block diagram showing the software components used in the solution (applications, middleware, databases, APIs, etc.), how they interact, and how they integrate with external platforms.
[Insert application architecture diagram]
Guidance
The diagram should show:
- All major application components and their roles
- Interactions and data flows between components
- Integration points with external systems
- Clear boundaries between the solution and its environment
- Consider using the C4 Model (a hierarchical approach to diagramming: Context, Container, Component, Code) for progressive detail
3.1.2 Component Decomposition
Section titled “3.1.2 Component Decomposition”Describe each major component of the solution:
| Component | Type | Description | Technology | Owner | |-----------|------|-------------|------------|-------| | [name] | Application / Service / API / Database / Queue / etc. | [what it does] | [technology stack] | [team] |
3.1.3 Service & Capability Mapping
Section titled “3.1.3 Service & Capability Mapping”Mapping components to business capabilities helps identify duplication and ensures the solution aligns with the organisation’s capability model.
Map the solution to business services and capabilities it supports:
| Service ID | Service Name | Capability ID | Capability Name | |-----------|-------------|--------------|----------------| | […] | […] | […] | […] |
3.1.4 Application Impact
Section titled “3.1.4 Application Impact”Tracking impacted applications ensures that downstream teams are informed and that integration testing covers all affected systems.
Identify other applications that are impacted by this solution:
| Application Name | Application ID | Impact Type | Change Details | Comments | |-----------------|---------------|-------------|----------------|----------| | [name] | [id] | Use / Change / Create | [details] | [notes] |
3.1.5 Key Design Patterns
Section titled “3.1.5 Key Design Patterns”Document the architectural and design patterns applied in this solution:
| Pattern | Where Applied | Rationale | |---------|--------------|-----------| | [e.g., Microservices, Event-Driven, CQRS, Strangler Fig] | [which components] | [why this pattern was chosen] |
3.1.6 Technology & Vendor Lock-in Assessment
Section titled “3.1.6 Technology & Vendor Lock-in Assessment”Assess the degree of vendor or technology lock-in for key components:
| Component / Service | Vendor / Technology | Lock-in Level | Mitigation | Portability Notes | |---|---|---|---|---| | [component] | [vendor/technology] | None / Low / Moderate / High / Critical | [how lock-in is mitigated] | [how portable is this component?] |
Guidance
Consider lock-in across multiple dimensions:
- Proprietary APIs — Does the solution use vendor-specific APIs with no open equivalent?
- Data formats — Can data be exported in standard, open formats?
- Contractual — Are there minimum commitment periods or exit penalties?
- Operational — Does the team have skills to operate on an alternative platform?
- Migration effort — How much re-engineering would be needed to move to an alternative?
This assessment should inform the Exit Planning section (5.10) and the Cost Optimisation quality attribute (4.4).
3.1.7 Sustainability Considerations
Section titled “3.1.7 Sustainability Considerations”Component-level decisions influence the carbon profile of the running system. Capture the sustainability-relevant patterns; details and metrics belong in Section 4.5.
| Question | Response | |----------|----------| | Where appropriate, has caching been used to avoid recomputation or repeated downstream calls? | Yes / No — [which components, what’s cached] | | Are batch processes consolidated rather than continuously polling? | Yes / No / Not applicable | | Are async / event-driven patterns used to flatten peak load and right-size compute? | Yes / No — [where] | | Have heavy framework choices been weighed against lighter alternatives where the workload allows? | Yes / No — [discussion] |
Why this matters
The biggest sustainability gains in the Logical View are usually avoiding work rather than doing work efficiently: a cached response, a debounced poll, an event consumed once instead of polled fifty times. These are architectural patterns chosen here, not infrastructure tweaks made later.
Scoring Guidance
| Score | What This Looks Like | |:-----:|---------------------| | 1 | High-level diagram exists but components not decomposed | | 3 | Components documented with technology choices, design patterns justified | | 5 | All of the above plus vendor lock-in assessed, component interactions fully specified, all statuses (new/existing/decommissioned) documented |
Quality Attribute Cross-References:
- 4.3 Performance Efficiency - Component design affects performance characteristics
- 4.2 Reliability - Component decomposition influences fault isolation and resilience
- 4.4 Cost Optimisation - Vendor lock-in affects long-term cost flexibility
- 4.5 Sustainability - Component architecture affects resource utilisation