Part 2 — Lifecycle, Requirements, Strategy & Knowledge-Area Mapping

Formatted source: https://docs.google.com/document/d/1ti73eZ5IeeHEbh8etGTJvFQGx0MP5Bzph5Pvkq7Ylws/edit

Lab C — Map the lifecycle of one critical data asset

Choose one high-priority asset—Customer is a strong candidate, but you may choose another if your reasoning is defensible.

Create a lifecycle sketch showing how Meridian:

plans for the data;
creates or obtains it;
stores and maintains it;
uses it;
transforms/enhances it;
shares it;
eventually retains/disposes of it.

Add cross-cutting notes for Data Quality, Metadata, Security/Risk and Governance.

Then add a separate lineage line for one specific element or measure. The purpose is to make the distinction visible:

Lifecycle = management stages/events across the data’s life.
Lineage = where a specific data element came from, how it moved/changed and where it was used.
SDLC = how a system or solution is analyzed, designed, built, tested and deployed.

Interpretation prompt

Where in the lifecycle could Meridian accidentally create new inconsistent data rather than merely move existing data? What management control would reduce that risk?

Lab D — State business/data requirements before technology

Pick one Meridian issue that looks technical—for example customer identity conflict, the untraceable KPI, or inconsistent product categories.

Before naming any software/tool, complete this table:

Requirement type	What Meridian needs
Business outcome	What decision/process must improve?
Business definition	Which concept must be understood consistently?
Data scope	Which domains/elements are in scope?
Quality requirement	What must be accurate/complete/timely/consistent enough for use?
Metadata requirement	What definitions/ownership/source/lineage must be known?
Security/privacy requirement	What restrictions or appropriate-use rules apply?
Lifecycle/retention requirement	What must happen over time?
Integration/latency requirement	What movement/timing is actually needed?
Governance requirement	Who decides, owns, stewards, approves or escalates?
Evidence/metric	What would prove improvement?

Only after this table is complete may you discuss technology options.

Stop and check

Question: Why is “implement Purview/OpenMetadata/a new integration platform” a weak first requirement statement?
Answer: Because a tool is an implementation choice, not the underlying business/data requirement. Chapter 1’s principle is that Data Management requirements should drive technology decisions.

Lab E — Create the Chapter 1 strategy artifacts

Using your inventory and priority findings, create a small first-draft Data Management program package for Meridian.

E1. Draft Data Management Charter

Include at minimum:

vision / why Meridian needs Data Management;
concise business case;
guiding principles;
major goals;
initial success measures;
critical success factors / major risks;
operating-model intent.

This is the program mandate and overall intent.

E2. Draft Scope Statement

Define:

what is in/out for the first planning horizon;
initial goals/objectives;
priority domains/processes;
accountable roles/organizations/leaders.

This is the scope/boundary/accountability artifact.

E3. Draft Implementation Roadmap

Sequence a small set of programs/projects/tasks/milestones. A reasonable roadmap might include governance setup, customer-definition/mastering work, Metadata/lineage baseline, Data Quality controls, security/access cleanup and evidence/maturity review—but your order must follow your findings rather than copying a generic list.

This is the implementation path.

Deciding distinction

Charter = why / mandate / overall intent
Scope = what / who / planning-horizon boundaries
Roadmap = how / when / initiatives and milestones

Lab F — Map Meridian issues to DMBOK Knowledge Areas

Take at least six MCG issues and identify:

primary/leading Knowledge Area;
supporting Knowledge Areas;
why the lead area is primary for the current question;
what evidence or artifact that area would likely produce.

Use this structure:

Meridian issue	Lead Knowledge Area	Supporting areas	Why lead	Expected evidence/artifact

Important reasoning rule

A real enterprise issue can involve multiple Knowledge Areas. Do not force a single permanent label. The lead area depends on what problem/decision the current scenario is asking you to address.

Example: MCG-004 “Revenue KPI Cannot Be Traced” could involve Architecture, Integration, DW/BI, Metadata and Data Quality. If the question is “where did this metric come from and how did it change?”, Metadata/lineage may lead. If the question is “why do two analytical totals differ?”, DW/BI and Data Quality may become more prominent.

Governance distinction

Do not map every issue to Data Governance simply because Governance sits at the center of the DAMA Wheel. Governance supplies direction, decision rights and oversight; other Knowledge Areas perform distinct work.

Next → Part 3 — Independent Rebuild, Debrief & Completion Key