Master Data Management and Data Integration: Complementary but distinct

master data management and data integration: complementary but distinct A White Paper by Bloor Research Author : Philip Howard Review date : October 2006 Put simply, if you ignore data integration or do not treat it as being of sufficient importance then your MDM project will fail. Philip Howard Executive summary page  This white paper discusses the relationship consolidated view of your customers across, between master data management (MDM) and say, 15 different sales order processing data integration. However, before we do that, systems. Note that this is regardless of we need to understand what we mean by MDM whether you move all of the data into one on the one hand and data integration on the place first and then consult the consolidated other. We also need to understand the role of view or if you do this dynamically, collating technologies such as customer data this view when, say, the customer calls into a integration (CDI), product information call centre. management (PIM) and global supplier management (GSM). Secondly, it should also be obvious that if some of the information you have about your MDM is an increasingly popular technology customers is invalid then it is effectively because it enables the enterprise to useless. Indeed, it may even be worse than understand customers, products, suppliers useless since it may lead to making a sales and other business entities in a more proposal that puts the customer off rather complete and holistic manner, thereby than encourages him. In addition, the validity enabling more advantageous interactions with of your data is essential not only for best external bodies and better control over business practice but also to meet regulatory internal company assets. requirements such as Sarbanes-Oxley. In most large organisations there are multiple So, it should be clear that data integration, applications that deal with the same sort of both for moving the data and ensuring its information, whether that is customers, quality, is a fundamental requirement for any suppliers, products or whatever. However, successful MDM implementation. This is not in that information is often not synchronised and dispute. However, there are two issues: the is distributed across the organisation. MDM first is the role that data integration plays aims to bring this information together (as we within MDM, which we believe to be too easily shall see, there are various ways to do this) so ignored or not fully appreciated and, secondly, that you can see all details about customer A, it seems to us that less thought has been put for example, or product B, in one place at any into the relationship between data integration one time. and MDM, and whether they should be treated as an integrated whole or if it would be better With respect to CDI, PIM and GSM, these are to treat them as separate layers within a all specific instances of MDM. That is, master stack. While either approach can work in any data management is the term used for a one implementation, this white paper generic platform that supports all of these contends that from a general-purpose solution types and it is also used as an perspective it is better to treat data integration umbrella term without necessarily implying as a set of enabling technologies for any such platform. implementing MDM rather than as a part of MDM per se. Moving on to data integration, this consists of several technologies. However, between them In this paper we will discuss the different ways they basically do two types of things: they in which MDM may be implemented, the role either move information from one place to that data integration has to play (which may another or they check and assure the validity differ according to the approach taken to of the data. It should be clear that MDM master data) and expand on why we believe cannot work without some means of moving that data integration should be regarded as a data, as otherwise you could not form a separate set of technologies. Types of MDM solution page  While the executive summary for this report was intended for the general-purpose reader, this section, together with those that follow, is intended for readers that are already familiar with the concepts behind MDM and are aware of its benefits. We will not, therefore, be discussing why you might want to implement MDM or what its underlying concepts are but instead dive right in and start by discussing different types of MDM solution. Breadth of data As we have intimated previously, there are For an example record, like a customer, product or other entity different ways that MDM may be implemented, De nitive Attributes depending upon what you want to do. In Keys Identity Attributes Other Attributes Related Transactional/Content Data particular, these differences can be categorised into three main groups, as Master Identity follows: Master Record • Master Identity where management is of the system of record for keys only, with the Master Data inclusion of a few specific attributes solely to aid the determination of uniqueness. Figure : MDM solutions differ in data scope • Master Record where management is of the Note that hierarchies and relationships unique key and the definitive best record of between entities are a key requirement (no master attributes that has been resolved pun intended) and are assumed to be included from the composition of one or more in all three categories of master information. defined source authors. • Master Data where management is of unique keys, the definitive best record of master attributes and additional transactional information related to the entity. Types of MDM solution page  Architectural approach Just as there are multiple acronyms for MDM (CDI, PIM and so on) so are there multiple terms emerging to describe the architectural approach of how data is authored, stored and accessed. We believe there are 3 fundamental architectures to MDM: • Master Registry: This MDM approach holds • Master Repository: This MDM approach • Master Hub: This MDM approach takes a central registry of unique identities and a holds a central repository of unique authorship for master data away from the reference mapping to the participating identities together with the resolved ‘best participating applications and creates a applications that own entities. In this record’ of attributes from participating central hub of identities, attributes and situation, the participating applications applications that own entities. In this transactional data associated with each retain authorship for creating and updating situation, the participating applications unique definition. In this situation, the hub the individual entities. This approach author segments of the best record, while may replace participating applications and/ physically holds the smallest amount of the repository creates its own new or provide the basis for new applications to master data, the key, with cross-reference composite master record that is used by the be built. mapping to enable other tools and organisation as the definitive unique applications to leverage the unique identity definition. This approach includes the in translation and to access or bring other registry and physically stores more master data together via the unique identity. data than the registry.