Metadata Development

From MIKE2.0 Methodology

Activity: Metadata Development

Objective

The Metadata Development activity is used to define and integrate the metadata artifacts that describe data and content. The Metadata Development approach defined in this activity does not depend on a single enterprise metadata repository and can instead involve a number of federated solutions that develop progressively across the organisation and are integrated through common standards. A Metadata Warehouse may be developed; increasingly Active Metadata Integration is used as an advanced software development technique.

There are many forms of metadata across a typical organisation, as described in the SAFE metadata management architecture. The tasks below describe some of the most important metadata assets that should be captured and integrated. Metadata Development builds off the Metadata Driven Architecture initially defined in Phase 2 and incorporates Data Standards and Data Governance Policies.

The MIKE2.0 Methodology takes the approach that metadata development should be integrated into design and development activities as opposed to a standalone activity. This activity is important for ensuring that this process is in indeed followed and highlighting some of the most important tasks.

Major Deliverables

• Development of metadata artifacts across the organisation
• Integrated metadata artifacts across the organisation

Tasks

Develop Metadata Models

Objective:

The metadata model should complement the data model or taxonomy model that is defined for storing information assets. There may be a number of models across the organisation - a single, common model is not required.

Input:

• High Level Information Requirements
• Overall Architectural approach, defined through the Conceptual, Logical and Physical Architecture

Output:

• Metadata Model

Develop Metadata Definitions

Objective:

A common definition of data elements is a key aspect of metadata development. The best example of this is a data dictionary, which typically includes:

• Attribute and entity definitions
• Domain values
• Integrity constraints

Input:

• High Level Information Requirements

Output:

• Metadata defined that related to data definiton

Classify Information Assets

Objective:

The Information Classification activity is the implementation of rules for how information assets will be valued, protected, stored and related to the business. It it is particularly important for Information Lifecycle Management and the recent focus has been on classification of unstructured content. Characteristics that are measured include:

• Information Value Characteristics
• Information Service Level Agreements
• Information Protection Characteristics
• Information Storage Characteristics
• Information Quality Characteristics

Input:

• High Level Information Requirements

Output:

• Metadata business rules to generated it defined as related to information classification

Information Services Metadata (Interface)

Objective:

Information Services Metadata relates to the description of the service as well as the schema that exposes it to integration with other systems in the architecture. This services information applies to Message Modelling.

Input:

• High Level Information Requirements
• Solution Architecture Definition/Revision

Output:

• Metadata defined as relates to exposed services. This relates to Message Modelling.

Develop Business Intelligence Metadata

Objective:

Business Intelligence Metadata is used to better empower business users to access information for analytical and reporting purposes. Business Intelligence Metadata typically provides a semantic abstraction layer on top of information stores so that users can more easily query, analyse and understand information. Typical Business Intelligence Metadata includes:

• Business-friendly terms and Data Definitions
• Use of Cube or Universe views of information assets that can help improve performance and simplify queries
• Queries, filters or business rules applied within the BI system

It is particularly important for this metadata to be integrated to metadata in back-end systems to maintain Data Lineage.

Input:

• High Level Information Requirements
• Solution Architecture Definition/Revision

Output:

• Metadata model defined as relates to Business Intelligence.

Integrate Metadata Artifacts

Objective:

Integrating metadata artifacts brings assets together into a common model. This is relevant when building a Metadata Warehouse for reporting or for taking a metadata-driven approach to software development.

Input:

• Sources of metadata across the in-scope environment

Output: Integrated metadata, possibly within a Metadata Warehouse

Core Supporting Assets

Yellow Flags

Areas to look out for include:

• Resistance from the organisation to recognise inforamtion as an asset.

• Lack of a high level current-state information architecture so it is known where information assets reside.

Key Resource Requirements

• Information Architect
• Information Analysts

Potential Changes to this Activity

This activity is still being defined and will likely undergo a number of changes. Potential changes could include:

• The Metadata Driven Architecture activity takes place during the Technology Blueprint and is used to get to get an initial repository in place to move to a metadata-driven architecture. The alignment between this activity and that activity needs to better defined.

• There are many different types of metadata, the purpose of this activity is not to list them all but to instead highlight the most important tasks. It may be better to keep this activity quite general and define the details into Supporting Assets.

• This activity covers metadata development, but not metadata reporting on areas such as Data Lineage or Impact Analysis, which is one of the more tangible business benefits. This area should be covered within one of the activities.

• Some later tasks such as Data Profiling, Data Re-Engineering and ETL Physical Design have tasks to explicitly integrate metadata

• The goal in MIKE2.0 should to make Metadata Development a by-product of software development as opposed to a standalone, additional task.

• It may be better to generalise the data dictionary task and make it data definition.