Scenario Lab — Scenarios 07–12
Scenario 7 — Standards central, logs live
Stem: Steward-approved definitions/common mappings are central; rapidly changing job Metadata stays in source tools.
Leading KA: Metadata Management.
Primary problem: selective persistence architecture.
Supporting: Architecture, Operations, Governance.
Roles: Metadata architect, Stewards, source admins.
Best: Hybrid Metadata Architecture.
Weaker: centralize every runtime detail—creates synchronization burden for rapidly changing Metadata.
Changed fact: nothing persists centrally → Distributed.
Source: pp. 410–411.
Scenario 8 — Repository updates source
Stem: Steward corrects approved enterprise Metadata and controlled synchronization updates the source repository.
Leading KA: Metadata Management.
Primary problem: reverse synchronization / architecture.
Supporting: Change Management, Governance, version/conflict control.
Roles: Steward, Metadata admin, source-tool owner.
Best: Bi-Directional Metadata Architecture.
Weaker: call it centralized solely because there is a central repository.
Changed fact: sources feed enterprise repo but never receive updates → no longer Bi-Directional.
Source: pp. 411–412.
Scenario 9 — Meaning, mapping, run result
Stem: repository stores a business definition, ETL mapping, and last job-success timestamp for one element.
Leading KA: Metadata Management.
Primary problem: type classification.
Best: Business, Technical, Operational respectively.
Roles: Steward/SME, integration team, operations.
Weaker: classify all by the user who views them.
Changed fact: timestamp is business effective date of a definition rather than job result → classification changes with context.
Source: pp. 399–401.
Scenario 10 — Operational Metadata confusion
Stem: candidate calls “number of orders processed today” Operational Metadata just because it concerns operations.
Leading KA: Metadata Management.
Primary problem: classification shortcut.
Best: reject shortcut; classify by role/context. Operational Metadata describes processing/access of data.
Weaker: keyword matching on “operational.”
Changed fact: “ETL processed 1.2M rows in 14 minutes, failed 37 records” → Operational Metadata.
Source: pp. 399–401.
Scenario 11 — Model of Metadata
Stem: architects define System, Database, Data Set, Data Element, Mapping, Process, Steward, and their relationships.
Leading KA: Metadata Management.
Primary problem: repository model design.
Supporting: Metadata Architecture, Data Modeling.
Roles: Metadata architect/repository designer.
Best: create a Metamodel.
Weaker: call it a business data model simply because it contains entities/relationships.
Changed fact: entities become Customer, Order, Product, Invoice → data model.
Source: pp. 413–414.
Scenario 12 — Standards drift
Stem: Metadata sources use conflicting naming conventions and security/visibility attributes.
Leading KA: Metadata Management.
Primary problem: standards inconsistency.
Supporting: Governance, Security, Quality.
Roles: Governance, Metadata architect/admin, source owners.
Best: Apply Metadata Standards and monitor compliance through Governance.
Weaker: treat it only as repository operations.
Changed fact: standards already defined but harvest jobs fail → Manage Metadata Stores becomes operational priority.
Source: pp. 413–414.