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?

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

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.

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

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

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

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.

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

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.

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

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

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