Calab.ai Handbook

Graph View

04 Architectural Impact Assessment as PAD-SDD Bridge

3 min read

Edit this page

Decision 04: Architectural Impact Assessment as PAD-SDD Bridge

Status

Accepted

Date

2026-02-18

Context

Separating platform-level concerns (PAD) from use-case-specific concerns (SDD) creates a boundary management problem: how do new use cases communicate their impact on the platform? Without a formal mechanism, platform changes introduced by individual use cases may go unreviewed, untracked, or undocumented — leading to configuration drift between the PAD (what we think the platform looks like) and reality (what it actually looks like after multiple use cases have been deployed).

Decision

Include an Architectural Impact Assessment (AIA) section (§5) in every SDD. The AIA is a structured assessment that documents:

  1. Component Impact Assessment (§5.1) — Impact of the use case on each platform component (EXISTING / CHANGE / NEW / DECOMMISSIONED), aligned with the PAD’s Solution Technologies table
  2. Impacts to Platform Architecture Views (§5.2) — A checklist-style summary of impact to each PAD view (Integration, Infrastructure, Information, Security, Support, Monitoring, Capacity)
  3. Use Case Integration Interfaces (§5.3) — Specific integration interfaces required, referencing PAD standard interfaces
  4. Use Case NFRs (§5.4) — Deviations from or additions to PAD baseline NFRs
  5. Use Case Technology Choices (§5.5) — New technologies not yet in the PAD inventory
  6. Architecture Decision Records (§5.6) — Use-case-specific decisions, with promotion path to PAD
  7. Solution Design Risks (§5.7) — Technical risks specific to this solution
  8. Technical Debt (§5.8) — Debt introduced by this use case
  9. Test Strategy (§5.9) — Testing approach for this use case
  10. Deployment and Cutover (§5.10) — Use-case-specific deployment considerations

When an AIA is approved, the PAD must be updated:

  • Solution Technologies table (PAD §3.3.2) updated with CHANGE/NEW items and the use case’s ID
  • Use Case Register (PAD §4) updated with the new use case entry
  • Any other impacted PAD sections updated as identified in the Impacts to Platform Architecture Views table

Rationale

  • Traceability: Every platform change can be traced to the use case that introduced it via the ‘Source UC’ column in the PAD’s Solution Technologies table
  • Review discipline: IT stakeholders can review the AIA to understand what a new use case will change before approving it
  • Living documentation: The PAD evolves as use cases are onboarded, rather than becoming stale
  • Separation of concerns: The SDD documents what changes it needs; the PAD reflects the cumulative state of the platform

Consequences

  • There is a maintenance obligation: when an AIA is approved, someone must update the PAD accordingly
  • The PAD’s Use Case Register serves as the definitive list of what’s running on the platform
  • Platform-wide decisions that emerge from use-case-specific work should be promoted from SDD decisions to PAD decisions
  • The AIA section (§5) is the largest section in the SDD template — this reflects its importance as the bridge between documents

Graph View

Graph View