00A-01 — CDMP Applied Data Management Laboratory — Master Program Guide
Purpose: define the program architecture, learning rules, lab-design standard, scope controls, evidence expectations, difficulty progression, and governance rules for Main 00B.
Authoritative formatted sources: Google Doc · PDF
Source boundary
DMBOK concept scope for Chapters 1–17 is controlled by Main 00A and the relevant chapter PDFs. Meridian scenarios, software choices, schemas, and synthetic datasets are instructional implementation designs; they are not presented as DAMA-prescribed architectures.
1. Program mission
Create durable CDMP understanding by repeatedly converting theory into observable work. The program is designed to prevent two failure modes:
- Recognition without understanding: “I can recognize the definition but cannot explain what it means in a company.”
- Tutorial dependence: “I can follow technical steps but do not understand the Data Management reason for the action.”
The applied lab therefore requires both conceptual explanation and practical evidence.
2. Learning architecture
| Layer | Question it answers | Primary outputs |
|---|---|---|
| DMBOK Mastery Lab | What does DAMA mean? What must I distinguish and retrieve? | Guides, maps, battle cards, scenarios, MCQs, recall |
| Technology Training & Competency Roadmap | Can I use the underlying tools without copying blindly? | Competency roadmap, target depth, readiness gates, learner-selected training |
| Meridian Casebook | What company am I managing and why does the data exist? | Processes, systems, domains, roles, defects, incidents |
| Chapter Applied Labs | Can I make this chapter concept happen in a real environment? | SQL/Python, diagrams, policies, registers, decisions, metrics |
| Cross-Chapter Capstones | Can I reason when several Knowledge Areas are simultaneously relevant? | Integrated investigations and staged remediation |
| Evidence & Journal | Can I prove and explain what I did? | Screenshots, artifacts, reflections, before/after results |
3. Lab types
| Lab type | Best for | Examples |
|---|---|---|
| Technical build | Concepts clearer when an object is created | Model → PostgreSQL schema; star schema; roles/views |
| Diagnostic / break-it | Concepts whose importance is felt when something fails | Orphan rows, broken source format, wrong access, duplicate masters |
| Management artifact | Decisions, accountability, documented rules | Governance charter, retention schedule, maturity assessment |
| Decision / dilemma | Judgment matters more than code | Ethics, escalation, change resistance |
| Observation / trace | Relationships, movement, and context | Architecture, lineage, metadata, source-to-target mapping |
| Cross-domain incident | Several disciplines must coordinate | Untraceable KPI, Customer 360 conflict, sensitive-data exposure |
4. Mandatory lab sequence
A. DMBOK concept target — state exactly what chapter concepts the lab makes concrete.
B. Business situation — explain the Meridian process and decision context.
C. Technology prerequisite gate — identify required SQL/Python/PostgreSQL/DBeaver competency; train first if the gate is not met.
D. Predict before touching the tool — state what you expect to find or what should happen.
E. Perform — carry out the technical, management, or decision work.
F. Interpret — explain the output, not merely screenshot it.
G. Break / vary / counterexample — change one assumption or inject a safe defect where useful.
H. Repair — fix the problem using the chapter concept and explain why.
I. Rebuild independently — recreate the learning-critical portion without line-by-line instructions.
J. Evidence — save scripts, results, diagrams, decisions, metrics, and notes.
K. DMBOK Debrief — translate the experience back to DAMA terminology and distinguish neighboring concepts.
L. Retrieval / scenario check — finish with a short closed-book explanation or scenario.
5. Script-independence standard
A script can accelerate practice, but a script you cannot explain is not mastery.
- Annotate important lines/clauses in plain language.
- Change inputs, filters, names, conditions, or outputs.
- Predict at least one result before execution.
- Rebuild a smaller equivalent from a blank editor.
- Explain the business/Data Management purpose without referring to syntax.
For long boilerplate/setup code, independence is judged on the learning-critical portion, not memorizing boilerplate.
6. Scope controls
In scope
- relational SQL and database concepts that support DMBOK understanding;
- Python and pandas for profiling, transformation, reconciliation, and repeatability;
- local workstation setup and reproducibility;
- light BI and metadata platforms when a chapter gains learning value;
- synthetic data and safe simulated incidents.
Out of scope unless later required
- production DB clustering, HA engineering, deep tuning, replication administration;
- application frameworks, algorithm-heavy CS, advanced package engineering;
- complex cloud architecture, Kubernetes, enterprise CI/CD;
- product-feature memorization disconnected from DAMA;
- real PII, credentials, employer data, or unsafe production experiments.
7. Evidence standard
Every completed lab must answer:
- What existed before?
- What did you do or decide?
- What changed or what did you learn?
A screenshot alone is rarely sufficient. Prefer rerunnable logic, structured registers, before/after results, and decision/context notes.
| Evidence type | Examples | What it proves |
|---|---|---|
| Executable logic | SQL, Python, DDL, validation queries | What operation/test was performed |
| Configuration/object evidence | Schema/table definitions, roles, view DDL | What the environment actually contains |
| Business artifact | Policy, decision log, RACI, glossary, retention rule | How DM decisions are operationalized |
| Result evidence | Query output, quality score, reconciliation, dashboard | What happened or was discovered |
| Interpretation | Lab journal / DMBOK debrief | The learner understands meaning, not only procedure |
8. Lab difficulty progression
| Level | Scaffolding | Expectation |
|---|---|---|
| Guided | Detailed steps and hints | Understand and explain every action |
| Faded guidance | Milestones/checks; fewer commands | Choose commands/techniques yourself |
| Diagnostic | Problem statement and evidence only | Investigate cause and perform repair |
| Cross-domain | Ambiguous real-world case | Identify lead/supporting DMBOK areas and sequence response |
| Independent capstone | Business objective, constraints, acceptance criteria | Design work, produce evidence, defend decisions |
9. How chapter labs are built safely
- Read the full controlling DMBOK chapter and refresh its blueprint.
- Identify concepts that benefit from doing, observing, deciding, or diagnosing.
- Select the minimum technology needed to make the concept visible.
- Check the Technology Competency Roadmap prerequisite gate.
- Create the Meridian business situation and synthetic data required.
- Write the lab without inventing DAMA rules; label Meridian choices as lab-specific.
- Create the debrief/source map from the same chapter.
- Test SQL/Python/database actions in the lab environment.
- Run independence QC.
- Produce the formatted guide + companion PDF and inspect both.
10. Completion rubric
| Dimension | Not yet | Working | Mastered for this lab |
|---|---|---|---|
| DMBOK explanation | Cannot explain without notes | Explains main concept with prompting | Accurate DAMA terminology + nearby distinctions |
| Technical execution | Copies without understanding | Can modify and rerun | Can rebuild core work / troubleshoot common failure |
| Interpretation | Reports output only | Explains what output shows | Connects output to business impact, control, DMBOK meaning |
| Evidence | Missing or screenshot-only | Basic saved artifacts | Reproducible logic + result + decision/context evidence |
| Transfer | Recognizes exact tutorial only | Handles changed input | Handles changed fact/scenario and selects right approach |
11. Program governance and maintenance
- Main 00A remains the controlling study-system specification for DMBOK source fidelity and exam preparation.
- Main 00B is the Meridian Applied Data Management Laboratory.
- Main 00C controls the learner sequence across Main 00A and Main 00B.
- Main 00 is only the short navigation doorway.
- 00B retains this internal 00A control area for applied-lab build, evidence, and QC rules; do not confuse it with Main 00A.
- Update technology versions, lab implementation, or company defects when useful, but do not silently change DMBOK meaning.
- Keep stable Meridian identifiers so later labs can reuse evidence.
- Recurring learner mistakes should trigger targeted lab variations or break-it exercises.
- Do not build every possible lab; each lab must add a distinct learning function.
12. Folder architecture and separation rule
00 — START HERE— learner orientation/navigation.00A — Applied Lab Internal Program Control & Build Specification— this control area.01 — Program Curriculum & Roadmaps— 17-chapter applied curriculum and roadmaps.02 — Meridian Company & Casebook— persistent company, systems, roles, domains, defects.03 — Technology Training & Competency Roadmap— what/why/how deep/readiness/stop boundaries.04 — Lab Environment, Data & Setup— synthetic data, setup, SQL/Python assets, diagrams, outputs, recovery.05 — Applied Labs— chapter labs plus cross-chapter capstones/incidents.06 — Evidence, Portfolio, Trackers & Templates— evidence/journal, templates, registers, tracker.99 — Reference Sources & Borrowed Patterns— reference-only patterns; not a source of DMBOK meaning.
Separation rule: place new material under the functional area where it belongs. Do not create new root-level peer folders when an established area already owns the content.