Deep Battle Cards A–F
Deep Card A — Business vs Technical vs Operational Metadata
Definition: Business expresses meaning/rules/ownership/governance; Technical describes structures/mapping/movement; Operational records processing/access runtime evidence.
Purpose: together they answer what data means, how it is implemented, and how it behaves.
Typical owners/users: Stewards/SMEs; architects/developers/integration teams; operations/support.
Inputs: definitions/rules; models/schemas/mappings; logs/status/usage/SLA evidence.
Outputs: glossary/rules/ownership; models/mappings/technical lineage; logs/errors/usage metrics.
When used: classify from the information’s role/origin, not audience.
Deciding distinction: MEAN → BUILD/MOVE → RUN.
Contrast: approved Active Customer definition → Business; ETL mapping → Technical; last successful ETL run → Operational.
Trap: Operational Metadata is not ordinary operational transaction data.
Source: pp. 399–401.
Deep Card B — Business Glossary vs Data Dictionary vs Directory/Catalog
Definition: Glossary manages business concepts/terms; Dictionary describes data-set/element structure; Directory/Catalog identifies sources/systems/locations for discovery.
Purpose: shared meaning vs structural detail vs discovery.
Owners/users: Stewards/SMEs; modelers/developers/analysts; broad data consumers/catalog admins.
Inputs/outputs: terms→approved definitions; schemas→element properties; inventories→searchable source listings.
When used: “what does it mean?” vs “what are its properties?” vs “where is it?”
Deciding distinction: meaning vs structure vs location.
Contrast: Net Revenue meaning → Glossary; CUSTOMER_ID datatype/uniqueness → Dictionary; which system stores Customer history → Catalog.
Trap: one modern platform may offer all three; that does not erase the conceptual difference.
Memory: Glossary talks; Dictionary details; Catalog finds.
Source: pp. 403–407.
Deep Card C — Centralized vs Distributed Metadata Architecture
Definition: Centralized stores harvested copies in one persistent repository; Distributed provides a common access point but retrieves Metadata from sources in real time with no persistent central store.
Purpose: integrated consistency/search vs source-held retrieval.
Scope: persistence and retrieval.
Inputs: source repositories + consumer requirements.
Outputs: integrated central repository vs brokered source views.
Deciding distinction: persistent central copy.
Contrast: nightly harvest into enterprise repo → Centralized; portal queries modeling/ETL repos at every search → Distributed.
Trap: many source repositories do not automatically make the enterprise solution distributed; the no-central-persistence rule does.
Memory: Centralized copies; Distributed asks.
Source: pp. 408–410.
Deep Card D — Hybrid vs Bi-Directional Metadata Architecture
Definition: Hybrid combines central persistence for selected Metadata with source retrieval for detail. Bi-Directional adds governed Metadata change flowing back to source environments.
Purpose: Hybrid balances consistency/freshness/scale; Bi-Directional coordinates maintenance across environments.
Scope: persistence mix vs update direction.
Inputs: standardized/manual Metadata, changing source Metadata, update/conflict rules.
Outputs: central enterprise layer plus source retrieval; or synchronized source/repository updates.
Deciding distinction: selective persistence vs reverse update flow.
Contrast: Stewarded definitions central + job detail live → Hybrid; approved enterprise change updates source tool → Bi-Directional.
Trap: frequent refresh alone is not bi-directional.
Memory: Hybrid mixes; Bi-Directional talks back.
Source: pp. 410–412.
Deep Card E — Strategy vs Requirements vs Architecture
Definition: Strategy sets enterprise direction/current-to-future approach; Requirements define needed content/function/access/control; Architecture defines how Metadata will be sourced, stored, integrated, refreshed, and delivered.
Purpose: prevent product-first implementation.
Owners/users: sponsors/Governance/Metadata lead; business/technical consumers; architects/specialists.
Inputs: business priorities/current state; consumer needs; source/technical constraints.
Outputs: strategy/roadmap; requirement set; architecture/metamodel/technical design.
Deciding distinction: WHY/WHERE → WHAT → HOW.
Contrast: assess current sources and create phased future plan → Strategy; need search/history/approvals/restricted access → Requirements; central vs hybrid + refresh design → Architecture.
Trap: tool evaluation before strategy/requirements reverses DAMA’s order.
Source: pp. 411–414.
Deep Card F — Data Model vs Metamodel
Definition: Data model represents business/data concepts; Metamodel represents Metadata entities, attributes, and relationships in the Metadata environment.
Purpose: organize business data vs organize knowledge about data/systems/processes.
Owners/users: Data Modelers vs Metadata architects/repository designers.
Inputs: business/data requirements vs Metadata strategy/requirements.
Outputs: conceptual/logical/physical data model vs conceptual/detailed metamodel.
Deciding distinction: what do the modeled entities represent?
Contrast: Customer/Order/Product → Data Model; System/Table/Column/Mapping/Steward → Metamodel.
Trap: both are models and both are broadly Metadata artifacts, but the metamodel operates one abstraction level higher.
Memory: Model the data; metamodel the Metadata.
Source: pp. 413–414.