# Real-Life TOGAF Application Scenario: Digital Customer Onboarding

This realistic composite example shows how a regional bank can use TOGAF to
change a slow, manual customer-onboarding process. The organization is
fictional, but the people, constraints, decisions, and delivery problems are
typical of a regulated transformation.

## The story in simple terms

Northstar Mutual wants customers to open a small-business account in one day
instead of twelve. Buying a new onboarding application looks like the obvious
answer, but software alone will not fix:

- four conflicting customer records;
- different processes in branches and online;
- repeated identity and compliance checks;
- unclear ownership of exceptions;
- missing evidence for automated decisions; and
- old systems that cannot all be replaced at once.

TOGAF helps the bank treat this as one coordinated business change instead of
five disconnected technology projects.

## Scenario

Northstar Mutual takes twelve days to onboard a new small-business customer.
Applicants repeat information across channels, staff re-key data, compliance
checks are mostly manual, and four systems store conflicting customer records.

The board sets an outcome: onboard eligible low-risk customers within one
business day while maintaining regulatory and fraud controls.

## What would happen without TOGAF?

| Local decision | Immediate result | Later problem |
|---|---|---|
| Digital team buys a new form product | A modern form appears quickly | Staff still re-key data into four systems |
| Compliance automates its own checks | Some cases move faster | Channels use different rules and evidence |
| Data team creates another customer database | Reporting becomes easier | A fifth conflicting customer record appears |
| Infrastructure team chooses a workflow platform | Technology is available | No agreed process or accountable process owner |
| Each project creates its own roadmap | Teams look busy | Dependencies collide and benefits arrive late |

The problem is not that the teams are weak. The problem is that each team can
make a locally reasonable decision that produces a poor enterprise result.

## The people doing the work

| Role | Real responsibility in this scenario |
|---|---|
| Executive sponsor: COO | Own the one-day outcome and remove organizational barriers |
| Lead enterprise architect | Keep business, data, application, and technology decisions coherent |
| Business architect | Redesign the onboarding value stream and operating responsibilities |
| Data architect and data owner | Define the customer record, ownership, purpose, retention, and quality |
| Application architect | Define service boundaries and integration responsibilities |
| Technology and security architects | Define platform, resilience, identity, encryption, and operational controls |
| Product manager | Turn transition outcomes into an ordered delivery backlog |
| Compliance and fraud leaders | Own control interpretation and risk acceptance |
| Operations representatives | Design workable exception handling |
| Delivery teams | Build and test solutions within agreed architecture guardrails |

The architects do not replace these people. They connect their decisions and
make trade-offs visible.

## The twelve-week architecture and delivery rhythm

TOGAF does not require the bank to spend months writing documents before
delivery starts.

| Weeks | Architecture focus | Delivery activity | Decision produced |
|---:|---|---|---|
| 1–2 | Preliminary and Phase A | Research current customer and staff journeys | Outcome, scope, principles, stakeholders, and authority |
| 3–4 | Business Architecture | Prototype one guided application journey | Target value stream, capabilities, roles, and business gaps |
| 4–6 | Data and Application Architectures | Test identity provider and orchestration options | Canonical data, ownership, service boundaries, and interfaces |
| 5–7 | Technology Architecture | Prove security, resilience, audit, and platform assumptions | Technology guardrails and quality requirements |
| 7–8 | Opportunities and Solutions | Slice the prototype into deployable increments | Work packages and Transition Architectures |
| 8–9 | Migration Planning | Estimate, fund, sequence, and assign dependencies | Implementation and Migration Plan |
| 9 onward | Implementation Governance | Build, integrate, test, and release increments | Compliance evidence, decisions, and controlled exceptions |
| Continuous | Requirements and Phase H feedback | Measure real customer and operational outcomes | Updated requirements and proportionate architecture change |

Architecture and delivery overlap. Decisions become more detailed only when the
team has enough evidence to make them safely.

## Preliminary Phase

Existing architecture governance is adapted for the transformation:

- the COO sponsors the engagement;
- a cross-domain architecture team is formed;
- risk acceptance remains with the accountable risk executive;
- product teams can decide implementation details within approved guardrails;
- material data, identity, and platform decisions go to the Architecture Board;
- controlled content is stored in the existing documentation and portfolio
  systems.

Relevant principle:

> Capture customer information once, validate it at the source, and reuse it
> only for explicitly governed purposes.

## Phase A: Architecture Vision

### Scope

In scope:

- application through account activation;
- web and assisted channels;
- customer identity and business verification;
- onboarding data and document handling;
- case management and compliance decisioning.

Out of scope:

- marketing acquisition;
- downstream credit products;
- full replacement of the core account platform.

### Stakeholders and concerns

| Stakeholder | Main concern |
|---|---|
| COO | Cycle time and operating cost |
| Compliance executive | Control effectiveness and evidence |
| Customer | Simple, transparent onboarding |
| Operations manager | Exceptions and staff workload |
| Product teams | Feasible increments and ownership |
| Data owner | Customer record quality and permitted use |
| Security | Fraud, identity, privacy, and resilience |

### Measures

- median eligible onboarding time below one business day;
- 60% reduction in manual re-keying;
- no material reduction in control effectiveness;
- 95% of applications show a clear status;
- one accountable golden customer record for onboarding.

## Phase B: Business Architecture

### Baseline findings

- each channel runs a different intake process;
- operations teams duplicate identity and company checks;
- exception ownership is unclear;
- customers cannot see missing actions;
- controls are documented by department rather than value-stream stage.

### Target value stream

```mermaid
flowchart LR
    Apply[Submit application] --> Verify[Verify identity and business]
    Verify --> Assess[Assess eligibility and risk]
    Assess --> Resolve[Resolve exceptions]
    Resolve --> Activate[Activate account]
    Activate --> Welcome[Confirm and onboard]
```

### Capability gaps

| Capability | Baseline | Target | Gap |
|---|---|---|---|
| Digital application | Fragmented forms | Reusable guided intake | Standardized service |
| Identity verification | Manual and repeated | Risk-based automated verification | New integration and policy |
| Case orchestration | Email and queues | End-to-end case state | New capability |
| Customer communication | Inconsistent | Event-driven status updates | Shared notification |
| Control evidence | Department records | Traceable decision evidence | Common evidence model |

## Phase C: Data Architecture

### Target choices

- define a canonical onboarding customer and organization vocabulary;
- name a business owner and stewards for customer identity data;
- establish one authoritative onboarding record while the core platform remains
  the account system of record;
- capture source, consent/purpose, verification status, and lineage;
- apply classification, retention, and deletion rules;
- publish governed data contracts to downstream consumers.

### Data gaps

- conflicting identifiers;
- missing ownership;
- inconsistent field definitions;
- untracked copies of submitted documents;
- no end-to-end lineage for automated decisions.

## Phase C: Application Architecture

### Target services

- onboarding experience;
- application/case orchestration;
- identity and business verification adapter;
- eligibility and risk decision service;
- document service;
- customer master resolution;
- notification service;
- audit/evidence service.

Existing core account and compliance platforms remain but receive clearer
service boundaries.

```mermaid
flowchart LR
    Channels[Web and assisted channels] --> Orchestrator[Onboarding orchestration]
    Orchestrator --> Verify[Verification adapter]
    Orchestrator --> Decision[Eligibility and risk]
    Orchestrator --> Documents[Document service]
    Orchestrator --> Master[Customer resolution]
    Orchestrator --> Core[Core account platform]
    Orchestrator --> Notify[Notification]
    Orchestrator --> Audit[Audit evidence]
```

## Phase D: Technology Architecture

Required platform capabilities:

- managed API and event integration;
- workflow/runtime platform;
- strong customer and workforce identity;
- encryption and managed secrets;
- centralized observability and audit retention;
- resilient multi-zone deployment;
- automated delivery and policy checks.

Key quality requirements:

- no single failure may lose an accepted application;
- all material decisions must be traceable to input and rule/model version;
- sensitive data must be protected in transit and at rest;
- channel status updates must be eventually consistent within two minutes;
- recovery procedures must be exercised, not merely documented.

## Phase E: Opportunities and Solutions

Candidate work packages:

1. common vocabulary, ownership, and controls;
2. onboarding experience and orchestration minimum viable product;
3. verification and decision integration;
4. customer resolution and migration;
5. operational exception workbench;
6. notification and status;
7. control-evidence and observability foundation;
8. retirement of duplicate forms and queues.

## Transition architectures

### Transition 1: Guided intake

One digital form and case identifier, while existing teams still perform manual
verification. Delivers better customer status and removes re-keying.

### Transition 2: Automated low-risk path

Automated verification and eligibility for low-risk cases; exceptions remain
staff-assisted.

### Transition 3: Target operating model

Unified cross-channel service, governed customer record, risk-based automation,
and retirement of duplicate processes.

## Phase F: Migration Planning

| Sequence | Work package | Reason |
|---:|---|---|
| 1 | Vocabulary, ownership, control mapping | Enables consistent design and evidence |
| 2 | Evidence/observability foundation | Reduces risk before automation |
| 3 | Guided intake and orchestration | Early customer and efficiency value |
| 4 | Verification and decision integration | Enables one-day outcome |
| 5 | Exception workbench | Handles non-happy paths safely |
| 6 | Customer resolution and migration | Removes conflicting records |
| 7 | Legacy retirement | Captures savings after adoption |

Funding is released by transition outcome rather than only by component
completion.

## Phase G: Implementation Governance

Automated evidence checks:

- interface contract compatibility;
- sensitive-data classification and encryption;
- audit event completeness;
- approved dependency and platform standards;
- recovery and performance tests.

Human decisions:

- change to control interpretation;
- use of customer data for a new purpose;
- material deviation from customer identity ownership;
- exception to resilience targets;
- new vendor concentration risk.

One delivery team requests a six-month exception to keep an existing document
store. The exception is approved with encryption controls, migration milestones,
an owner, and an expiry date.

## A real delivery conflict

In week ten, the preferred identity-verification supplier reveals that its
standard service stores document images outside the country for 30 days.

The teams have competing concerns:

- product wants to keep the supplier to protect the launch date;
- compliance needs evidence that verification rules are applied;
- privacy requires purpose limitation and approved data location;
- security wants controlled keys, deletion evidence, and incident notification;
- finance wants to avoid a second supplier integration.

TOGAF does not provide a magic answer. It provides a controlled way to decide:

1. Requirements Management records the new data-location fact and traces the
   affected privacy, security, supplier, and schedule requirements.
2. The architects assess impact across Data, Application, Technology, and the
   migration roadmap.
3. Procurement asks the supplier for an in-country processing option and
   deletion evidence.
4. The Architecture Board compares three options using risk, value, time, cost,
   reversibility, and regulatory acceptability.
5. The accountable privacy and risk executives reject the standard service.
6. Transition 1 continues with staff-assisted verification while the in-country
   supplier option is completed.

This decision delays automation but does not delay the whole customer journey.
The Transition Architecture protected early value without silently accepting a
material risk.

## What the first customer experiences

Amira owns a small catering company.

1. She enters company and owner information once on her phone.
2. The bank validates the fields immediately and shows why each item is needed.
3. The orchestration service creates one case identifier.
4. Identity and company checks run using the approved rules.
5. A registry mismatch sends the case to the correct operations queue with the
   evidence already attached.
6. An employee resolves the mismatch without asking Amira to restart.
7. Amira sees the status change and receives a clear request for one missing
   document.
8. The account is activated, and the audit service records which rule versions,
   inputs, and approvals supported the decision.

To Amira, this is one simple journey. Behind it, all four architecture domains
must work together.

## The minimum artifact pack

The team does not produce every possible TOGAF artifact.

| Artifact | Decision it supports |
|---|---|
| One-page Architecture Vision | Why the change matters and what success means |
| Stakeholder map | Who must participate, decide, approve, or receive a view |
| Value-stream and capability map | How work and accountability must change |
| Canonical customer vocabulary | What important data means and who owns it |
| Application interaction diagram | Which service owns each responsibility |
| Technology guardrails | Which security, resilience, and platform rules apply |
| Gap and dependency matrix | What must change and what relies on what |
| Transition roadmap | How value can arrive in safe, coherent stages |
| Architecture Decision Records | Why consequential trade-offs were made |
| Compliance evidence | Whether implementation realizes the approved intent |

Each artifact exists because somebody needs it to make or govern a decision.

## Phase H: Change Management

After two releases:

- median low-risk onboarding time is six hours;
- manual handling falls by 48%, below the 60% target;
- exception volume is higher than expected due to poor external registry data;
- customer status satisfaction improves;
- audit evidence is more complete.

The architecture is updated. A bounded ADM cycle is opened for exception
management and external-data quality; the overall target remains valid.

## Before and after

| Measure | Before | After two releases | Target |
|---|---:|---:|---:|
| Median low-risk onboarding time | 12 days | 6 hours | Under 1 business day |
| Applications manually re-keyed | 82% | 34% | Below 22% |
| Applications with visible status | 18% | 96% | At least 95% |
| Conflicting onboarding customer records | 4 | 1 authoritative onboarding record | 1 |
| Automated decisions with complete evidence | 0% | 98.7% | 100% |
| Exception cases resolved within one day | 41% | 63% | 85% |

The table also prevents false success. The headline speed target is achieved,
but exception performance and manual work still need improvement. Phase H uses
this evidence to choose the next bounded cycle.

## Traceability example

```mermaid
flowchart LR
    Goal[Onboard within one day] --> Req[Automate eligible low-risk decisions]
    Req --> ABB[Risk decision capability]
    ABB --> SBB[Decision service implementation]
    SBB --> WP[Verification and decision work package]
    WP --> Metric[Median onboarding time]
    Metric --> Evidence[Production outcome evidence]
```

## What the example demonstrates

- begin with outcome, not technology;
- model only baseline details relevant to change;
- integrate all four domains;
- use transition states to deliver value safely;
- connect requirements to work and evidence;
- govern exceptions explicitly;
- update architecture from real outcomes.

## Explain the scenario in one minute

Northstar did not use TOGAF to draw more diagrams. It used TOGAF to make one
business outcome govern four connected domains. The bank agreed who decides,
described the relevant current and future states, found the gaps, delivered
through safe transition states, governed a supplier problem, and used production
evidence to decide what to improve next.

[Next: Certification and learning](11-certification-and-learning.html)