See more articles in this blog

Enterprise Integration & IT Strategy Blog

Some Useful Views of Metadata

Tom Finneran, Principal Consultant  :  14 June 2010 / 10:40 AM  :  0

Most IT practitioners recognize the importance of metadata but not all can describe it’s value.  Gartner has stated these benefits of metadata management:

• Increased reuse of established software assets
• Reduced time to perform change impact analysis
• Quality assurance that all affected assets are part of a coordinated change
• Identification of redundancies and opportunities to reduce maintenance costs through consolidation
• Improved understanding of overlaps in business areas, including during mergers and acquisitions
• Accuracy of end-user analysis
• Savings in training costs
• Speed of business intelligence tool implementations
• Better management decisions

CIBER recognizes four views of metadata:

• Business View – What Business people need to know. 
• Solution Analysis, Design, and Development View – What IT people need to gather and know
• Operational Inventory View – What does what, where, and when on what platform
• Operational Transport View – What is needed to move data to the right place at the right time

The metadata models discussed herein may be considered simplifications. There may be entities and relationships that may be added to the models to build them out. The idea here is to show some usefulness of managing metadata in some kind of repository.  An Enterprise Metadata Repository should provide access and reporting of all four views.  We may discuss the business requirements for a metadata repository in another paper. 

Business View

This is metadata that provides information about data and reports available for use by business users, data stewards, business analysts, and report and analytic users.  This business metadata should be made available on a Business View metadata web site. 
This model represents a simple Business View metamodel.

One business user may know about a report or another analytic, the business user  would go to a metadata portal wherein the user would access a list of Delivery Interfaces that would contain  the report or analytic.  The report metadata would give the report’s name and description.  It would also show a list of fields (Delivery Attribute) used in the report or analytic that will lead to a description of each attribute, including derivation rules and other business rules.  The Data Domain contains domain rules and a list of valid values (Domain View).  The user can see if there are other attributes in the table of the selected attributes that might provide additional insight and report / analytic improvements. 
Another user might be looking for an important data attribute that is key to a given metric.  Finding that attribute, the business person may then get a list of all reports (Delivery Interface)  using this data attribute.
These are just two examples of how Business View Metadata can prove useful. 

Solution Analysis, Design, and Development View

Throughout the application development process, metadata is available to be collected.  Most data modelling tools collect a minimum of descriptive metadata.  UML tools can expand metadata collection.

The model above shows that Change Requests can lead to application development or application maintenance.  It can be valuable to know which Change Request led to what Application change.  Much of the metamodel represents data modelling.  Business Intelligence requirements and the relationship to the data model attributes is represented. 
This metadata is easy to collect and can be turned into a web site useful to business users, data stewards, and development team members.  Modelling tools should be able to publish the models developed as well as the metadata in support of them as a set of HTML pages that can be made available on a metadata web site.  Most modelling tools now have this capability

Operational Inventory View

Metadata that explains what does what, where, and when on what platform

One of our clients who is a senior executive of a IT Infrastructure Management subsidiary of a large conglomerate stated that “this metadata view is our data.”  Yes, metadata can be business operational data depending upon the business. In this case, they needed to know what application runs on what hardware and software platform.  The location of the platform is important as is the business party organization who is responsible for the platform and the contact person for the platform.  There are additional ITIL data entities that may be valuable for analyzing the impact of change requests on Application Platforms. 

Operational Transport View

Operational Transport Metadata answers the question: what is needed to move data to the right place at the right time?  The ETL metadata and any other enterprise integration metadata, including business rules, will be made available to developers using the integration tool software and can be integrated into the metadata repository when it is available later.

Operational Transport Metadata is collected as a part of ETL and other Enterprise Integration development.  An ETL job, represented by Enterprise Integration Package, is developed as part of a  system, represented by the Application Structure.  The job contains tasks that activate component logic that governs the movement of source data to target data.  In some cases, there are global variables, like job start date, that is used throughout the job so that date tests are consistent even if the job starts on one day and ends the next.  This is just one example.  Some EI package vendors have expanded their metadata repository to handle a broader set of metadata views but, so far, attempts have been incomplete. 

Conclusions

Metadata is useful during development as documentation but it is also valuable for business intelligence users, for IT Infrastructure Management, and for data integration.  An Enterprise Metadata Repository accessible through a user-friendly knowledge portal, can provide benefits such as those given at the beginning of this paper and maybe more.  Unfortunately, even though first-class software vendors have sought to develop a metadata repository, no one, to date, has been successful. Therefore, we need to build our own repository or build extensions to existing repository tools.  At CIBER, we have followed both approaches according to the clients requirements and / or culture.

Posted in Enterprise Integration & IT Strategy on 14 June 2010
More by this author

Tagged: Business Intelligence  

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Post a comment