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.
Document control
| 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
| 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
[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
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
| 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
The current onboarding process spans three systems and manual steps.
| 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
In the target state, applicants complete onboarding online; verification
and account creation are automated and orchestrated.
[Narrative: key capabilities, what is automated, where people remain in
the loop and why.]
6. Gap analysis
| 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
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
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
| 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
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
| 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
| 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
| 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
| 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
| 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: CTCO=Ccapex+5×Copex = EUR 2.56 million.
16. Roadmap and transition states
| 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 |
17. Architecture decisions
| 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
| 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.