Data Management 6: Meta Data Management

Bas van Gils
Posted by Bas van Gils on Jul 25, 2013

Enterprise Architecture

Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.

This is the sixth blog post in the Data Management series. In the previous post we zoomed in on Master Data Management (MDM). This time the focus shifts to Meta Data Management, or the art of keeping track of “data about data”.

Data Management series: Meta Data


Meta data is often loosely defined as data about data. Another way of putting it that is more philosophical in nature: Meta data is to data what data is to real-life. Defining it clearly is not so straightforward however. The following examples give a general idea:

  • Data reflects real life transactions, events, objects, relationships, etc. For example, data about a sale, inventory levels, phone calls, addresses etcetera. 
  • Meta data reflects data transactions, events, objects, and relationships. More concretely: where is certain data stored? With what quality? Managed by which data steward? When was it last modified? As part of which process? 

If you consider this carefully, it quickly becomes obvious that there is a “type/instance issue” lurking beneath the surface: meta data is data, but is on a different level than “normal” data. The following diagram illustrates this more clearly:

Meta Data is other that ‘normal data’

Various authors have come up with taxonomies for meta data. Many of them are in line with the ISO/IEC 11179 standard, which includes topics such as:

  • Business meta data: definitions, quality requirements etc.
  • Technical and operational meta data: Which data store? What is the schema? What are the data types?  
  • Process meta data: in which process is data used and created? With that frequency?
  • Data stewardship meta data: who is responsible for quality / requirements for data?

In many cases some form of technical meta data is available in source / transaction systems. For example, most relational database systems can be queried for such things as primary keys and field definitions. Other aspects (stewardship, CRUD-relations with processes, quality assessments etc.) need to be stored elsewhere. There are three main architectures for this:

  • Centralized: 
    • All meta data in one repository with a single point of access
    • Quick access, but more complex to maintain procedurally
  • Decentralized:
    • Central retrieval engine with distributed meta data
    • Consistent with low replication at the cost of low standardization in form/ content/ ..
  • Hybrid:
    • The central repository only accounts for user-added meta data and critical standardized items 

Meta Data Management, then, is the set of processes that ensure proper creation, storage, integration, and control to support associated usage of meta-data. While technically complex (it requires a great deal of analysis and careful book keeping), this discipline is mostly business driven: data stewards and data professionals need their meta-data in order to deliver the right data, at the right time to be successful in business.


The interesting thing about meta data is that in part it is already modeled graphically in ArchiMate:

  • Process meta data: using the Access relation between BusinessObject (Entity) and BusinessProcess concepts is a good starting point. Ideally it is in CRUD-terms. Later we may want to extend this with other aspects of the BusinessProcess that are relevant for our Entities (i.e., the fact that the process is running 99.9% of the time)
  • Steward meta data: we can already find the steward of an Entity (see our earlier blog post in this series on stewardship). However, at a later point in time we may want to extend this further

This leaves Business Meta Data and Technical Meta Data. The former is associated with Entities, the latter is associated with Data Objects. At first glance, it may seem to make sense to use the ArchiMate concept “Meaning” to model these types of Meta Data. However, it is more useful to define a profile with attributes for the BusinessObject and DataObject concepts to do this type of book keeping. Most tools, including BiZZdesign Architect, allow profiling to extend the standard language. As a starting point for Meta Data Attributes:

Technical and business meta data

To visualize this meta-data, BiZZdesign Architect already has quite a bit of functionality on board: standard label views, property tables and cross relation tables. Some additional scripts will further add value for the use of the tool for meta data management:

  • A CRUD table that shows the relation between BusinessProcess and BusinessObjects in CRUD terms. The BusinessObjects should be the rows. Rows should be overlaid with a color that indicates who is the data steward for this BusinessObject. 
  • A ‘data quality’ table that has DataObjects on the rows and the Qualities for Technical Meta Data (i.e., the profile we’ve defined) as its columns. If possible, overlay this with colors for those aspects that have a “low / medium / high” type

We have almost reached the end of the data management series: two more postings to go. Next time we will cover Business Intelligence and in the last posting we will wrap up the series by covering advanced models / visualizations using ArchiMate and BiZZdesign architect.

Risk & Compliance Magazine


Join 10.000+ others! Get BiZZdesign's latest articles straight
to your inbox. Enter your email address below:


Subscribe to Email Updates

comments powered by Disqus