Integrated Capstone — The Invisible Data Estate
Case
A financial-services company has: - a Business Glossary with 300 terms; - separate modeling, ETL, and BI repositories; - a CMDB and database catalogs; - a new data lake; - conflicting definitions; - technical lineage that stops at tool boundaries; - lake files missing source/version Metadata; - an enterprise repository pilot containing copied Metadata but no ownership workflow; - sensitive asset locations visible to too many users; - executives celebrating “90% coverage” even though business users rarely search the repository.
Your task
Build a Chapter 12 response that: 1. identifies the primary Metadata program problem; 2. separates Business, Technical, and Operational Metadata needs; 3. chooses/justifies an architecture; 4. defines strategy/requirements before further product configuration; 5. creates a metamodel and standards; 6. integrates sources/resolves conflicts; 7. distinguishes As Designed/As Implemented lineage and enables Impact Analysis; 8. fixes data-lake ingest Metadata capture; 9. applies Metadata security and Governance/stewardship; 10. defines balanced completeness, quality, stewardship, usage, glossary, and maturity evidence.
Layered answer framework
1. Primary problem
The company does not lack Metadata. It lacks integrated, consistently governed enterprise Metadata knowledge. Local sources exist, but they do not form a trustworthy, discoverable, controlled system of context.
2. Types
- Business: definitions, ownership, rules, quality/security context.
- Technical: schemas, mappings, models, transformations, lineage.
- Operational: load/job/access/runtime evidence needed for support and usage analysis.
3. Architecture
A centralized or hybrid pattern can be justified by requirements. If approved definitions, standards, stewardship, and critical enterprise Metadata should persist centrally while high-volume rapidly changing operational details remain source-held, Hybrid is a strong source-aligned candidate.
4. Strategy and requirements first
Define scope/objectives, stakeholder groups, current Metadata/source inventory, consumer content/detail needs, refresh/currency, workflow, versioning, security, delivery, and phased future state before expanding product configuration.
5. Metamodel and standards
Model Metadata concepts/relationships such as System, Data Set, Data Element, Term, Mapping, Process, Steward, Rule, Report. Define naming, identifiers, custom attributes, visibility/security, and exchange standards.
6. Integration
Harvest to staging; preserve audit evidence; standardize; map equivalent concepts; resolve conflicts/overlap; merge/load under controls. Do not publish contradictory source definitions and call the result integrated.
7. Lineage and impact
Harvest As Implemented evidence from actual code where tooling allows it. Preserve As Designed specifications to show intent and augment gaps without mislabeling them. Use the combined dependency graph for Impact Analysis.
8. Data lake
Capture minimum Metadata—name, source, format, version, date received, plus security/retention/ownership attributes—at ingest while context is known.
9. Governance and security
Assign Owners/Stewards, define approval/change workflow, monitor quality/currency/completeness, restrict sensitive Metadata visibility, manage feedback/issues, enforce standards.
10. Balanced metrics
“90% coverage” is only one answer. Add: - documentation quality/conflict trends; - Steward representation; - usage/search/adoption; - Business Glossary activity/resolution; - maturity; - relevant service reuse/compliance.
Why tool-first is weaker
A repository product cannot independently resolve conflicting business meanings, accountability, sensitive visibility, lineage gaps, poor source context, or low adoption. Those are strategy, Governance, integration, quality, and operating-model problems.
Changed-fact logic
If one layer is fixed, do not keep solving it. Example: if coverage and quality become strong but usage remains low, focus on Socialization, Access, delivery, usability, and value communication rather than re-harvesting the same Metadata.
Source anchor: pp. 395–423.