Scenario Lab — Scenarios 01–06
Scenario 1 — Three meanings of Customer
Stem: Sales, Finance, and Service each define “Active Customer” differently.
Leading KA: Metadata Management.
Primary problem: inconsistent business terminology/meaning.
Supporting: Data Governance, Data Quality, Master Data.
Roles: Business Data Stewards/SMEs, Governance.
Best action/artifact: Business Metadata / Business Glossary governance; agree approved definition, relationships, ownership/status, and make it accessible.
Weaker: build technical lineage first—it shows movement, not agreed meaning.
Changed fact: ask which physical fields populate Active Customer → Technical Metadata/source-to-target mapping becomes primary.
Source: pp. 399–407.
Scenario 2 — Where is Customer data?
Stem: analyst knows the concept Customer but cannot identify systems containing customer history.
Leading KA: Metadata Management.
Primary problem: source/system/location discovery.
Supporting: Business Glossary, Data Architecture.
Roles: Metadata team, consumers, asset owners.
Best: searchable Directory/Catalog linked to business concepts/source Metadata.
Weaker: Data Dictionary alone—good for element detail, not enterprise location/discovery.
Changed fact: ask CUSTOMER_ID datatype and uniqueness → Data Dictionary.
Source: pp. 403–407.
Scenario 3 — Definition vs datatype
Stem: one user asks what Net Revenue means; developer asks whether NET_REV_AMT is decimal(18,2).
Leading KA: Metadata Management.
Primary problem: distinguish semantic vs structural Metadata needs.
Supporting: Governance, Data Modeling.
Roles: Steward/SME; developer/modeler.
Best: Business Glossary for meaning; Data Dictionary/Technical Metadata for datatype.
Weaker: force both questions into one artifact category.
Changed fact: developer asks which ETL rule derives NET_REV_AMT → source-to-target mapping/Technical Metadata.
Source: pp. 399–407.
Scenario 4 — Repository bought first
Stem: IT purchases an enterprise Metadata product before interviews, requirements, source inventory, or future-state planning.
Leading KA: Metadata Management.
Primary problem: reversed lifecycle / tool-first implementation.
Supporting: Governance, Architecture, Program Management.
Roles: sponsor, Metadata lead, Governance, business/technical stakeholders.
Best: define Strategy and Requirements—charter/scope, interviews, current sources, future architecture, phased plan.
Weaker: configure product and let tool define the operating model.
Changed fact: approved strategy/requirements and understood architecture needs → product evaluation can proceed.
Source: pp. 398–399, 411–413.
Scenario 5 — One harvested copy
Stem: modeling, ETL, BI, and database Metadata are copied nightly into one enterprise store.
Leading KA: Metadata Management.
Primary problem: architecture classification.
Supporting: Integration, Architecture.
Roles: Metadata architect/admin.
Best: Centralized Metadata Architecture.
Weaker: Distributed—the distributed pattern has no persistent central store.
Changed fact: portal queries each source live and stores no central copy → Distributed.
Source: pp. 408–410.
Scenario 6 — Live portal, no store
Stem: one portal retrieves answers directly from source repositories at query time.
Leading KA: Metadata Management.
Primary problem: distributed retrieval architecture.
Supporting: Architecture, Operations.
Roles: Metadata architect, source-tool owners.
Best: Distributed Metadata Architecture.
Weaker: Centralized—there is no persistent central repository.
Trade-off: source availability/quality controls results; central enrichment and persistent cross-source analysis are limited.
Changed fact: approved definitions persist centrally while details remain live → Hybrid.
Source: pp. 409–411.