June 16, 2011
Avoid Roach Motel MDM Architecture
Topic: Data Management
There's a trap for catching cockroaches called the Roach Motel. TV commercials have made the product famous by using the slogan: "Roaches check in but they never check out!"
Oddly enough, some types of user-designed databases are similar to the Roach Motel, such that "Data checks in but rarely checks out!"
For example, most homegrown master data management (MDM) solutions focus on customer data. Central to the solution is a database that serves as the master repository for customer reference data. Typically, customer data flows one way -- from multiple operational applications (ERP, CRM, financials) into the database. If data comes back out, it usually goes straight into downstream databases, such as data warehouses or analytic data marts, or it may go into databases used only for sales contacts, marketing campaigns, and direct mail. Rarely does the customer data flow back upstream to enhance the operational applications and databases from which it came.
This kind of Roach Motel MDM Architecture is good for profiling and studying customer reference data. It can be handy for documenting the lineage of aggregated reference data, and it's just fine for customer-base segmentation and other analytic applications. However, Roach Motel MDM is inherently one way, so it's bad whenever you need to improve reference data in a central place, then publish it to a wide variety of operational applications.
Although Roach Motel MDM Architectures are sometimes called a customer data hub, it's not really a hub. A Roach Motel is merely an operational data store (ODS) or (worse) a data staging area. If you want to reach the full potential of MDM -- and especially if you want to operationalize MDM -- then you need a real hub that can do more than just aggregate data and pass it on to a short list of targets.
Deploy a True Customer Data Hub
If a data hub is really a hub, data flows bi- directionally, both into the hub and back out to upstream applications and data sources from whence it originated. This is called a closed loop data flow. For this to happen, you usually need a wide range of interfaces, both old ones (database calls in batch) and new ones (data services in real time).
Furthermore, a data hub doesn't just manage or move data -- it improves data. All MDM applications should improve reference data on the hub, then synchronize it back to source systems so they benefit, too. Typical improvements include data standardization, matching, de- duplication, and identity resolution. As with the Roach Motel, reference data from a hub can still flow downstream to BI data stores. Yet, these may also add value to reference data, then sync with the hub.
By definition, MDM enables the consistent, apples-to- apples sharing of reference data across multiple IT systems as well as across the business units that own and/or use those systems. As a wise data management professional once said: "If you're not sharing data, you probably don't need MDM." Likewise, if you're hoarding reference data in a Roach Motel database, you're not sharing.
Avoid Roach Motel MDM architecture. Make reference data fully sharable by managing it through a true hub that supports data movement in many directions.
Make MDM's reference data fully accessible. This means supporting a wide range of interfaces, include Web services, perhaps over a service bus.
Improve reference data. Don't just manage it. Aggregation adds value. Add more value via data quality functions, such as standardization, de-duplication, and identity resolution.
Synchronize reference data across multiple applications. After all, the point of MDM is to enable data sharing, not data hoarding as seen in Roach Motels.
Much of the information for this article comes from a TDWI Webinar, Master Data Management for a Single Customer View. You can register for and replay the Webinar at tdwi.org.
Copyright 2011. TDWI. All rights reserved.