As I’ve written here before, I am a big proponent of the value of an enterprise data model (which I will shorthand as “EDM” henceforth) for all the benefits it provides, among them: describing the data requirements and relationships for the enterprise, which aids data integration projects and helps prevent unnecessary data redundancy; serving as the “glue” in metadata management by defining a controlled vocabulary for data assets; standardizing definitions of data terms; and being the foundation to which physical data assets can be mapped so that we can locate where a given business concept is represented in our systems. This is something I call “master metadata.”
We work with a very comprehensive Enterprise Logical Data Model at my company, and when I’ve given presentations about it at professional conferences I usually get asked the question: why did you build your own rather than obtain one of the industry-standard data models that are out there? My usual response is that, at the time we began developing the ELDM, standard models in our particular industry were largely non-existent. We’re in health insurance; models for the insurance industry have mostly been produced in the property and casualty space, with which we have some similarities but also large differences. There are also clinically oriented standard health care models, but unfortunately the payer side of the health care industry lagged in developing such things.
Since we began developing our ELDM a handful of vendors (I know of four, there may be others) have produced their interpretations of generic EDMs for health insurance. I’ve had a cursory look at one of them. That experience led me to question the value of the purchased model, for I think that a large part of the benefit of building a model is in the process itself, a sort of journey, and the opportunity it presents to align business and IT around some common understandings.
Think of two scenarios: Company A with no EDM who might see purchasing one as an opportunity to jump-start their data management maturity and believe it would be faster and cheaper than starting from scratch; and Company B with a well-developed, detailed, comprehensive EDM who might think a purchased model would alleviate their ongoing maintenance burden and fill in some logical gaps. Since B already has modeled the enterprise, translating from one to the other shouldn’t be too hard. There may be a middle-ground company too, Company C, whose enterprise data architects have spent a few years trying to develop an EDM, made some headway but had trouble navigating the vested interests across multiple IT groups or application owners, and have thrown up their hands in frustration and said, “Let’s just go out and buy it.”
In all three cases, you are going to be faced with adopting and comprehending a new vocabulary and someone else’s formalized representation of your data. It is hard enough to get different parts of the business to agree on the meaning of terms they have used internally for decades (consider two of the most problematic terms in any enterprise: “customer” and “product”) let alone to embrace some external entity’s vocabulary. At Company A the data architects will first spend a lot of time learning and understanding the purchased model before even trying to put it into practical application, an effort that may consume nearly as much time as building a model themselves. Company B will similarly have to map their own model to the purchased one then invest in re-mapping the data assets they’ve previously mapped to the homespun model. Company C will just be transferring their problem from one place to another. Almost none of the analytical labor required to build an EDM gets eliminated, just shifted to a different set of tasks.
The reason I say the value of the EDM is in the journey of building it is because of the conversation that has to happen as SMEs are engaged in describing their data requirements. Building an enterprise model is almost like doing psychoanalysis on the business. As you interview SMEs about their particular processes and data needs, you keep asking the question, in therapist fashion, “What do you really mean by that?” until you have drawn out the specificity required in a good data model. In our own process, we started with a small circle of business-savvy IT leaders then presented subsets of the draft model at first to small stakeholder groups from the business and then larger ones, creating discussion that exposed and clarified homonyms or synonyms, made explicit business rules, and over time created an approved enterprise vocabulary and description of information relationships and hierarchies.
It wasn’t easy, and the backing of the CIO and other business leaders helped enormously, as well as the articulateness and facilitation finesse of the people doing the work. (These are all qualities of which poor Company C is apparently dearly in need.) In the end we had something we could point to as the agreed set of enterprise names and definitions which has served projects very well in ensuing years. Had a standard industry EDM been available for purchase, could we have spent less time and effort by learning and embracing it? Perhaps. Would the result have been as successful from our stakeholders’ perspectives? I don’t think so.
All that said, I would be interested in comments from people who have successfully used an industry-standard model within an enterprise and what that process looked like.