Scenario Lab — 10–18
10. Migration surprise
Situation: migrated history behaves differently from records created natively in the new application.
Best: treat migration as controlled integration: profile, map, transform, reconcile, test repeatedly and plan cutover.
Weaker: rely on one successful test load.
Changed fact: recurring exchange after go-live → operational integration rather than migration.
Supporting: Data Quality, Storage & Operations, Metadata. Roles: migration lead, source/target owners, DQ/integration teams.
Source: pp. 279–282.
11. Real-time fraud
Situation: multiple event streams must be combined to identify suspicious behavior and automatically block/alert.
Best: CEP using rules plus historical/reference context.
Weaker: message routing only.
Changed fact: events only need transport without interpretation → ESB/message flow may suffice.
Supporting: Architecture, Security. Roles: event architect, integration team, fraud/business owner, security operations.
Source: pp. 268–273, 279–282.
12. No physical copy wanted
Situation: users need one logical view across heterogeneous stores without moving all data into a warehouse.
Best: federation/data virtualization.
Weaker: build a warehouse solely because multiple sources exist.
Changed fact: persisted history, source-independent availability or performance requires stored integrated data → hub/warehouse becomes stronger.
Supporting: Architecture, DW/BI. Roles: architect, virtualization team, consumers, source owners.
Source: pp. 268–273.
13. External partner exchange
Situation: regulated customer data will be exchanged electronically with a partner.
Best: Data Sharing Agreement/MOU defining responsibilities, acceptable use, restrictions and service expectations plus technical specification.
Weaker: interface specification alone.
Supporting: Governance, Security, Metadata. Roles: Data Owner/Steward, legal/security, integration team, partner owner.
Source: pp. 282–285.
14. Archive unreadable
Situation: retired-application archive exists but current technology cannot read the format.
Best: archive governance must preserve long-term readability/technology compatibility and retrieval capability.
Weaker: count stored bytes as successful archiving.
Changed fact: authorized deletion after retention expires → lifecycle/disposition becomes primary.
Supporting: Document & Content Management, Storage & Operations.
Source: pp. 266–268.
15. Local tool sprawl
Situation: every application team uses a different integration tool; support skills/costs keep rising.
Best: enterprise standards, sponsorship, reusable patterns and CoE expertise where value exceeds replacement cost.
Weaker: replace every working local solution solely for uniformity.
Changed fact: narrow local use case fully justifies a local solution with controlled enterprise risk → local option may remain reasonable.
Source: pp. 282–285.
16. Mapping change request
Situation: developer wants to change a transformation converting business status codes.
Best: business stakeholder/Data Steward review and approve meaning-changing rule; capture governed mapping/Metadata/change evidence.
Weaker: developer changes business semantics alone.
Changed fact: purely technical implementation detail leaves business meaning unchanged → technical decision may remain technical.
Supporting: Metadata, Governance.
Source: pp. 282–285.
17. Critical downstream system
Situation: a real-time data service feeds the organization’s most critical trading application.
Best: operate and monitor DII availability, latency, recovery and error handling to the service tier required by the most demanding dependent consumer.
Weaker: measure component uptime only.
Changed fact: low-criticality batch consumer → lower service tier may be justified.
Supporting: Storage & Operations, Governance. Roles: critical consumer owner, integration operations, architect, service manager.
Source: pp. 279–282, 285–286.
18. Too much complexity
Situation: same data appears in many sources; nobody knows which is authoritative or fit for new purpose.
Best: requirements → discovery → profiling + lineage + business rules before source/architecture/tool selection.
Weaker: choose a tool first.
Changed fact: once evidence about sources/fitness/rules/lineage is known, architecture, mapping and orchestration decisions can be made responsibly.
Supporting: Data Quality, Metadata, Architecture.
Source: pp. 273–279.