You are here:  Home  >  Conference and Webinar Communities  >  Current Article

Metadata Management Q&A – Part 2

By   /  April 14, 2014  /  1 Comment

by Ian Rowlands

I was privileged to do a webinar on March 19th as a preview for a session that I’m doing at the Enterprise data World Conference in Austin on April 30th. I got some really good questions and I thought I’d use my DATAVERSITY Blog to address some of them in two parts (read Part 1 here).

Q: ­Should you first develop a MDM strategy and framework that works for the business and then purchase a MDM solution that fits that strategy or is it the other way around?­

A: MDM is a tricky acronym, since it might mean “Master Data Management” or “Metadata Management”. Conveniently, it doesn’t matter in this case. You certainly should determine your strategy and framework before you purchase a tool. Start with business needs, move on to strategy, use that to determine feature/function requirements and then go looking for a tool that fits.

Q: ­How do we integrate Metadata Management for Master data?­

A: Hmmm … that’s a question that might demand a seminar all of its own. Let me try and summarize. Master data is a subset of the data items for which you may wish to manage metadata. Further, there are attributes of master data that need to be managed to support the use of the master data pervasively in the organization – but there are other attributes that may be relevant only to defined processes. So you should think about the overall metamodel and then position the types and attributes that are relevant to master data as a subset.

Q: What would be the best architectural approach for Metadata , Federated or Centralized?­

A: Neither, or both …! It all depends on your use cases. I might do a blog all of its own on this one, but I can say that as well as “pure play” approaches – “Uber repository”, federation, distribution, and so on, there is a more sophisticated option. This might be described as a “use-case-driven hybrid”. There are circumstances in which leaving metadata in silos may be appropriate. Others in which it may be appropriate to build a “corporate” metadata layer from multiple underlying metadata stores. This approach will be especially appropriate for enterprises prepared to invest in a technology framework capable of supporting a variety of approaches.

­Q: How do you handle privacy requirements metadata?­

A: As far as design is concerned, privacy requirements metadata can be regarded in the same light as any other kind of metadata – it can have its own particular item types, and its own particular attributes. Technically, it’s not specifically challenging. The real issues are about process, and access. There are some standards emerging in the Healthcare space that should be considered and you would also be well advised to give special consideration to archiving.

Q: Can you list most popular Metadata products (programs) available on the market?  Any recommendations?­

A: I’m not sure that this was a serious question, but let me give a serious answer. There are very few enterprise repository products, and I happen to think mine – ASG-Rochade – is the best. There are some good “point’ technologies, and before you worry about choosing a tool, get a handle on your requirements.

Q: Did you cover Ontology­

A: No. I don’t think it’s a beginners topic!

About the author

Ian Rowlands is ASG’s Product Marketing Manager (Data Intelligence). He heads product marketing for Metadata Management and is also tasked with providing content across ASG’s entire portfolio. Ian has also served as Vice President of ASG’s metadata product management and development teams. Before ASG, Ian served as Director of Indirect Channels for Viasoft, a leading Enterprise Application Management vendor that was later acquired by ASG and managed relationships with distributor partners outside North America. He has worked extensively in metadata management and IT systems and financial management, and presented at conferences world-wide, including DAMA and CMG.

  • Richard Ordowich

    There is a common belief that metadata “describes the meaning and usage of information assets.”

    What is not evident however is what metadata describes meaning and usage? There are some relevant articles that help address this issues such as Data, Information, Knowledge and Competence by Valdemar W. Setzer His point of view states that data does not encompass meaning (semantics) and computers don’t contain or process information. He goes on the describe information, knowledge and competence in a way that helps explain these terms in a way that explains why our current beliefs about these terms are flawed.

    Current metadata provides what others have described as weak or “lite” meaning (semantics). Weak semantics are based on structural and syntactic (value domain) metadata and deep or “heavy” semantics require human cognition, perception and interpretation. Semantic metadata does not reside in databases.

    Why is this important? When techniques such as Master Data Management are examined from these viewpoints, it is evident that MDM is limited to dealing with weak or lite metadata. The MDM tools are not capable of deriving meaning from the metadata and thereby have to rely on humans to resolve the variations in meaning. Understanding this helps to appreciate the limitations of MDM before deployment and a realization that the master data may require more human resources than anticipated.

    On another note, master data and in particular reference data such as code lists must be designed and maintained applying principles of taxonomy and ontology. Many code lists contain members that are semantically inconsistent such as a code list that includes values: draft, final, monthly, yearly. This results in confusion and data errors. Few databases designers understand or apply taxonomy and ontology to their data design. This lack of competence in literacy results in poorly designed data.

You might also like...

A Brief History of the Data Warehouse

Read More →