We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.


Business Metadata – Getting to the Truth

Originally published August 31, 2006

 

Consider technical metadata. Technical metadata is (relatively) easy to access and organize. The meta model for technical data is (after all is said and done) relatively straightforward. There are fields and field names. There are tables and data models. There are relationships and data flow diagrams. There are functional decompositions, CRUD matrices and so forth. And while the system developer and the database administrator may perceive the world of technical metadata as being complex and unwieldy, in truth, the world of technical metadata is simple compared to the world of business metadata.

 

Business metadata is infinitely more complex than the world of technical metadata because in the world of business metadata, the meta model can be almost anything. In the world of business metadata, practically any textual description can be an abstraction of something else. And because anything can be an abstraction of something, the possibilities for business metadata are endless. Simply stated, there are no hard and fast rules for business metadata and its meta model.

Another difficulty in getting one’s arms around business metadata is that there is nothing that is more correct or more accurate than something else. Revenue in Brazil may not be the same as revenue in France. A product for an automobile maker may not be the same thing as a product for PricewaterhouseCoopers. A good day in Alaska is probably something quite different than a good day in Kiribati. And so it goes. The metadata model for business metadata depends on numerous factors – locality, context, opinion, history and so forth; thus, dealing with business metadata is a wishy-washy, undefined prospect. But does that mean that there is no structure to data and metadata in the world of business metadata? Hardly.

The model of business data and metadata should be constructed in much the same way as the model for technology, despite all the ambiguities.

Some of the rules of the road for constructing a model for business data and metadata are:

  • Define the scope of integration at the outset. Know the boundaries of the model before you start to build the model.

  • Start with major subject areas. The major subject areas are those major topics of importance to the business.

  • Identify the major relationships between the different subject areas.

  • Concentrate on primitive data, not derived data.

  • Define the major subject areas at different levels of abstraction.

  • Create definitions that are relevant and accurate within the context of the business.

  • Make sure that descriptions and definitions are in the nomenclature of the business person, not the technologist.

  • Avoid complicated and parochial nomenclature such as that found in law, medicine, engineering, etc., unless, of course, the business metadata is meant for lawyers, doctors, engineers, etc.

  • If a formal model is to be created, make sure the formal model is able to be easily modified.

  • If there is to be a wide geographic scope of the model (say over the U.S., Europe and Africa), make sure that there is latitude for definitions and descriptions to encompass all geographical areas. 

These are just a start at the rules for bringing some degree of organization and rationality into a world that has almost no organization. 

In many ways, business metadata is like the Wild West. If you are the first person there, you sort of make up the rules as you go along, using past experience to give you some guidelines. The early pioneers get to make up the rules as they go along. And, of course, sometimes get an arrow in the back or a bullet in the heart – it comes with the territory.

  • Bill InmonBill Inmon

    Bill is universally recognized as the father of the data warehouse. He has more than 36 years of database technology management experience and data warehouse design expertise. He has published more than 40 books and 1,000 articles on data warehousing and data management, and his books have been translated into nine languages. He is known globally for his data warehouse development seminars and has been a keynote speaker for many major computing associations.

    Editor's Note: More articles, resources and events are available in Bill's BeyeNETWORK Expert Channel. Be sure to visit today!

Recent articles by Bill Inmon

 

Comments

Want to post a comment? Login or become a member today!

Be the first to comment!