Last time I introduced two different approaches for master data models and thought it would be worth examining the differences in greater detail.

The first approach is to use pre-packaged core models provided by a vendor as part of an overall MDM suite of tools. Often these types of products evolved out of industry applications in which a common information model was used to support specific types of enterprise applications. For example, a vendor might have analyzed the property and casualty insurance industry and developed core data models for customer, policy, claim, service, financial products, etc. A set of application layers may have been developed on top of these models to implement common workflows (customer risk rating for establishing premium rates, or initiating a claim). However, there is a perception that aspects of those industry-oriented models can be segregated into a more universal format, which can become the starting point for a prepackaged master domain.

So in this case, the model and the associated services for a “customer” are reused as a general-purpose model. On the other hand, its original context may have biased the design; even if the customer model is used for a retail environment, there may be remnants of its insurance “genome” that remains embedded within the model and corresponding access and update functions and methods.

In the business-driven approach, you don’t start out with a predefined model. Rather, you use your own models, and that means either starting with data models in use within the organization or developing a canonical shared model. In this scenario, the MDM vendor’s product leverages your internal models and generates the services and interfaces around your organizational model.

In my previous entry, Structure, Semantics and Master Data Models, I noted the issues we have seen with respect to master reference data management, structural variation, and semantic differences. In my next post, let’s look at how a fundamental difference in the way a master data environment is envisioned not only biases the decision regarding modeling, but also lays the framework for the kinds of problems we have discussed. I will also be talking about this on a March 20 TDWI Webinar, “Is Your Approach to Modeling MDM Fixed or Flexible?”