Lesson 8 — Lineage, Impact, and Metadata Security
Data Lineage
Lineage describes origin, movement, and transformation. A useful path might be:
Source field → Staging field → Transformation → Warehouse field → Semantic metric → Report
As Designed Lineage
Derived from mapping specifications, models, and design documentation. It describes intended movement.
As Implemented Lineage
Derived from actual code, jobs, and technical implementation. It reflects production reality.
If a mapping says A → B but production code runs A → C → B, the current production path is As Implemented. The design remains useful for intent and for detecting implementation drift.
A mature environment may combine implemented evidence with designed information to fill gaps, while labeling each correctly.
Coverage limit
Lineage can only trace what the Metadata environment can see. An unmanaged spreadsheet, script, black-box vendor process, or inaccessible system can create gaps. A “broken lineage diagram” may actually be a Metadata coverage problem.
Impact Analysis
Impact analysis asks a different question:
- Lineage: Where did this come from, and where did it go?
- Impact: What will be affected if this changes?
Both use the same dependency graph. Root-cause investigation often walks lineage upstream. Change planning often walks dependencies downstream.
Example: - “Trace SSN from CRM to all reports.” → Lineage. - “What breaks if we remove SSN from CRM?” → Impact Analysis.
Metadata security
Security applies to the map as well as the treasure. Metadata may reveal: - a sensitive dataset exists; - its exact location; - sensitive field names; - owners and access patterns; - movement paths; - control classifications.
Even without revealing protected values, this can create risk. Metadata access may therefore require restriction.
Source anchor: pp. 412–413 and 418–419.