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!