by Scott Campbell, Director, Western Region, Infoverity
Master Data Management (MDM) implementations are often asked for outbound messages to adhere to a Canonical Model (CM). Thinking through the Enterprise Application Integration (EAI) patterns that might apply, we find there are a couple of ways to approach this.
First, you might ask, is it reasonable to expect the MDM to publish Messages that adhere to the CM definition? Let’s assume that the model of our messages published matches the MDM model. In other words, the MDM model will determine the Message model.
At first pass, it’s a pretty straightforward answer. One of the primary uses of an Enterprise Service Bus (ESB) is to map messages between endpoints (services, applications, etc.) to enable heterogeneous integration. So then, you might ask, should we just request the ESB to handle all the transformations?
As we think through that, let’s recall a typical use case of an ESB involving integration of both legacy and newly-created endpoints. A standard approach would be to establish an Enterprise CM, build transformations for legacy message formats to the new CM, and require new endpoints to publish the CM. This approach improves the efficiency of communications by agreeing on a standard. It continues to support legacy endpoints by handling the transformation of the legacy model to the new CM standard. It also reduces overall system execution cost by having new endpoints eliminate the need for that translation. As additional endpoints are added to the ecosystem they can slipstream in an efficient manner by fitting into one of those approaches.
Great, then let’s make the ESB do all the heavy lifting for us.
Wait! What if we thought about this in a different way? Remember in our assumption the MDM model drives the Message model. If we want the Message model to adhere to the CM, let’s ask the question this way: Should the MDM model adhere to the CM?
First we ask if we need the entire CM modeled in MDM in order to adhere to the CM. The answer is no, for at least two reasons. First of all, Master Data doesn’t master all attributes of a model, only those that need mastered across business units or purposes. Second, adherence to a model doesn’t imply we need all the attribution, only that the subset of attribution that we do provide is consistent with the model. So, we can establish that adhering to the CM doesn’t mean MDM must master all the CM attribution; a relevant, conforming subset is enough.
The CM is meant to provide an enterprise with a standardized data model across business purposes, and Master Data is meant to provide an enterprise with a way to master common data across business purposes. By definition, those two patterns should align very closely. It’s a logical assumption that the MDM model should, in fact, be a subset of the CM. One provides the enterprise-view of attribution, and the other provides a way to master that attribution.
Therefore, there is a strong argument for the MDM model to be a subset of the CM. However, Master Data modeling does not equate directly to Enterprise modeling. Master Data modeling must consider things like: the ability for users to easily participate in Data Stewardship of the Master Data; and attribution for effective, efficient Match, Merge and Deduplication processing. These core tenets of Master Data will very often require the MDM model to diverge from the CM.
In conclusion, the next time you’re struggling with the relationship between Master Data and a Canonical Model, remember it’s ok to start with the CM and ask why the MDM model isn’t consistent. Just also remember the reasons it will diverge.