When to use
- APIs, source systems, data movement, sync, reconciliation, or failure handling are central.
- The user experience depends on reliable data exchange across boundaries.
When not to use
- The work is only a front-end or workflow change with no dependency risk.
- The central uncertainty is product adoption, market fit, or operational behavior.
Start with
- Map systems, source-of-truth ownership, data movement, and trigger points.
- Document failure states, retries, reconciliation, and manual fallback expectations.
- Review feasibility with technical owners before defining delivery scope.
Build integration confidence from source of truth to sign-off.
Phase 1 — Data architecture
Establish authoritative ownership and map the contract between source and target systems.
I.1Playbook stepSSOT Mapping
Map the single source of truth for every data entity in scope.
Key output: SSOT Matrix
SSOT Mapping
Map the single source of truth for every data entity in scope.
Key output: SSOT Matrix
I.2Playbook stepAPI & Payload Mapping
Map JSON or XML payloads and create the field-level translation contract.
Key output: Data Dictionary
Depends on: I.1 SSOT Matrix completed
API & Payload Mapping
Map JSON or XML payloads and create the field-level translation contract.
Key output: Data Dictionary
Depends on: I.1 SSOT Matrix completed
Phase 2 — Non-functional requirements
Define sync mode, latency, capacity, rate limits, and acceptable lag from business need.
I.3Playbook stepThroughput & SLA Definition
Define sync mode, latency SLA, volume expectations, and acceptable data lag.
Key output: NFR Specification
Depends on: I.2 Data Dictionary
Throughput & SLA Definition
Define sync mode, latency SLA, volume expectations, and acceptable data lag.
Key output: NFR Specification
Depends on: I.2 Data Dictionary
Phase 3 — Failure design
Specify retry, dead-letter, alert, fallback, partial-success, and recovery behavior.
I.4Playbook stepFailure & Retry Logic
Map every unhappy path, retry rule, fallback process, and alert threshold.
Key output: Error Handling Rules
Depends on: I.3 NFR Specification
Failure & Retry Logic
Map every unhappy path, retry rule, fallback process, and alert threshold.
Key output: Error Handling Rules
Depends on: I.3 NFR Specification
Phase 4 — Financial integrity
Define reconciliation checks, tolerance, discrepancy resolution, ownership, and audit evidence.
I.5Playbook stepReconciliation Design
Design how financial discrepancies are detected, investigated, corrected, and audited.
Key output: Reconciliation Logic
Depends on: I.4 Error Handling Rules
Reconciliation Design
Design how financial discrepancies are detected, investigated, corrected, and audited.
Key output: Reconciliation Logic
Depends on: I.4 Error Handling Rules
Phase 5 — Sign-off
Package the architecture and secure formal technical, security, and financial approval.
I.6Playbook stepArchitecture & Audit Sign-off
Package the design and secure Architecture, InfoSec, and financial approval before development.
Key output: Architecture Sign-off
Depends on: I.5 Reconciliation Logic
Architecture & Audit Sign-off
Package the design and secure Architecture, InfoSec, and financial approval before development.
Key output: Architecture Sign-off
Depends on: I.5 Reconciliation Logic
Design the data contract, failure behavior, and audit trail before development.
Use the Standard or Deep route when integration behavior creates material operational, financial, security, or data-integrity risk.
Who uses it
Tech Leads, Architects, BAs, system owners, InfoSec, Operations, and Finance or Audit when financial data is involved.
When to use it
Use when APIs, source-of-truth boundaries, transformation, sync behavior, failure handling, or reconciliation drive the delivery risk.
What it produces
An SSOT matrix, data dictionary, NFR specification, error-handling rules, reconciliation logic, and architecture sign-off.
How to use it
Complete every step in order. Resolve ownership and field mapping before selecting sync behavior, then design failure and audit controls.
Capture this project context.
Initiative name and discovery routeBusiness ownerTech Lead or ArchitectBA / PM ownerTarget start dateSystems involvedWhether financial data is involvedSME availability and areaIntegration summary: what moves, between which systems, and why
Resolve ownership first
Do not begin field mapping while two systems still claim authority over the same entity.
Design the unhappy path
Timeouts, partial success, rate limits, dead-letter handling, fallback, and recovery ownership are first-class requirements.
Keep the evidence reviewable
Financial integrity, security controls, immutable transaction logging, and rollback behavior must be explicit before sprint start.
Discovery is complete when all are true.
- SSOT is designated for every data entity with no unresolved conflict.
- Field-by-field mapping is complete with transformation rules.
- Sync architecture and latency SLAs are business-approved.
- Every failure scenario has a defined handling rule.
- Dead-letter queue and alert routing are designed.
- Manual fallback process is documented.
- Reconciliation logic and thresholds are Finance-approved.
- InfoSec and the Architect have signed off.
A signed-off integration architecture that defines authoritative data ownership, payload translation, service levels, failure recovery, reconciliation, security, audit logging, and rollback.
People, artifacts, escalation
Minimum participants
Product or BA ownerTech leadArchitectSource-system ownerQA
Minimum artifacts
- System map
- Data flow
- Source-of-truth matrix
- Failure and fallback model
- Reconciliation logic
Escalate if
- The integration affects payment, eligibility, compliance, audit, or official records.
- A source-system owner cannot confirm ownership or constraints.
- Multiple dependencies must change together.
Check the evidence before moving forward.
What decision will this discovery evidence support?
What user, process, data, system, or model evidence would change the decision?
Which risk remains unresolved, and who accepts it if the team proceeds?
What artifact proves the team is ready for build, pilot, rollout, or scale?
Continuous Discovery
Cadence
- Weekly or biweekly signal review for live behavior, support issues, and adoption friction.
- Monthly user or stakeholder touchpoints for deeper problem discovery.
- Quarterly roadmap and outcome review using evidence, not only delivery volume.
Activities
- Track behavior, funnel, support, operational, and trust signals after launch.
- Keep a discovery backlog of assumptions, unresolved risks, and improvement hypotheses.
- Run lightweight interviews, usability checks, experiment reviews, or data validation as new evidence appears.
- Feed validated learning into roadmap, backlog, support readiness, and deprecation decisions.
Outputs
Discovery backlogLearning logExperiment or validation planOutcome dashboardRoadmap recommendation