Deep Battle Cards G–L
Deep Card G — Integrate Metadata vs Distribute/Deliver Metadata
Definition: Integration reconciles source Metadata into managed form; Delivery makes managed Metadata accessible.
Purpose: consistency vs usability/adoption.
Owners/users: Metadata integration specialists vs portal/application teams and consumers.
Inputs: heterogeneous source Metadata vs managed Metadata + consumer needs.
Outputs: mapped/merged standardized Metadata vs portals/reports/files/services/application views.
Deciding distinction: reconcile vs consume.
Contrast: map equivalent concepts and resolve overlaps → Integrate; publish approved Metadata through portal/API → Deliver.
Trap: harvesting is one integration step; it is not delivery.
Memory: Integrate makes one; Deliver makes useful.
Source: pp. 414–417.
Deep Card H — As Designed vs As Implemented Lineage
Definition: As Designed comes from mapping/design specs; As Implemented comes from actual code and implemented processing.
Purpose: distinguish intended architecture from production reality and fill lineage gaps transparently.
Owners/users: architects, developers, lineage specialists, auditors, change teams.
Inputs: design specs/models vs code/jobs/tool repositories.
Outputs: intended lineage vs current implemented lineage.
Deciding distinction: specification vs actual code.
Contrast: CRM.Customer→DW.Customer in mapping → Designed; code routes through cleansing job X → Implemented.
Trap: approved design is not automatically current production behavior.
Memory: Designed = planned; Implemented = running.
Source: pp. 418–419.
Deep Card I — Lineage vs Impact Analysis
Definition: Lineage traces origin/movement/transformation; Impact identifies dependencies affected by a contemplated change.
Purpose: provenance/trust/root-cause vs change-risk planning.
Scope: current/past path vs future consequence.
Inputs: integrated dependency Metadata.
Outputs: lineage path diagrams vs impact reports.
Deciding distinction: trace vs predict consequence.
Contrast: track PII source-to-report → Lineage; identify reports/jobs affected by column rename → Impact.
Trap: impact commonly traverses lineage relationships, but the questions are not the same.
Coverage warning: incomplete Metadata → incomplete lineage → incomplete impact.
Memory: Lineage traces; Impact predicts.
Source: pp. 418–419.
Deep Card J — Metadata Coverage vs Usage vs Documentation Quality
Definition: Completeness = how much in-scope Metadata exists; Usage = whether consumers access/use it; Documentation Quality = correctness/consistency/fitness of content.
Purpose: distinguish availability, adoption, and trustworthiness.
Inputs: scope inventories; logs/surveys; comparison/collision/quality checks.
Outputs: coverage ratio; usage trends; quality findings/trends.
Deciding distinction: exists? used? trustworthy/current?
Contrast: 1,100/2,000 elements → completeness; few searches → usage; contradictory definitions → quality.
Trap: 100% inventory can still fail if nobody trusts or uses it.
Memory: HAVE IT → USE IT → TRUST IT.
Source: p. 423.
Deep Card K — Metadata Security vs Data Security
Definition: Data security protects values/content; Metadata security protects information describing sensitive assets, existence, location, structure, access, or security context.
Purpose: prevent the Metadata layer from becoming a roadmap to protected information.
Owners/users: Security, Governance, Metadata admins, asset owners.
Inputs: data classification/access requirements + Metadata sensitivity.
Outputs: role-based Metadata visibility/access controls.
Deciding distinction: descriptive exposure itself can create risk.
Contrast: catalog reveals location of highly protected datasets to unauthorized users → Metadata security problem even if values are hidden.
Memory: Protect the treasure and the map.
Source: pp. 412–413.
Deep Card L — Repository Administration vs Metadata Governance
Definition: Administration operates refreshes, jobs, movement, warnings, interfaces, and technical issues; Governance sets decision rights, roles, standards, quality/currency/completeness, security, lifecycle, change/approval, and accountability.
Purpose: keep the platform running vs keep Metadata trusted/controlled as an enterprise asset.
Owners/users: Metadata specialist/admin vs Governance body, Owners, Stewards, leadership.
Inputs: job/interface evidence vs policies/roles/standards/risk requirements.
Outputs: successful operations/issues resolved vs standards, stewardship, approvals, quality/security controls.
Deciding distinction: operate the system vs govern meaning/lifecycle/accountability.
Contrast: failed harvest job → administration/Manage Stores; who approves definitions and sensitive visibility → Governance.
Trap: a technically stable repository can still contain stale, conflicting, unowned, insecure Metadata.
Memory: Admin runs; Governance rules.
Source: pp. 413–414, 421–423.