Skip to content

Lesson 5 — Strategy, Requirements, and the Metamodel

The sequence prevents tool-first failure

STRATEGY → REQUIREMENTS → ARCHITECTURE → METAMODEL / STANDARDS → IMPLEMENTATION

Define Metadata Strategy

Strategy describes how the organization will move from its current Metadata state to a future state. It should include:

  • charter, scope, and objectives;
  • stakeholders and communications;
  • business/technical interviews;
  • assessment of current Metadata sources and information architecture;
  • future-state architecture direction;
  • governance/stewardship, delivery, technical, and security considerations;
  • phased implementation plan.

A bank may emphasize regulatory lineage. A retailer may emphasize discovery and shared analytics definitions. The platform should support the business outcome, not define it.

Understand Metadata Requirements

Requirements begin with what content and level of detail each consumer needs.

A Steward may need definitions, owners, quality, and rules. A developer may need schemas, mappings, endpoints, and technical lineage. Operations may need job status, alerts, runtime, and SLA evidence.

Also capture: - volatility/refresh frequency; - maintenance and approval workflow; - roles and responsibilities; - quality/currency/completeness; - search/access/integration; - history/versioning; - security.

Metadata can itself be sensitive

A catalog can reveal the existence, location, structure, ownership, classifications, and movement of protected data even if it never displays the values. Metadata therefore can require role-based visibility.

Create the Metamodel

A metamodel is the data model for the Metadata repository/environment. It defines Metadata objects and relationships such as:

System → Database → Data Set → Data Element → Mapping → Process → Rule → Steward → Term.

A conceptual metamodel communicates the major concepts and relationships. A detailed metamodel defines the attributes and implementation structure required by the repository.

Data Model vs Metamodel

  • Entities Customer, Order, Product, Invoice → data model.
  • Entities System, DataElement, Mapping, Rule, Process, Steward → metamodel.

Both are models. The distinction is what the modeled objects represent.

Exam trap

A vendor can demonstrate hundreds of object types. That does not mean the enterprise should adopt them all unchanged. Strategy and requirements determine what the organization needs to manage.

Source anchor: pp. 411–414.

← Lesson 4 · Lesson 6 →