Scenario Lab — 1–9
1. Interface explosion
Situation: Twelve systems exchange Customer directly; support cost and inconsistent downstream formats keep growing.
Best action: move toward hub-and-spoke with canonical/shared exchange representation and reusable interfaces where scale justifies it.
Why: primary problem is pairwise proliferation and semantic inconsistency. Supporting KAs: Architecture, Metadata, Governance. Roles: Data Architect, integration team, Data Stewards, system owners.
Weaker: keep adding bespoke links because each individual link looks easy.
Changed fact: only two stable systems sharing one simple dataset → point-to-point may be reasonable.
Source: pp. 267–270.
2. Warehouse nightly load
Situation: Very high reporting volume overnight; several hours of latency are acceptable.
Best: batch ETL.
Why: choose the latency pattern that satisfies the consumer requirement at reasonable complexity/cost.
Weaker: force real-time because it sounds more advanced.
Changed fact: minute-level freshness → micro-batch/CDC/event-driven may become stronger.
Source: pp. 263–266.
3. Only changed records
Situation: Full extracts overload source/network; consumers need only inserts, updates and deletes.
Best: CDC/delta processing.
Weaker: full snapshot every run.
Changed fact: objective is to keep an exact remote copy synchronized → replication becomes the management concept.
Supporting: Storage & Operations, Metadata. Roles: source DBA/owner, integration engineer, consumer.
Source: pp. 263–268.
4. Receiver outage
Situation: Order capture must continue when analytics is unavailable.
Best: asynchronous/loosely coupled exchange with reliable queue/retry.
Weaker: unnecessary synchronous call that blocks producer.
Changed fact: transaction cannot complete without downstream confirmation → synchronous may be required.
Supporting: Architecture, Storage & Operations. Roles: producer/consumer service owners, architect, integration operations.
Source: pp. 263–270.
5. Exact balance sync
Situation: Financial posting and balance update cannot diverge.
Best: synchronous coordination may be justified despite blocking risk.
Weaker: async solely for resilience when stale/inconsistent state is unacceptable.
Changed fact: seconds/minutes of delay acceptable → looser/event-driven design becomes possible.
Source: pp. 263–270.
6. Source truth surprise
Situation: documentation says a field is never null; actual data contains 18% nulls.
Best: profile actual data and update requirements/Metadata.
Weaker: trust documentation blindly.
Changed fact: location of candidate fields is unknown → discovery comes first.
Supporting: Data Quality, Metadata. Roles: analyst, DQ/integration team, Data Steward, source owner.
Source: pp. 273–276.
7. Unknown origin
Situation: a risk report combines upstream feeds but nobody can explain a measure’s origin/transformation.
Best: document/govern backward and forward lineage plus transformation Metadata.
Weaker: inspect only current target schema.
Changed fact: issue is how one source field converts into target → mapping is more precise.
Source: pp. 273–276, 282–285.
8. Wrong execution order
Situation: transactions load before referenced Master Data.
Best: repair orchestration—sequence, dependencies, triggers and recovery.
Weaker: rewrite correct mappings.
Changed fact: field conversion itself is wrong → mapping becomes primary.
Supporting: Reference/Master Data, Metadata. Roles: integration designer, MDM/data owner, operations.
Source: pp. 276–279.
9. Duplicate services
Situation: teams repeatedly create near-identical Customer lookup services.
Best: search/reuse governed services; modify an existing service when feasible; create a broad reusable service only when no suitable one exists.
Weaker: every application team creates a new near-duplicate API.
Supporting: Architecture, Metadata, Governance. Roles: integration CoE/architect, service owners, application teams.
Source: pp. 276–282, 282–285.