TDWI TECHNOLOGY MARKET REPORT

Transcription

1 FOURTH QUARTER 2006 Segmenting Master Data Management Solutions By Philip Russom TDWI TECHNOLOGY MARKET REPORT About TDWI s Technology Market Reports TDWI s Technology Market Reports are a new Member benefit that describes a community of vendors and products in a particular technology market. The primary goal of these reports is to segment a particular technology market by various characteristics that make it easy for TDWI Members to identify a shortlist of vendors and products to evaluate in depth before making purchasing decisions. Technology Market Reports describe important criteria for evaluating vendor products and highlight key differentiators among leading players in each segment. About the Author PHILIP RUSSOM is the senior manager of research and services at TDWI. Before joining TDWI in 2005, Russom was an industry analyst covering BI at Forrester Research, Giga Information Group, and Hurwitz Group. He also ran his own business as an independent industry analyst and BI consultant, and was contributing editor with Intelligent Enterprise and DM Review magazines. Before that, Russom worked in technical and marketing positions for various database vendors. You can reach him at prussom@tdwi.org. Research Methodology This report focuses on the many technologies and vendor products that can be involved in a software solution for master data management. For a complementary study of users best practices in master data management, see TDWI s recent Best Practices Report, Master Data Management: Consensus-Driven Data Definitions for Cross-Application Consistency (included in this Member mailing; also available at Most of the market data described in this report comes from an Internet-based survey run in mid A total of 802 people completed all of the survey s questions, but only 148 reported having real-world experience implementing master data management. The completed surveys of these 148 respondents constitute the data sample for this report. To complement the survey-based primary research, TDWI also interviewed many data management practitioners (in IT departments and consulting firms) and received briefings from relevant software vendors. TDWI would like to thank those who contributed to this report. We appreciate the many users who completed our survey, especially those who responded to our requests for phone interviews. TDWI Membership Quarterly Q

2 Master Data Management Solutions Introduction As we ll see in this report, master data management (MDM) is practiced in many different ways, with many different tools and technologies, in response to many different technical and end user requirements. The dizzying array of options is itself a barrier to action. To help technical users clear the barrier, this report segments the leading practices, architectures, tools, technologies, and requirements of MDM. 1 Based on the segmentations of this report, a technical user should be able to identify an MDM practice that is appropriate to his/her organization, understand what combination of tools and technologies is required, then draft an evaluation list of vendor products that maps credibly to his/her requirements. The report can also help business people decide what role a software solution should play in leveraging master data and similar data assets. Overview of Master Data Management (MDM) Solutions In this report, the term MDM solution refers to software automation that enables the management of master data (and related information assets like reference data, metadata, and application codes) in a collaborative environment that includes both business and IT people. There are three basic MDM practices: operational, analytic, and enterprise. Architectural Approaches for MDM Solutions One way to segment MDM solutions is by architectural approach. These segments are meaningful because they are closely linked to fundamental end user requirements. These segments also determine what components an MDM technology stack will need. But MDM s architectural options can be difficult to sort out, because they are diverse: Analytic versus operational MDM. TDWI s survey asked users to identify architectural characteristics of MDM solutions they have implemented. Their responses show that MDM supports applications for business intelligence (32%), transactions (14%), or both (51%). (See Figure 1.) This reveals the most basic distinction in MDM practices: namely, analytic MDM versus operational MDM. The former is usually about data warehousing, while the latter is about an operational application. The two have very different technology architectures, and most companies need both. Embedded versus enterprise MDM. Another distinction involves MDM that is architected for specific applications (37%), broad infrastructure (28%), or both (32%). (See Figure 2.) The practices of analytic MDM and operational MDM just mentioned are examples of specific applications that embed MDM. But a third practice, called enterprise MDM, is architected as a standalone infrastructure that enables MDM across multiple, diverse applications. The traditional approach to MDM is to embed a specific form of it within a larger application, serving only that application. Enterprise MDM is an emerging practice for sharing centrally controlled master data across multiple applications of differing types. Built versus bought MDM solutions. TDWI s survey shows that most MDM solutions are homegrown from scratch (41%), though others can be developed on a vendor-built 1 Segmentation is an analytic method that reveals the constituent parts of a thing, then sorts the parts by criteria like cost, complexity, type, approach, technologies required, or applicability to a known goal. 8 TDWI Membership Quarterly Q

3 Overview of MDM Solutions tool (25%) or both (29%). (See Figure 3.) Although a few vendors offer an MDM application, few user organizations have bought one. Even so, most organizations of any size have bought a packaged application that embeds a form of MDM for that application (but no others). When MDM stretches across multiple applications (as in data warehousing or customer data integration), users almost always design and build their own solution. Physical versus federated/virtual data management. More architectural diversity is seen in data management, which can be physical (40%), virtual or federated (5%), or both (45%). (See Figure 4.) In phone interviews TDWI conducted, most users described a database, repository, or master file through which they integrate, transform, and physically relocate master data and related data. Others described a database or table within an application architecture that is the physical system of record or gold copy for master data. By comparison, virtual and federated approaches are rare in MDM solutions. Data federation and real-time operation are rare but growing characteristics of MDM solutions. Batch versus real-time operation. Given that most MDM solutions are wedded to physical data management, it s not surprising that synchronizing master data and propagating changes is usually done by physically relocating data offline in batch (32%), with real-time operation (15%) being relatively rare. (See Figure 5.) TDWI suspects that this will change, as user organizations move into enterprise MDM with centralized data definitions that are accessed by applications via services in real time to assure consistency and up-to-date data definitions. Describe the architectural characteristics of MDM solutions. 1. Supports applications for: 2. Focuses on: Don t know 2% Other 1% Don t know 1% Other 2% Business intelligence 32% Both 32% Specific applications 37% Both 51% Transactions 14% Broad MDM infrastructure 28% 3. Originated as: 4. Data management is: Don t know 3% Other 2% Don t know 9% Other 1% Both 29% Homegrown from scratch 41% Physical 40% Both 45% Vendor-built tool 25% 5. Operates: Virtual or federated 5% Don t know 5% Other 2% Offline in batch 32% Both 46% Online in real time 15% Figures 1 5. Based on 148 survey respondents. TDWI Membership Quarterly Q

4 Master Data Management Solutions Tools and Technologies Used in MDM Solutions As we ve shown, MDM solutions are complex in terms of the available architectural options and how these relate to end-user requirements and preexisting systems. But once you ve made your architectural choices, you still have even more choices to make, because each MDM solution requires a combination of tools that you must select and integrate. In fact, most MDM solutions are homegrown and require multiple tools, usually from multiple vendors, and involve integration with multiple information systems owned by multiple organizations. Therefore, complexity is the rule for the wide majority of MDM solutions. The number of tool types required varies by MDM practice. The simplest form is operational MDM, effected by functions embedded in a non-customized packaged application; these can be automatic without any implementation. The most complex form is enterprise MDM, where master data is shared across many applications of diverse types. Somewhere in the middle would be analytic MDM, as seen in the average data warehouse implementation. MDM solutions require fi v ed i f f e r e n tt o o l s,o n average. To quantify this problem, TDWI asked: Which types of tools does your organization use to implement MDM? (See Figure 6.) The 148 survey respondents gave 729 responses, suggesting that, on average, an organization uses five types of tools in an MDM solution. Technical users who are new to MDM often ask whether they should build their solution by customizing an existing application, modeling a new database to house master data, or deploying an integration tool to move master data around. The answer no one likes to hear is, All of the above and possibly more. As with similar practices (like data warehousing and customer data integration), master data management is almost always a multi-tool solution. Which types of tools does your organization use to implement MDM? Database management system (DBMS) Extract, transform, and load (ETL) Data modeling Data quality Metadata repository Operational data store (ODS) Enterprise application integration (EAI) File transfer protocol (FTP) Packaged application Enterprise information integration (EII) Replication Other 4% 18% 17% 32% 32% 29% 50% 46% 44% 78% 73% 69% Figure 6. Based on 729 responses from 148 survey respondents. Another way to segment MDM solutions is by the type of tool or technology used or, in most cases, the combination of tools and technologies. To illustrate common tools, technologies, and their relationships, Figure 7 presents a technology stack for MDM. This rendering represents enterprise MDM, which would include the greatest diversity of tools and technologies. Other possible stacks would be subsets of the one shown. Let s drill into the segments of the MDM technology stack in Figure TDWI Membership Quarterly Q

5 Overview of MDM Solutions Upstream Operational Applications ERP Collaborative Environments Master data creation: Data & biz modeling Design & development Study & audit Authorize & publish Master data browsing: Views for tech/biz users Annotations & threads Search Browse taxonomy Downstream Target Applications EDW CRM Master Data Repository CDI SCM Data Quality Technologies Validation, cleansing, enhancement, etc. PIM Finance Integration Technologies EAI, EII, ETL, FTP, replication, SOA, etc. FPM Closed Loop back to Operational Apps Sometimes done in operational or enterprise MDM. Figure 7. A complete technology stack for enterprise master data management. Databases of various types. In TDWI s survey, users identified database management systems (DBMSs) as the most common technology piece for MDM (78% in Figure 6). This is not surprising, given that databases are all over the MDM technology stack as part of both source and target systems. And the master data repository the critical hub of the solution is usually a specialized database, like an operational data store (ODS, 44%) or metadata repository (46%). Master data repository. This can take many forms, including a table within an application s database, a separate mid-tier relational database (i.e., ODS), or a flat file dumped from the system of record (from which master data will be propagated to other applications). However, many users rely on a metadata repository (46%) because it is well-suited to the integration and sharing requirements of master data. In fact, many of the users TDWI interviewed either closely linked the management of master data and metadata, or claimed there s no distinction at all. The metadata repository may be part of a larger tool or an independent tool unto itself. Regardless of the form it takes, the master data repository is extremely important as the center of the technology stack. It imposes a hub-and-spoke architecture where the repository is the hub and integration interfaces provide spokes to source and target systems. Integration technologies. Most users TDWI interviewed consider MDM to be an integration practice, akin to the data integration that is core to data warehousing or the application integration that is part and parcel of modern distributed architectures. Accordingly, users surveyed assigned high rankings to integration technologies like extract, transform, and load (ETL, 73%), enterprise application integration (EAI, 32%), file transfer protocol (FTP, 32%), enterprise information integration (EII, 18%), and database replication (17%). Furthermore, a few survey respondents The master data repository is the heart of an MDM solution. Integration technologies extend the reach of the master data repository. TDWI Membership Quarterly Q

6 Master Data Management Solutions selected other and wrote in Web services and SOA. An MDM solution of any complexity will require multiple integration technologies to collect and propagate master data. Data quality technologies. In many users minds, the point of MDM is to improve data and its usage. For these users, it s natural that managing master data entails data quality measures, as do related practices like data integration and metadata management. Half of survey respondents listed data quality as a component of an MDM solution. (See Figure 6.) Collaborative environments. The most amorphous region in the MDM technology stack involves collaborative tools. Users tend to apply a wide variety of data modeling and business process modeling tools here, plus functions of integration tools, applications, and portals. One of the goals is for technical and business people to collaborate via the creation and consumption of master data, which doesn t necessarily require a dedicated software tool. Instead, collaboration may best be served by organizational structures that bring technical and business users together, namely data stewardship programs and data governance committees. 2 Most MDM solutions today operate offline and one-way, but enterprise MDM will change this to real-time, closed loops. Closed loop. Analytic MDM solutions all have an explicit flow of master and reference data from upstream source applications to downstream target databases, similar to how other data and metadata flow in these solutions. In fact, the same tools and infrastructure typically support all these flows, especially in a data warehouse implementation. In other MDM practices, however, the flow may complete a loop, where masters are defined centrally at the repository, then imposed on operational applications for cross-application consistency. The leading requirement for closed-loop MDM is that master data must be decoupled from individual applications (whether operational or analytic) and be given to a central authority to control. This is no small feat, since not all applications or their owners! will allow a loss of control. Yet, a closed loop is necessary when organizations need to synchronize multiple applications via operational MDM or share master data broadly via enterprise MDM. Vendor Tools for MDM Segmenting vendor offerings reveals the types of tools seen in the middle of the MDM technology stack (Figure 7). When it comes to selecting tools to integrate into an MDM solution, tools for database management, metadata management, and data integration present the most challenges. Let s look at these segments and a few representative vendor products within each that an MDM implementer might consider for use. Database Management Systems As noted earlier, databases are all over the MDM technology stack, since they are key components of operational applications, downstream databases, and the central master data repository. Obviously, numerous software vendors like IBM, Microsoft, Oracle, Sybase, Teradata, and so on offer database management systems (DBMSs) that serve multiple purposes. Users select these DBMSs for their ability to support the operational or analytic applications with which they are 2 For more details, see the chapter Organizational Best Practices for MDM in TDWI s report Master Data Management: Consensus-Driven Data Defi nitions for Cross-Application Consistency (included in this Member mailing; also available at 12 TDWI Membership Quarterly Q

7 Vendor Tools for MDM associated. In other words, the MDM implementer rarely has influence on the selection of DBMSs, yet must design an MDM solution that integrates with these preexisting systems. Even if technical users design an ODS as a master data repository, they are usually forced to build it atop a DBMS brand that is already established in the organization. Instead of selecting a DBMS, the MDM implementer must select other products (like tools for metadata management or data integration, or perhaps applications for MDM) that support preexisting DBMSs deeply via native gateways, APIs, and other proprietary functions. Databases aside, this also applies to other preexisting systems, like operational applications, analytic applications, and corporate portals. Indeed, one of the toughest tasks the MDM implementer must tackle is designing a solution that will retrofit onto diverse, preexisting systems. An MDM solution must work with existing databases and apps, and rarely has the option of replacing or altering them. Metadata Management Tools and Repositories Most of the users TDWI interviewed for this report spoke of master data technology stacks that depend heavily on metadata management tools and practices. For some users (especially those doing analytic MDM, and sometimes those doing enterprise MDM), master data management is a variation or extension of metadata management. For them, it makes sense to conduct master data management via metadata management infrastructure (applying the same tools and similar techniques to reference and master data that they re already applying to metadata). Choosing the right metadata management tool and repository is critical to MDM success. The catch, in terms of tool selection, is that metadata is everywhere, so its management is almost as ubiquitous. Data warehousing professionals complain that their productivity is dragged down by the time-consuming and error-prone manual task of exchanging metadata between the repositories of their tools for data modeling, data integration, report writing, and database management. Any MDM implementer choosing the metadata management route must minimize metadata exchange by addressing the question: Which tool has metadata management that will work broadly with master data and, therefore, should become my central master data repository? This question has three possible answers: Select a tool that has an accessible metadata repository and use this for the master data repository. With analytic MDM, this is usually a data integration tool for extract, transform, and load (ETL), like market-leading products IBM DataStage and Informatica PowerCenter. For operational MDM, some packaged applications include a repository (like BW with SAP) or an equivalent collection of tables in the application database (Siebel). Although these are somewhat open and extensible, they are designed for the larger product in which they are embedded, and so may have limitations beyond those. Deploy a standalone metadata repository designed for enterprise-scope use. Marketleading products include ASG-Rochade and Computer Associates AllFusion Repository. (See Table 1.) These are designed for cross-application enterprise use, unlike most embedded metadata management tools and their repositories. Users can build custom applications atop these repositories, and ASG offers an analytic MDM solution that runs atop Rochade. The use of such a tool assumes a central master data repository, which is a requirement for enterprise MDM solutions. For MDM solutions that must operate in real time or in a closed loop, these standalone metadata management tools support a wide variety of interfaces, Web services, and service-oriented architecture (SOA). TDWI Membership Quarterly Q

8 Master Data Management Solutions Build your own repository atop a relational DBMS. This option is a good choice when dealing with large volumes of master data in batch, although it demands considerable development resources and doesn t handle change well. For example, TDWI interviewed users who rely on Teradata Warehouse for processing, storing, and propagating master data as part of an analytic MDM solution. Most Teradata shops have personnel who are wellversed in hand-coded SQL, and the Teradata platform is far more scalable than the average single-purpose metadata repository. Standalone Metadata Management Vendors Vendor Name Product Name Web Site ASG ASG-Rochade Computer Associates AllFusion Repository MetaMatrix MetaMatrix for Master Data Management Table 1. Representative vendors and products for standalone metadata management. An ETL tool (and possibly its metadata repository) are core to analytic MDM solutions, and sometimes CDI and PIM applications, too. Data Integration Tools Extract, transform, and load (ETL) is the preferred type of data integration for data warehousing and, therefore, for analytic MDM. Furthermore, all ETL tools have metadata management with a repository, although capabilities vary. (See Table 2 for a list of representative ETL tools.) Hence, an MDM solution for data warehousing and business intelligence usually has an ETL tool at its heart. The leading alternative in analytic MDM would be a homegrown master data repository based on the data warehouse s DBMS or ODS. The same is true (to a lesser degree) of MDM solutions for customer data integration (CDI). When enterprise MDM is an extension of the data warehouse environment (a common occurrence), ETL again plays a significant role. 3 Extract, Transform, and Load Vendors Vendor Name Product Name Web Site Business Objects Data Integrator IBM WebSphere DataStage Informatica PowerCenter Advanced Edition Sunopsis Active Integration Platform Table 2. Representative vendors and products for ETL. Operational MDM is a bit different. When the synchronization of master data across multiple application instances can be done from one application database to another, then data integration tools of various types are appropriate. If, however, shared master data must go through application logic, a tool for enterprise application integration (EAI) may be required, like IBM WebSphere MQ or TIBCO BusinessWorks. 3 Similar to ETL tools, data quality tools may be applied to master data. For a survey of data quality tools, see the report Enterprise Data Quality Tools, published in the TDWI Membership Quarterly in second quarter TDWI Membership Quarterly Q

9 Vendor Applications for MDM Vendor Applications for MDM A number of vendors have reduced the complexity of implementing MDM by consolidating many of its required functions within a single application product. These applications segment into three general categories: general master data management (MDM), customer data integration (CDI), and product information management (PIM). A fourth possible category would be financial performance management (FPM), but this practice is usually accomplished via a general MDM application, an enterprise data warehouse (EDW), or a homegrown solution. These are all downstream target applications, as seen on the right side of Figure 7. Applications for General MDM TDWI Members regularly ask about applications for general MDM, so here are detailed summaries of some representative products. (See Table 3.) Click Commerce Master Data Management (MDM) Solution. This solution combines data services, patented search, and data management tools, enabling companies to consolidate, cleanse, and harmonize master data repositories within an extended enterprise. In other words, it supports master data exchange across companies practicing enterprise MDM, and even beyond to partnering companies. A good choice for B2B operations. Hyperion MDM Server. Designed for analytic MDM and usually applied to financial performance management (FPM). Like Kalido, Hyperion provides best-of-breed hierarchical management and change control. Its excellent functions for financial data stand out, but customers also use it with product, customer, and other data entities. The application (acquired from Razza) includes a hub that can persist data to disk or in a memory cache with data federation and changed data capture. It s strong on versioning, especially for time dimensions with before/after views of data. The user interface enables business and technical users to collaborate. Hyperion and Kalido fi tw e l li nl a r g e organizations where change is frequent and deep. Kalido MDM. Designed for analytic MDM in the context of a large enterprise data warehouse (EDW). Like Hyperion, Kalido provides best-of-breed hierarchy management and change control. Its innovative virtual data management enables views of warehouse data both before and after major change events (like reorgs and acquisitions), and it buffers the MDM solution (and Kalido s data warehouse solution, too) from changes to source applications and their data. Customers tend to be very large multinationals, doing MDM with financial, customer, product, and other data. It s strong on modeling tools that enable business and technical people to control master data in the context of a comprehensive business model. SAP NetWeaver MDM. Designed for SAP-centric organizations where prominent business processes are supported by SAP applications. It has strong functions for both operational MDM and analytic MDM, and through the integration capabilities of NetWeaver this solution can integrate third-party products in support of enterprise MDM. In fact, TDWI interviewed users who are making substantial investments in NetWeaver (which opens up SAP applications considerably) expressly to enhance data warehousing and MDM functions. It s an excellent choice if you re already using SAP s packaged applications and NetWeaver, which this solution requires. The SAP customer base has high confidence in NetWeaver s MDM and integration capabilities, though few are using them deeply (yet). Silver Creek DataLens System. Patented solution for product data quality that can be applied to master data. The DataLens System is strong on matching records of unpredictable syntax and structure (like product data or master data) based on semantics via natural language processing TDWI Membership Quarterly Q

10 Master Data Management Solutions (NLP). It doesn t store anything (it s a pipe), so it s inherently real-time in operation. DataLens can operate as a standalone solution, although many customers use it embedded within integration products by Endeca, IBM, Oracle, and SAP. Stratature Enterprise Dimension Manager (+EDM). This solution features a multidimensional approach to modeling master entities, with a central, dimensional database as the hub. It offers branching or straight-line versioning, and is strong on the integration and reconciliation of master data in dimensions and hierarchies. +EDM enables business people to manage their own dimensions in collaboration with IT. Master Data Management Vendors Vendor Name Product Name Web Site Click Commerce Master Data Management Solution Hyperion Hyperion Master Data Management Server Kalido Kalido MDM SAP SAP NetWeaver MDM Silver Creek DataLens Builder Stratature Enterprise Dimension Manager (+EDM) Table 3. Representative vendors and products for packaged MDM applications. Like customer data, customer master data suffers quality issues. Applications for Customer Data Integration (CDI) Obviously, a CDI application focuses on integrating and propagating customer data. What s not so obvious is that almost all CDI applications have significant MDM functions embedded within them. This helps to achieve a goal that CDI shares with MDM: well-thought-out definitions of customer that are applied consistently across applications. Furthermore, customer data and customer masters are subject to errors, so CDI apps also include data quality (DQ) functions. Hence, CDI is an application type that relies on the MDM and DQ functions embedded within it. Due to its heavy reliance on data integration and the fact that it regularly supports customer analyses of various types, CDI s brand of MDM usually resembles analytic MDM and the technology stack commonly seen in data warehousing. But some CDI applications are applied to customer-centric transactional applications, which makes CDI look like operational MDM, sometimes with a real-time or closed-loop capability. See Table 4 for examples of CDI applications that represent the gamut of CDI and MDM approaches. DataFlux CDI Solution. This CDI application is built atop the data quality platform called DataFlux Integration Server. This is natural, since both customer data and master data about customers suffer data quality problems systemically. DataFlux technology provides the ability to build detailed data quality and data integration routines to standardize, match, and enhance data as it moves into the master reference file. Then you can propagate master data and its business rules in real time, helping to ensure that data arriving at the data hub remains consistent, accurate, and reliable over time. 16 TDWI Membership Quarterly Q

11 Vendor Applications for MDM IBM WebSphere Customer Center. Like most CDI solutions, WebSphere Customer Center (acquired from DWL) is built around a central database as the hub. Unlike most, however, it was built for real time (as well as batch), utilizing SOA and open standards as integration spokes beyond the hub. It s designed for customer data in the context of transactional applications (i.e., operational MDM), but in some configurations its central database might contribute to analytic MDM solutions. Oracle Customer Data Hub. This is another hub built around a central database (in this case, Oracle Data Server), and it specializes in the continuous synchronization of customer data in real time, if you need it. It features a broad set of capabilities, including deduplication, matching, customer key management, process integration, and ongoing monitoring. Though designed for mostly Oracle data sources and targets, it works with other Oracle Fusion Middleware products to reach any source or target for customer data inside or outside the enterprise. It s a great choice for organizations with numerous Oracle products and Oracle-trained personnel already in place. Like SAP NetWeaver, Oracle Fusion integrates a family of apps, plus MDM and other integration functions. Purisma Customer Registry. Designed for customer identity management (CIM) via CDI, with some MDM capabilities. Siperian Hub. Originally designed as a customer data hub for CDI, Siperian Hub today continues its focus on customer data, though some users apply it to data about other entities. It works well in situations where customer data and master data needs to be synchronized and reconciled across multiple operational applications. Some users do so on an enterprise scale, and some enhance a data warehouse with dimensional data from Siperian Hub. It supports CIM across multiple customer and data integration interactions. Customer Data Integration Vendors Vendor Name Product Name Web Site DataFlux DataFlux Integration Server IBM WebSphere Customer Center Oracle Customer Data Hub Purisma Purisma Customer Registry Siperian Siperian Hub Table 4. Representative vendors and products for customer data integration (CDI). Applications for Product Information Management As with CDI, product information management (PIM) is an application type that relies on the MDM and DQ functions embedded within it. The style of MDM embedded in PIM is usually operational rarely analytic. As with CDI, PIM controls data definitions as it synchronizes data, and real-time operation is sometimes a requirement. Table 5 shows examples of PIM applications representing various PIM and MDM approaches. A successful PIM application will integrate well with existing supply chain applications and the systems of external partners. i2 Master Data Management. Designed for product data, plus planning data. i2 s product includes components for specific applications: i2 MDM for Planning Data and i2 MDM for Product Information. This is a good choice for best-of-breed PIM. 4 4 Due to a recently announced agreement, Teradata now resells i2 Master Data Management, an operational MDM solution that complements the analytic MDM many Teradata users are already doing. TDWI Membership Quarterly Q

12 Master Data Management Solutions IBM WebSphere Product Center. Designed for managing location master data, especially multiple location hierarchies and item-location relationships. WebSphere Product Center (acquired from Trigo) provides a repository for managing and linking information about product, location, trading partner, organization, and terms of trade. Master data synchronization reaches internal enterprise systems and external trading partners. Oracle Product Information Management Data Hub. Similar to Oracle Customer Data Hub, Oracle Product Information Management Data Hub is the component of Oracle Fusion Middleware that integrates product information from heterogeneous systems into a single central product repository, from which it can be synchronized across applications and their functional departments. As it integrates, the Data Hub improves the definition, completeness, and quality of product data and product-centric master data. It s a good choice for use with other Oracle products. TIBCO Collaborative Information Manager. Focused on consumer packaged goods and retail, with data models and business-rule libraries for these industries. Most customers manage product master data, but other data domains are possible. Data management is process-based via a rules engine and rules design tool. Tools are Web-based for broad collaboration. The product data and master data repository can reside in any RDBMS; most configurations are physical, but data federation is possible. This product (acquired from Velosel) doesn t require other TIBCO products, though it works well with them, especially for real-time integration. Product Information Management Vendors Vendor Name Product Name Web Site i2 i2 Master Data Management IBM WebSphere Product Center Oracle Product Information Management Data Hub TIBCO Collaborative Information Manager Table 5. Representative vendors and products for product information management (PIM). Recommendations Users planning a new MDM solution (or the expansion of an existing one) should keep the following points in mind: Start with business requirements. MDM is similar to data quality in that you need to first discover prominent business pain points, and alleviate these by improving and sharing master data. Typical pain points that MDM can address include poor product planning, lackluster customer service, dubious decision making, and inaccurate financial or regulatory reports. Preexisting IT systems heavily influence MDM solutions. Consider preexisting IT systems as starting points for an MDM software solution. Incumbent systems influence how MDM is retrofitted or grown from what s already there. After all, business pain points are usually associated with such systems, and these probably 18 TDWI Membership Quarterly Q

13 Recommendations support some form of MDM already, which you will extend (via integration techniques) and/or replace (with a standalone MDM application, whether homegrown or vendor-built). Hence, MDM is a balance of preexisting systems and newly added functions. Note that preexisting systems may impose an MDM architecture. For example, you d probably choose to practice analytic MDM through your existing data warehouse infrastructure, which already has a technology stack with inherent architectural approaches. Likewise, extending operational MDM means extending an application for ERP or CRM, which has a predetermined technology stack and architecture. You must work within these, unless you re willing to build an additional MDM technology stack or buy one in the form of a vendor s MDM application. Enterprise MDM makes more sense as a standalone stack, as opposed to an extension of a stack for another purpose, like warehousing or ERP. But if you deploy a separate stack for MDM, you ll still have to tie it into existing systems. Expect to use an increasing number of tool types. As we saw from TDWI market data, organizations use an average of five tools for an MDM solution. Besides the tools and platforms determined by preexisting systems, expect to add integration tools of various types and perhaps an independent repository. As early as possible, assess what kind of data quality measures master data will require and add tools or homegrown functions as needed. Even if you acquire a vendor s packaged application for MDM, CDI, or PIM, you ll probably have to add your own integration and quality tools, so beware these hidden costs. Establish a master data repository as the hub in your MDM architecture. The repository can take many forms, as described in this report. Regardless of which form you use, the hub is critical to IT and business processes for creating, collecting, authorizing, and distributing master data. Without an accessible, well-integrated hub, these processes are in peril. MDM is often a multi-tool affair, which entails cost, complexity, and system integration. The master data hub is critical, so put your best efforts into its model and interfaces. Look ahead to advanced requirements like closed loop and real time. Expect these to intensify as you go deeper into enterprise MDM. To enable these, you ll need a master data repository supporting interfaces that can operate in real time and/or reach many operational applications upstream. Look to Web services and SOA as part of the solution. Advanced requirements are more complex and costly than others, so address them only if you must. Collaborate with colleagues across functions. The point of MDM is to develop consensus-driven definitions of key business entities, then share and apply them consistently. A few tools may help, such as portals or modeling tools that support both IT and business users, but there s no substitute for the collaboration fostered by cross-functional groups, like a data warehousing team, stewardship program, or data governance committee. MDM is about people sharing data, which requires collaboration. TDWI Membership Quarterly Q