Scenario Lab — Scenarios 13–18
Scenario 13 — Harvest job failing
Stem: scheduled extraction from a modeling tool repeatedly fails, leaving stale Metadata and warnings.
Leading KA: Metadata Management.
Primary problem: repository operation/movement failure.
Supporting: Governance oversight, Operations.
Roles: Metadata admin/specialist, source-tool owner.
Best: Manage Metadata Stores—monitor job/logs, diagnose interface, restore refresh.
Weaker: rewrite strategy; direction may be fine while execution is broken.
Changed fact: no one owns source Metadata quality or refresh standards → Governance/accountability becomes deeper issue.
Source: p. 414.
Scenario 14 — Conflicting source concepts
Stem: two integration tools use different names for the same logical concept and overlapping Metadata conflicts in the enterprise repository.
Leading KA: Metadata Management.
Primary problem: Metadata integration/reconciliation.
Supporting: Data Quality, Architecture, Governance.
Roles: Metadata integration specialist, Steward, source owners.
Best: stage, standardize, map equivalents, resolve conflicts, controlled merge/load.
Weaker: publish both unchanged and make users choose.
Changed fact: Metadata already reconciled but users cannot find it → Distribute/Deliver/Access becomes primary.
Source: pp. 414–416.
Scenario 15 — Repository nobody can use
Stem: enterprise repository has high-quality Metadata, but business users have no accessible search interface and request answers by email.
Leading KA: Metadata Management.
Primary problem: delivery/access.
Supporting: Socialization, usability.
Roles: Metadata product/team, portal/application owners, consumers.
Best: Distribute and Deliver Metadata—portal/intranet, reports/glossaries, application views, services.
Weaker: collect more Metadata; content already exists.
Changed fact: portal exists but users still avoid it → socialization/training/usability/usage becomes primary.
Source: pp. 398–399, 415–417.
Scenario 16 — Data-lake mystery files
Stem: thousands of files arrive with opaque names and no source, version, format, or received date.
Leading KA: Metadata Management.
Primary problem: context lost at ingest.
Supporting: Security, Retention, Architecture.
Roles: data-lake/platform team, Metadata team, Governance.
Best: capture minimum Metadata at ingestion and catalog the lake.
Weaker: wait until later and reconstruct context after it is lost.
Changed fact: files already ingested without context → later reconstruction may be necessary but remains weaker prevention.
Source: pp. 402–403, 419–421.
Scenario 17 — Sensitive catalog exposure
Stem: catalog reveals names and exact storage locations of highly protected datasets to all employees, but not values.
Leading KA: Metadata Management.
Primary problem: Metadata security/access control.
Supporting: Data Security, Governance.
Roles: Security, Governance, Metadata admin, asset owners.
Best: restrict Metadata visibility/access based on sensitivity.
Weaker: declare safe because values are hidden.
Changed fact: only authorized roles can see the sensitive asset Metadata → control concern may be satisfied.
Source: pp. 412–413.
Scenario 18 — Mapping says one thing, code another
Stem: design says Source A→Warehouse B; production code runs Source A→Cleansing C→Warehouse B.
Leading KA: Metadata Management.
Primary problem: intended vs actual lineage.
Supporting: Integration, Audit, Change Management.
Roles: lineage specialist, developer, architect, auditor.
Best: As Implemented for production reality; As Designed for intended design.
Weaker: treat design as automatically authoritative for current behavior.
Changed fact: implementation cannot be harvested → design may augment the gap, but must not be mislabeled as implemented.
Source: pp. 418–419.