# Solution Architecture Document: [Solution name]

> Enterprise solution architecture document for one business initiative:
> drivers, current and target state, gaps, the business, application,
> data and technology architecture of the solution, integration and
> security, compliance with non-functional requirements and architecture
> principles, risks, cost, roadmap and governance approval. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write sections 1 to 4 with the business sponsor before designing. A
  solution that cannot be traced to a business driver is hard to defend at
  the architecture board.
- Describe current and target state at the same level of detail, then
  derive the gaps. Every gap becomes a work package in the roadmap.
- Sections 12 and 13 (NFR and principles compliance) are what governance
  boards read first. Be honest about partial compliance and request
  waivers explicitly.
- Keep detailed component design out of this document; link to the
  relevant design documents instead.
-->

## Document control

<!-- Guidance: Identify the document, the initiative it supports and its approval status at the architecture board. -->

| Field | Value |
|---|---|
| Document ID | [SAD-PRJ-001] |
| Solution / initiative | [Solution name] |
| Programme or project code | [PRJ-0000] |
| Version | [0.1] |
| Status | [Draft / Submitted to board / Approved / Approved with conditions / Rejected] |
| Solution architect | [@architect] |
| Business sponsor | [@sponsor] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Conditions | Date |
|---|---|---|---|---|
| Architecture review board | [Chair @name] | [Approved / Approved with conditions / Rejected] | [Conditions] | YYYY-MM-DD |
| Enterprise architect | [@name] | [Decision] | [Conditions] | YYYY-MM-DD |
| Security architect | [@name] | [Decision] | [Conditions] | YYYY-MM-DD |
| Data protection officer | [@name] | [Decision] | [Conditions] | YYYY-MM-DD |
| Business sponsor | [@name] | [Decision] | [Conditions] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record changes requested by governance bodies with a reference to their minutes. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Business context, current state, initial options |
| 0.5 | YYYY-MM-DD | [@name] | *Example:* Target state and gap analysis; submitted to pre-board review |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved with conditions C1 and C2 (board minutes ARB-2026-14) |

## Contents

1. [Executive summary](#1-executive-summary)
2. [Business context and drivers](#2-business-context-and-drivers)
3. [Scope](#3-scope)
4. [Current state](#4-current-state)
5. [Target state](#5-target-state)
6. [Gap analysis](#6-gap-analysis)
7. [Solution overview](#7-solution-overview)
8. [Business and application architecture](#8-business-and-application-architecture)
9. [Data architecture](#9-data-architecture)
10. [Technology architecture and integration](#10-technology-architecture-and-integration)
11. [Security architecture](#11-security-architecture)
12. [Non-functional requirements compliance](#12-non-functional-requirements-compliance)
13. [Architecture principles compliance](#13-architecture-principles-compliance)
14. [Risks, assumptions, issues and dependencies](#14-risks-assumptions-issues-and-dependencies)
15. [Costs](#15-costs)
16. [Roadmap and transition states](#16-roadmap-and-transition-states)
17. [Architecture decisions](#17-architecture-decisions)
18. [Governance and approvals](#18-governance-and-approvals)

## 1. Executive summary

<!-- Guidance: Half a page for decision makers: the problem, the proposed solution, cost, timeline, key risks and the decision requested. -->

[Example: "Customer onboarding takes 9 days on average and requires five
manual hand-offs between three legacy systems. This document proposes a
digital onboarding solution built on the existing CRM platform, a new
identity verification service and an integration layer, delivered in three
transition states over 12 months for an estimated capital cost of
EUR 1.4 million. The board is asked to approve the target architecture and
the waiver for principle P-07 until transition state 2."]

## 2. Business context and drivers

<!-- Guidance: Why the organisation is doing this. Link drivers to strategy and to measurable outcomes so the solution can be judged against them. -->

### 2.1 Business drivers

| ID | Driver | Source | Measurable outcome |
|---|---|---|---|
| BD-01 | *Example:* Reduce customer onboarding time | Corporate strategy YYYY | From 9 days to under 1 day for 80% of applicants |
| BD-02 | *Example:* Comply with updated anti-money-laundering rules | Regulator | Electronic identity verification for all new customers by YYYY-MM-DD |
| BD-03 | *Example:* Lower operating cost | Finance | 40% fewer manual onboarding tasks |
| [BD-nn] | [Driver] | [Source] | [Outcome] |

### 2.2 Stakeholders

| Stakeholder | Interest | Influence |
|---|---|---|
| *Example:* Head of retail banking (sponsor) | Faster onboarding, revenue | High |
| *Example:* Compliance | Regulatory conformity | High |
| *Example:* Operations | Fewer manual tasks | Medium |
| [Stakeholder] | [Interest] | [High / Medium / Low] |

## 3. Scope

<!-- Guidance: Make the boundary explicit in organisational, functional and technical terms. Most disputes at review start with an unclear scope. -->

| Dimension | In scope | Out of scope |
|---|---|---|
| Business units | *Example:* Retail banking, all EU markets | Corporate banking |
| Processes | *Example:* Application, identity verification, account opening | Credit decisioning |
| Channels | *Example:* Web, mobile app | Branch, call centre (phase 2) |
| Systems | *Example:* CRM, core banking interfaces, new verification service | Core banking replacement |
| [Dimension] | [In scope] | [Out of scope] |

## 4. Current state

<!-- Guidance: Describe today's architecture at the level needed to understand the gaps. Include pain points with evidence. -->

The current onboarding process spans three systems and manual steps.

```mermaid
flowchart LR
  app([Applicant]) -->|PDF form by email| ops[Back-office team]
  ops -->|manual entry| crm[CRM]
  ops -->|manual check| kyc[Identity check portal]
  ops -->|manual entry| core[(Core banking)]
```

| Pain point | Evidence | Driver affected |
|---|---|---|
| *Example:* Re-keying data in three systems | 22 minutes average handling per application | BD-01, BD-03 |
| *Example:* Identity checks not recorded electronically | Audit finding AF-2025-07 | BD-02 |
| [Pain point] | [Evidence] | [BD-nn] |

## 5. Target state

<!-- Guidance: Describe the end state the organisation is moving to, not only this project's increment. Transition states come in section 16. -->

In the target state, applicants complete onboarding online; verification
and account creation are automated and orchestrated.

```mermaid
flowchart LR
  app([Applicant]) --> portal[Onboarding portal]
  portal --> orch[Onboarding orchestration]
  orch --> idv[Identity verification service]
  orch --> crm[CRM]
  orch --> int[Integration layer]
  int --> core[(Core banking)]
  orch --> case[Case management for exceptions]
```

[Narrative: key capabilities, what is automated, where people remain in
the loop and why.]

## 6. Gap analysis

<!-- Guidance: For each architecture domain, state what must be added, changed or retired to move from current to target. Each gap maps to a roadmap work package. -->

| ID | Domain | Current | Target | Gap | Action | Work package |
|---|---|---|---|---|---|---|
| GAP-01 | Business | Manual review of every application | Exceptions only | Exception rules not defined | Define rules with Compliance | WP-1 |
| GAP-02 | Application | No orchestration capability | Orchestrated onboarding | New capability | Build on CRM workflow | WP-2 |
| GAP-03 | Data | Customer data duplicated in three systems | CRM as customer master | Master data ownership | Data migration, sync rules | WP-3 |
| GAP-04 | Technology | Point-to-point file transfers | API-based integration layer | Integration platform missing | Extend enterprise API gateway | WP-2 |
| [GAP-nn] | [Domain] | [Current] | [Target] | [Gap] | [Action] | [WP-n] |

## 7. Solution overview

<!-- Guidance: A one-page view of the proposed solution and the options that were considered. -->

### 7.1 Options considered

| Option | Description | Fit to drivers | Cost (5 years) | Risk | Recommendation |
|---|---|---|---|---|---|
| A | *Example:* Extend existing CRM with workflow and a verification service | High | EUR 2.1 M | Medium | Recommended |
| B | *Example:* Buy a specialist onboarding platform | High | EUR 3.4 M | Medium (vendor lock-in) | Not recommended |
| C | *Example:* Improve manual process only | Low | EUR 0.4 M | Low | Not recommended (fails BD-02) |

### 7.2 Solution summary

[Describe option A in one or two paragraphs: main building blocks,
reuse of existing platforms, new components, and how it meets each
business driver.]

## 8. Business and application architecture

<!-- Guidance: Show the business processes and capabilities affected, then the applications that realise them and how responsibilities move. -->

### 8.1 Business architecture

| Capability / process | Change | Business owner | Users affected |
|---|---|---|---|
| *Example:* Customer onboarding | Redesigned as digital self-service with exception handling | Head of retail operations | 120 back-office staff, all new customers |
| *Example:* Identity verification | Automated document and liveness check | Compliance | Compliance analysts |
| [Capability] | [Change] | [Owner] | [Users] |

### 8.2 Application architecture

| Application | Status | Role in solution | Owner | Lifecycle |
|---|---|---|---|---|
| *Example:* CRM | Existing, extended | Customer master, orchestration | CRM platform team | Strategic |
| *Example:* Identity verification service | New (SaaS) | Document and liveness checks | Compliance IT | Strategic |
| *Example:* Identity check portal | Existing | Replaced | Compliance IT | Retire by TS-2 |
| [Application] | [New / Extended / Unchanged / Retired] | [Role] | [Team] | [Strategic / Tactical / Retire] |

## 9. Data architecture

<!-- Guidance: Data entities, master sources, flows, classification, residency and retention. Regulators and data protection officers read this section closely. -->

| Data entity | Master system | Consumers | Classification | Personal data | Residency | Retention |
|---|---|---|---|---|---|---|
| *Example:* Customer | CRM | Core banking, orchestration | Confidential | Yes | EU | 10 years after relationship ends |
| *Example:* Identity evidence | Verification service | CRM (result only) | Restricted | Yes (special) | EU | 5 years per AML rules |
| [Entity] | [System] | [Systems] | [Class] | [Yes / No] | [Region] | [Period] |

Data migration: [volumes, approach, reconciliation, cut-over].

## 10. Technology architecture and integration

<!-- Guidance: Hosting, platforms and the integration design. Reuse enterprise standards and say where you deviate. -->

### 10.1 Technology platforms

| Component | Platform | Hosting | Standard or deviation |
|---|---|---|---|
| *Example:* Onboarding portal | Corporate web framework | Private cloud EU | Standard |
| *Example:* Verification service | Vendor SaaS | Vendor EU region | Deviation: new SaaS vendor, see DEC-03 |
| [Component] | [Platform] | [Hosting] | [Standard / deviation] |

### 10.2 Integration

| ID | Source | Target | Pattern | Protocol | Frequency / volume | Error handling |
|---|---|---|---|---|---|---|
| INT-01 | *Example:* Orchestration | Verification service | Request-response | REST over HTTPS, mutual TLS | 3,000 per day | Retry 3 times, then manual case |
| INT-02 | *Example:* CRM | Core banking | Event-driven via integration layer | Messaging | 3,000 per day | Dead-letter queue, alert |
| [INT-nn] | [Source] | [Target] | [Pattern] | [Protocol] | [Volume] | [Handling] |

## 11. Security architecture

<!-- Guidance: Identity, access, data protection, network, monitoring and the threats specific to this solution. Link the threat model. -->

| Area | Control | Requirement source | Status |
|---|---|---|---|
| *Example:* Customer authentication | Strong customer authentication via corporate identity provider | Security policy SP-04 | Designed |
| *Example:* Data protection | Encryption at rest with customer-managed keys; field-level encryption of identity numbers | Data classification standard | Designed |
| *Example:* Third-party risk | Vendor security assessment of verification provider | Supplier policy | In progress |
| *Example:* Monitoring | Security events to the corporate SIEM | Logging standard | Designed |
| [Area] | [Control] | [Source] | [Status] |

Threat model reference: [link]. Residual risks accepted: [list with owner].

## 12. Non-functional requirements compliance

<!-- Guidance: State each NFR, how the solution meets it, and whether it complies. Partial compliance needs a plan or a waiver. -->

| ID | Category | Requirement | Solution response | Compliance |
|---|---|---|---|---|
| NFR-01 | Availability | *Example:* 99.9% during 06:00 to 24:00 | Active-active portal, SaaS SLA 99.95% | Compliant |
| NFR-02 | Performance | *Example:* Verification result within 60 s for 95% | Vendor benchmark 35 s p95 | Compliant |
| NFR-03 | Recovery | *Example:* RTO 4 h, RPO 15 min | CRM backup meets RPO; orchestration state replayable | Compliant |
| NFR-04 | Accessibility | *Example:* WCAG 2.2 AA | Portal compliant; vendor widget not yet tested | Partial: test by TS-1 |
| [NFR-nn] | [Category] | [Requirement] | [Response] | [Compliant / Partial / Non-compliant] |

## 13. Architecture principles compliance

<!-- Guidance: Assess the solution against each enterprise principle. Non-compliance is acceptable only with a justified waiver and an end date. -->

| Principle | Assessment | Compliance | Waiver |
|---|---|---|---|
| *Example:* P-01 Reuse before buy before build | Reuses CRM and API gateway; buys verification | Compliant | n/a |
| *Example:* P-04 Single master per data entity | CRM is customer master | Compliant | n/a |
| *Example:* P-07 No point-to-point integration | Interim file transfer to core banking until TS-2 | Non-compliant | WVR-12, expires YYYY-MM-DD |
| [Principle] | [Assessment] | [Compliance] | [Waiver ID] |

## 14. Risks, assumptions, issues and dependencies

<!-- Guidance: Keep one RAID register for architecture items. Each item has an owner and a next action. -->

| ID | Type | Description | Impact | Likelihood | Owner | Response |
|---|---|---|---|---|---|---|
| R-01 | Risk | *Example:* Verification vendor fails EU data residency audit | High | Low | @security | Contract clause; fallback vendor shortlisted |
| A-01 | Assumption | *Example:* CRM upgrade to version [x] completes before TS-1 | High | n/a | @crm-lead | Confirm at monthly checkpoint |
| I-01 | Issue | *Example:* Core banking API capacity not confirmed | Medium | n/a | @core-lead | Load test scheduled |
| D-01 | Dependency | *Example:* Enterprise API gateway extension | High | n/a | @platform | Tracked in platform roadmap |
| [ID] | [R / A / I / D] | [Description] | [H / M / L] | [H / M / L / n/a] | [@owner] | [Response] |

## 15. Costs

<!-- Guidance: Capital and operating costs over the evaluation period, with assumptions. Finance will reconcile this with the business case. -->

| Cost item | Year 0 (capex) | Annual run cost (opex) | Assumption |
|---|---|---|---|
| *Example:* Verification SaaS licences | EUR 50,000 setup | EUR 180,000 | 36,000 checks per year at EUR 5 |
| *Example:* Delivery team | EUR 1,100,000 | 0 | 8 FTE for 12 months |
| *Example:* Platform and hosting | EUR 60,000 | EUR 90,000 | Corporate rate card |
| **Total** | **EUR 1,210,000** | **EUR 270,000** | |

Total cost of ownership over five years: $C_{TCO} = C_{capex} + 5 \times C_{opex}$ = EUR 2.56 million.

## 16. Roadmap and transition states

<!-- Guidance: Show how the organisation moves from current to target state in stable, valuable steps. Each transition state should be operable on its own. -->

| Transition state | Date | Capabilities delivered | Gaps closed | Retired |
|---|---|---|---|---|
| TS-1 | YYYY-MM | Online application, automated verification, manual account creation | GAP-01, GAP-02 (part) | Email PDF forms |
| TS-2 | YYYY-MM | Automated account creation via integration layer | GAP-02, GAP-04 | Identity check portal, file transfer |
| Target | YYYY-MM | Full self-service, exceptions only | GAP-03 | Duplicate customer stores |

```mermaid
gantt
  title Solution roadmap
  dateFormat YYYY-MM-DD
  section Work packages
  WP-1 Exception rules      :wp1, 2026-01-05, 60d
  WP-2 Orchestration and integration :wp2, 2026-02-01, 180d
  WP-3 Data migration       :wp3, after wp2, 90d
  section Milestones
  TS-1 live                 :milestone, 2026-05-01, 0d
  TS-2 live                 :milestone, 2026-08-01, 0d
```

## 17. Architecture decisions

<!-- Guidance: Summarise the significant decisions and link their records. -->

| ID | Decision | Rationale | Status |
|---|---|---|---|
| DEC-01 | *Example:* Use CRM workflow for orchestration | Reuse, skills available, lower cost than a new BPM suite | Accepted |
| DEC-02 | *Example:* Event-driven integration with core banking | Decouples release cycles, aligns with P-07 | Accepted |
| DEC-03 | *Example:* SaaS verification vendor in EU region | Time to market, certified liveness detection | Accepted with condition C2 |
| [DEC-nn] | [Decision] | [Rationale] | [Status] |

## 18. Governance and approvals

<!-- Guidance: Record the review path, board conditions and how compliance will be checked during delivery. -->

| Checkpoint | Body | Date | Outcome | Conditions |
|---|---|---|---|---|
| Concept review | Architecture review board | YYYY-MM-DD | *Example:* Proceed to detailed design | Provide data residency evidence |
| Design approval | Architecture review board | YYYY-MM-DD | [Outcome] | [Conditions] |
| Pre-go-live compliance check | Enterprise architecture | YYYY-MM-DD | [Outcome] | [Conditions] |

| Condition | Owner | Due | Status |
|---|---|---|---|
| *Example:* C1 Accessibility test of vendor widget | @ux-lead | YYYY-MM-DD | Open |
| *Example:* C2 Vendor residency evidence | @security | YYYY-MM-DD | Closed |
| [Condition] | [@owner] | YYYY-MM-DD | [Open / Closed] |

## Standard and licence note

Based on common industry practice for enterprise solution architecture
documents: business drivers, current and target state, gap analysis,
domain architectures, compliance assessment, transition planning and
governance. This template is original text written for this collection
and reproduces no text from TOGAF or any other framework. Template
licence: MIT.