Skip to content

← Chapter 1 Applied Lab

Part 1 — Baseline, Asset Inventory, Value & Risk

Source: 01 — Chapter 1 Meridian Applied Lab — Data Management Baseline & Strategy
Formatted source: https://docs.google.com/document/d/1ti73eZ5IeeHEbh8etGTJvFQGx0MP5Bzph5Pvkq7Ylws/edit

1. DMBOK targets

This lab makes these Chapter 1 concepts concrete:

  • Data Management is the development, execution and supervision of plans, policies, programs and practices that deliver, control, protect and enhance the value of data/information assets across their lifecycles.
  • Data should be treated as an organizational asset with unusual properties.
  • Value and management priority should consider benefit, cost, replacement difficulty, quality, risk and reuse rather than storage location alone.
  • Data Management is cross-functional and requires an enterprise perspective.
  • Data requirements should drive technology decisions.
  • Data lifecycle, lineage and the SDLC are related but distinct.
  • A Data Management strategy/program can be expressed through a Charter, Scope Statement and Implementation Roadmap.
  • The DAMA Knowledge Areas divide the broader work without making Data Governance synonymous with all Data Management.

2. Meridian business situation

Meridian Commerce Group already operates through multiple systems—WEB, CRM, POS, PIM, OMS, WMS, ERP, SERV, HRIS, IAM, DWH, CAT and DOC—but management does not yet have a reliable enterprise inventory of the important data assets these systems create or use.

Several known conditions already exist:

  • customer identity conflicts across CRM, POS and Service;
  • competing definitions of “active customer”;
  • product category drift;
  • poor traceability for a revenue KPI;
  • quality defects;
  • over-permissioned access;
  • unclear retention;
  • local uncontrolled spreadsheets/code lists;
  • weak metadata;
  • governance ambiguity;
  • warehouse/reporting disagreement;
  • resistance to shared definitions.

Your job in Chapter 1 is not to solve every defect. Your job is to create an enterprise Data Management baseline that helps Meridian decide what deserves attention and why.

3. Prerequisite gate

No major technology prerequisite is required for Chapter 1. You should be able to work with Docs/Sheets and explain the Chapter 1 theory package.

Optional observation with SQL/DBeaver is allowed only if it helps you inspect existing structures; SQL is not a gate for this lab.

4. Learning outcomes

By the end, you should be able to:

  1. identify Meridian’s important data assets by business purpose rather than merely by application/table name;
  2. distinguish business/data problems from technology symptoms;
  3. rank candidate data assets using value, risk, replacement difficulty, quality and reuse reasoning;
  4. sketch the lifecycle of a selected data asset and distinguish that lifecycle from lineage and the SDLC;
  5. state business/data requirements before proposing technology;
  6. distinguish Charter, Scope Statement and Implementation Roadmap;
  7. map Meridian issues to leading/supporting DMBOK Knowledge Areas;
  8. explain why the work is Data Management rather than just IT administration.

5. Predict first

Before opening Meridian files, answer from memory:

  1. What do you expect Meridian’s three most important enterprise data assets to be?
  2. Which known Meridian defect do you think has the broadest cross-functional impact?
  3. Which issue looks most like a technology problem but is probably a Data Management problem underneath?
  4. What evidence would make you change your initial priority ranking?

Save these predictions. You will revisit them later rather than silently replacing them with hindsight.

Lab A — Build the enterprise Data Asset Inventory

Create a working inventory with at least these columns:

Field What to record
Asset / data subject Customer, Product, Order, Supplier, Inventory, etc.
Business purpose Why Meridian needs it.
Producing process Browse-to-Order, Product-to-Sellable-SKU, etc.
Source systems CRM, POS, OMS, PIM, etc.
Major consumers Finance, Sales, Service, BI, operations, etc.
Business owner / accountable area Who is responsible for business use/meaning.
Stewardship need Where domain stewardship is required.
Sensitivity / restrictions Whether special handling is needed.
Quality concern Known or suspected fitness-for-purpose problem.
Metadata / lineage concern Missing definitions, source, transformation or ownership information.
Lifecycle concern Retention, creation, use, sharing, transformation or disposal concern.
Known Meridian issue IDs MCG-001 through MCG-012 where relevant.

Interpretation question

Do not merely list every table/file. Explain why an enterprise data asset is defined by its business meaning/use and may be represented across several systems.

Lab B — Value, risk and management-priority matrix

Choose at least five assets from the inventory and assess them using a simple qualitative scale such as Low / Medium / High.

Suggested factors:

  • business decision/operational dependency;
  • revenue/customer impact;
  • quality sensitivity;
  • compliance/privacy/security sensitivity;
  • replacement difficulty;
  • breadth of reuse;
  • cross-system dependency;
  • current defect severity;
  • cost of poor data;
  • opportunity from improved data.

Then assign a management priority and justify it in prose. Do not calculate a fake universal “data value score” unless you can defend the weighting. Chapter 1 does not provide a universal pricing formula for data.

Stop and check

Question: Why could Customer data rank highly even if it is not the largest dataset?
Answer: Because priority is tied to business value, reuse, quality/risk exposure, replacement difficulty and cross-process dependency—not simply volume or storage size. Customer data supports sales, service, marketing, orders, analytics and governance decisions, so defects can propagate widely.

Question: Why is “stored in PostgreSQL” not a business-value statement?
Answer: Because PostgreSQL describes technical storage/implementation. Business value comes from what the data represents, which processes and decisions depend on it, its quality, risk and reuse.

Next → Part 2 — Lifecycle, Strategy & Knowledge-Area Mapping