Radha would like to thank Senthil Kumar B, technical architect with the data warehousing and business intelligence practice at MindTree Limited for contributing this month’s column.

There are a lot of master data management (MDM) tools in the market today, and there is also a consolidation process happening between the tool vendors. This situation poses a unique problem for IT teams to evaluate and procure the right tool for their enterprise. This month’s column addresses some of the key parameters that need to be evaluated before the decision for procurement is made. In addition to the tool, an approach to MDM has to be selected in order for the investment to start returning benefits.

Evaluation

A few key points are essential for running a smooth MDM engine.

“Must-haves:”

  • Data governance and stewardship. Identifying the right people to own the right data. This team is responsible for setting up the security access, correcting the erroneous data, defining the workflow, acting on the notifications and submitting a report on the usage of the data.
  • Data quality management. Bad data is as good as not having the data at all. Processes and frameworks constantly working on the business rules, to furnish out sanity to the master data is a must. This is one of the most complex points in the whole MDM cycle. Does the tool possess adequate data validation techniques or does it rely on the extract, transform and load (ETL) tool to cleanse the data?
  • Flexible data modeling capability. The tool should be as adaptive as the business process. A flexible data model is the ideal tool for such an implementation.
  • Integration engine maturity. The data integration drivers that get shipped along with the tool play a key role in the tool evaluation. Look for a tool that has good integration capability. Some of the tools stop with a flat file feature; though this might be enough to start developing your repository, there might be added ETL effort if your sources are completely heterogeneous in nature.
  • Workflow enabled authorization model. How does the authorization and publishing of data happen? Is it through email or through a sophisticated workflow engine? Based on my familiarity with the tools in the market, I have found that much of the MDM analyst's time is occupied in composing email about the next action items for the data. This is where a tool with a “cool” workflow feature takes the upper hand.
  • Security and access control. Can the users of the Indian market control Australian customers? Probably yes, maybe no. Security- and access-driven capability of the MDM system is a must for an organization trying to consolidate its worldwide master information.
  • Search and user interface (UI) customization. Thanks to Google, in this search-driven world, a tool without search capabilities has failure written all over it. The UI should be customizable and the framework should have inherent application programming interfaces (APIs) to achieve the same.
  • Match and merge. Some organizations have master data spread across multiple IT systems. The MDM tool should have good “match 'n merge” programs to choose the right data attribute from the right source system. Most MDM tools have fuzzy logic built into their design; but this can be misleading, because the data that they use should be relevant to the business that the organization is in. An aircraft manufacturer should be looking for a tool that can identify “Boeing” and “Boing” as the same records and choose Boeing over Boing for its single source of truth. 

“Nice-to-haves:”

  • Data enrichment. Some of the tools have the means to enrich their data by integrating with market research data vendors. A good example could be enriching the customer data for D&B-related fields. Though this is not a must feature, it certainly is a feature for tool differentiation.
  • Service oriented in nature. Service-oriented architecture (SOA) utilizes loosely coupled, reusable and interoperable software services to support business process requirements. Though this is not very specific to the tool, it is more of a framework question. Can the MDM solution be easily positioned in the SOA? If the tool has capability to talk to different sources, integrate the data and present the data as a service; it has capabilities to work with SOA.
  • Distributed system. This probably is one of the last items to be evaluated. If your master data runs into terabytes, then this feature of the tool might be worth visiting.

MDM Approach

In the past 5 years, MDM’s maturity model has come a long way. Most of the MDM implementations fall under two different kinds of approaches:

  1. Operational MDM (the tougher of the two) and
  2. Analytical MDM.

Operational MDM enables the synchronization of master entities and their attributes between the transactional processing systems. Why is operational MDM important? Let's consider an example. ABC Corporation is a manufacturing firm. It conducts road shows and marketing campaigns to advertise its products. The salesperson collects customer information during the road shows and feeds it into the IT systems for further follow-up. There are different sets of sales representatives who collect feedback on their products sold. They also enter the customer feedback into their IT systems. These are two different sets of customer relationship management (CRM) processes. In a mature company, there are typically a set of batch processes that pick up the master data from one system and transfer it to another. This introduces delay, inconsistency, inaccuracy of data and lot of manual reconciliation - the same customer name can be entered by two different salespeople or a recent survey from a salesperson can erase previously collected information about the customer. As a result, IT develops custom programs to clean up the data and write reconciliation programs but still cannot manage to do all this in real time. This mess can be reduced or eliminated by deploying an operational MDM. Operational MDM tools solve the synchronization problem using complex match-merge algorithms.
Analytical MDM is an architectural approach, if the problem revolves around inconsistent reporting for business performance management. In simple terms, inconsistent hierarchies are getting reported out and that poses problems while executive decisions have to be made. This demands the need for a unified reporting view of the master data in the enterprise reporting solution. The audience for this system would be the downstream data warehousing and business intelligence (BI) applications.

It is essential that an organization build both these models to address their MDM needs, but which one to choose first depends on an organization’s priorities. I’ve summed up the different capabilities/components of an MDM solution, but there are a few other factors, such as cost and platform dependency, which are left to the discretion of the decision-makers.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access