Choosing the Right Master Data Management Solution for Your Organization

Transcription

1 Choosing the Right Master Data Management Solution for Your Organization Buyer s Guide for IT Professionals BUYER S GUIDE

2 This document contains Confidential, Proprietary and Trade Secret Information ( Confidential Information ) of Informatica Corporation and may not be copied, distributed, duplicated, or otherwise reproduced in any manner without the prior written consent of Informatica. While every attempt has been made to ensure that the information in this document is accurate and complete, some typographical errors or technical inaccuracies may exist. Informatica does not accept responsibility for any kind of loss resulting from the use of information contained in this document. The information contained in this document is subject to change without notice. The incorporation of the product attributes discussed in these materials into any release or upgrade of any Informatica software product as well as the timing of any such release or upgrade is at the sole discretion of Informatica. Protected by one or more of the following U.S. Patents: 6,032,158; 5,794,246; 6,014,670; 6,339,775; 6,044,374; 6,208,990; 6,208,990; 6,850,947; 6,895,471; or by the following pending U.S. Patents: 09/644,280; 10/966,046; 10/727,700. This edition published May 2011

3 Overview This buyer s guide is designed to help IT professionals navigate the technical requirements to make the right selection when purchasing and implementing a master data management (MDM) solution. Master data is a collection of common, core entities, their attributes, and their values that are critical to a company's business and are required for use in two or more systems or business processes. Examples of master data include customer, product, employee, supplier, and location. Complexity arises from the fact that master data is often strewn across many channels and applications within an organization and invariably contains duplicate and conflicting data. MDM is how the master data is created and maintained as the system of record for the enterprise. MDM is implemented to ensure that the master data is correct, consistent, and complete and is circulated in context for consumption by internal or external business processes, applications, or users. Critical MDM functionality can be easily overlooked when technical requirements are narrowly focused on a single data type such as customer or product or on near-term requirements within a single business function. Consequently, IT teams run the risk of selecting and investing in technologies that may be difficult to extend to other datatypes or difficult to scale across the organization. Worse, such solutions will likely require costly and extensive custom coding to add business data entities or data sources or to extend the system to other lines of business or geographies. By including the following 10 critical MDM requirements, you will be well on your way to laying the foundation for a complete and flexible MDM solution that addresses your current requirements and can evolve to address unforeseen future data integration requirements across the organization: 1. Support multiple business data entities within a single MDM system 2. Ensure platform approach to MDM 3. Support complex relationships and hierarchies 4. Automatically generate service-oriented architecture (SOA) services 5. Integrate data quality within the MDM system 6. Mix and match different MDM architectural styles 7. Track history and lineage to support regulatory compliance 8. Implement MDM for both modes of operation: analytical and operational 9. Use multiple deployment modes: on premise, cloud, and hybrid 10. Meet data governance needs at the project or enterprise level

4 Ten Key Requirements to Consider When Evaluating an MDM Product Requirement 1: Support multiple business data entities within a single MDM system When you select and deploy an MDM system, make sure it can manage multiple business data entities such as customers, products, and organizations all within the same software platform. By doing so, system maintenance is simplified and more cost effective, which results in lower total cost of ownership. A less favorable alternative is to deploy and manage separate master data systems with each system managing a different business data entity. However, this approach would result in additional system maintenance and integration efforts and a higher total cost of ownership. Another advantage of an MDM system that can handle multiple datatypes is that implementation can begin with a single business data entity such as customer, and can later be extended to accommodate other master datatypes resulting in rapid return on investment. Requirement 2: Ensure platform approach to MDM There are two distinct approaches to multidomain master data management: application MDM and platform MDM. Both can address a pressing business problem that is caused by inaccurate, incomplete, and inconsistent data. However, an application MDM approach only solves the business problem for which it was designed. Because it comes with a predefined data model, business logic, or functionality and a specific graphical user interface (GUI), it cannot be extended to other business problems. The concept is similar to buying an off-the-shelf sales force automation (SFA) application for managing the sales pipeline or a procurement application to manage the purchase of direct or indirect materials for the supply chain. The paradox of this approach is that it inevitably leads to more data silos and cost overruns. Because it starts with the application rather than the data, we call this the upside-down approach. In contrast, the platform MDM approach can be extended to solve other business problems using the same MDM platform. This approach generates a higher ROI because the MDM technology investment can be used to evolve and scale to address additional business problems in a division, as well as the business problems encountered by other divisions, departments, and regions. Platform MDM is domain and data model independent. It allows organizations to flexibly define their own data model, generate logic and functionality based on this defined model, and provide support to configure the GUI based on the functionality. This approach lowers the total cost of ownership and shortens the time to value. Because this approach starts with the data, we call this the right-side-up approach. Requirement 3: Support complex relationships and hierarchies With a single entity master data hub, such as customers, hierarchies and relationships are relatively straightforward. For example, organizational relationships are depicted as legal hierarchies of parent and child organizations, while consumer relationships are those belonging to a common household. On the other hand, hierarchies among multiple data entities can be highly complex. Examples include Northern retail locations stocking certain products not sold in Southern locations; complex counterparty legal hierarchies determining credit risk exposure; or an account holder s spouse being a high net-worth individual. Make sure your MDM system is capable of modeling complex business-to-business (B2B) and business-to-consumer (B2C) hierarchies, along with the definitions of those master data entities within the same MDM system. Requirement 4: Automatically generate service-oriented architecture (SOA) services Reliable data is a prerequisite to supporting SOA applications those that automate business processes by coordinating enterprise SOA services. Because MDM is the foundation technology that provides reliable data, any changes made to the MDM environment will ultimately result in changes to the dependent SOA services and consequently to the SOA applications. IT professionals need to ensure that the MDM system can automatically generate changes to the SOA services whenever its data model is updated with new attributes, entities, or sources. This key requirement will protect the higher-level SOA applications from any changes made to the underlying MDM system. In comparison, MDM

5 systems with fixed SOA services that are built on a fixed data model will require custom coding to accommodate any underlying changes to the data model. Requirement 5: Integrate data quality within the MDM system Integrating data quality rules and activities (profiling, cleansing, and monitoring) with MDM processes is critical to enhancing the accuracy and value of data assets. Before you start any MDM project, you need to understand the content, quality, and structure of your source data. Data profiling at the source enables data stewards and data warehouse administrators to quickly discover and analyze all data anomalies across all data sources before data goes into the MDM system. This process greatly increases the speed to value from the MDM implementation. Because data cleansing enhances the accuracy of data, provides completeness, and promotes trustworthiness of the data at the source, it improves the consistency of the data within the MDM system. Once source data enters the MDM system, it undergoes data quality processing, including validation, correction, and standardization. With integrated data quality, the MDM system stores the complete history of the data before and after it is cleansed. If data quality is not tightly integrated within the MDM system, then the history of data changes is lost, which won t bode well for compliance initiatives such as the Sarbanes-Oxley Act (SOX). Requirement 6: Mix and match different architectural styles An MDM system can be deployed in one or more of the four architectural styles consolidation, coexistence, centralized, and registry. In consolidation, coexistence, and centralized styles, master data from different sources are reconciled to a physical golden record and centrally stored within the MDM system. In contrast, with registry style, the MDM system creates a virtual golden record, which is set of pointers or indexes to the source data, linking all relevant records to create a virtual view of the data. Depending upon the business use case, some data domains might require a coexistence MDM style while other data domains might require a different style such as centralized. Further, some implementations might require beginning with one style and later graduating to another style while retaining the existing data model, metadata, and matching/survivorship rules. For MDM to be successful within an organization, it is not enough to simply support only one of the architectural styles to the exclusion of others. Instead, the MDM system should support all architectural styles, leaving the choice of architectural style to the organization s business requirements. Requirement 7: Track history and lineage to support regulatory compliance Today, business users demand not only reliable data but also validation that the data is in fact reliable. This is a challenging and daunting undertaking because that master data is continually changing with updates from source systems occurring in real time as business is being transacted and while master data is merged with other similar data within the master data hub. The history of all changes to master data and the lineage of how the data has changed need to be captured as metadata. In fact, metadata forms the foundation for auditing and is a critical part of data governance and regulatory compliance reporting initiatives. As a result, and because metadata is such an essential component of MDM, it is important that your requirements include the need to track history and lineage. Requirement 8: Implement MDM for both modes of operation: analytical and operational An enterprise MDM system needs to synchronize master data with both operational and analytical applications to adequately support real-time business processes and compliance reporting across multiple departments. In contrast, customer data integration (CDI) and product information management (PIM) solutions are most often implemented at the departmental level with the objective of solving a single defined IT initiative such as a customer relationship management migration or a data warehouse rollout. These deployments will typically only synchronize data back to either operational or analytical applications but not both. If you cannot synchronize master data with both operational and analytical applications, your ability to extend the MDM platform across the organization will be limited.

6 Requirement 9: Use multiple deployment modes: on premise, cloud, and hybrid MDM has traditionally been implemented on premise. But increasingly, cloud MDM deployments are becoming common. Until recently, organizations that have been implementing MDM had no choice other than to implement the MDM system on premise within their data centers. Such an implementation requires purchasing a perpetual license to the MDM software, installing it on hardware systems, configuring and testing the MDM software, and maintaining it on an ongoing basis. The on-premise MDM deployment has been attractive to organizations that have large IT teams. But what about medium-size organizations that do not have large IT teams, yet still struggle with the same master data challenges as those of large organizations? Cloud MDM deployments have become attractive to these organizations. Why? First, the MDM software is already installed on a hardware system in the cloud; second, they don t need an army of IT personnel to configure the system for their use; and, finally, they can subscribe to it on a monthly basis, avoiding capital expenditures. Because on-premise systems will remain in use for some time, a hybrid MDM deployment, in which the MDM system resides both on premise and in the cloud, is appealing to many organizations. The choice should be available so organizations are not be forced to choose an MDM technology that can only support either on-premise or cloud deployments. Rather, a flexibility of multiple deployment modes should be a prime requirement in keeping up with changing business requirements. Requirement 10: Meet data governance needs at the project or enterprise level Data governance is unique every organization because it is based on the company s business processes, culture, and IT environment. However, companies typically select an MDM system without much thought to their enterprise data governance needs. It is critical that the underlying MDM system is able to support the data governance policies and processes defined by your organization. In contrast, your data governance design could be compromised and forced to adapt to the limitations of some MDM systems with fixed or rigid data models and functionality. Controls and auditing capabilities are also important data governance components. To properly support this functionality, your MDM system must be able to integrate with your security and reporting tools to provide fine-grained access to data and reliable data quality metrics. Conclusion: MDM Success Begins with Selecting an Integrated and Flexible MDM Platform Once your organization starts to make its departmental master data management projects operational, you will find that your larger enterprise requirements will expand to include other business datatypes and other lines of business or geographies. Therefore, it is important to first seek out and evaluate an MDM solution that adequately addresses these 10 essential MDM capabilities. It is also important to assess the MDM system s ability to support these 10 core capabilities out of the box; they should be integrated components of a complete enterprise-wide MDM system. In this way, you will be able to mitigate technology risk and improve your return on investment because additional integration and customization will not be necessary to make the system operational. Another benefit gained by having these 10 MDM components integrated within the same MDM system is that software deployment is much faster and easier to migrate over time. Finally, it is wise to check customer references to evaluate their enterprise-wide deployment and to ensure that the vendor s MDM solution is both proven and includes all 10 enterprise MDM system capabilities. By including these critical MDM requirements, you will achieve greater success with your MDM initiative along with a more rapid deployment and faster time to value. In addition, these requirements will allow you to quickly reap the returns from selecting an integrated and flexible MDM platform that can address both your current and future business requirements.

7 Product Evaluation Checklist Issues Informatica MDM Vendor 2 What entity types do I start with? Should I focus on customer data first? What about my product data? Do I create a master data system solely for analytical purposes? How can my operational systems benefit? What multidomain MDM architectural style is the most appropriate for my goals? What are the performance considerations? How secure will my master data be? Can I set up security roles and policies that align with my corporate data governance mandates? How long will this multidomain MDM project take? I want to see quick results to get organizational buy-in. Can I ensure that any work I do today won t be wasted as I move forward? If my business model and processes change, can I rapidly realign my architecture and MDM strategy to accommodate changes? Informatica MDM lets you start with any datatype in a single system or separate MDM systems. Informatica MDM supports multidomain MDM for both analytical and operation purposes. Informatica MDM supports all multidomain MDM architectural styles: registry, coexistence, consolidated, and centralized Informatica MDM has the most fine-grained security available for multidomain MDM. Informatica MDM customers have deployed a working solution in as little as 60 days. All implementations have been leveraged for future expanded deployments due to configurability and reuse. Informatica MDM has allowed numerous organizations to evolve and change their multidomain MDM deployments in alignment with their business needs.

8 Worldwide Headquarters, 100 Cardinal Way, Redwood City, California 94063, USA phone: fax: toll-free in the US: Informatica Corporation. All rights reserved. Printed in the U.S.A. Informatica, the Informatica logo, and MDM are trademarks or registered trademarks of Informatica Corporation in the United States and in jurisdictions throughout the world. All other company and product names may be tradenames or trademarks of their respective owners. First Published: May (05/05/2011)