E X E C U T I V E B R I E F

A GPS for Your MDM Journey:The Right and Wrong Master Data Management (MDM) Strategies to

Start Small and Expand across the Enterprise

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 2010

1A GPS for Your MDM Journey

Executive Brief

Table of ContentsExecutive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Beware of Technology-Focused MDM Strategies . . . . . . . . . . . . . . . . . . . . . 3

Starting Small the Wrong Way Can Limit You from Successfully Expanding MDM across the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

A Business-Focused Approach is the Right Way to Start Small, Succeed and Expand across the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Successfully Expand MDM across the Enterprise . . . . . . . . . . . . . . . . . . . . . 5

Examples of Successful Multidomain MDM Journeys . . . . . . . . . . . . . . . . . . 8

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

2

Executive SummarySome visionary companies saw the benefits of empowering the business with desktop access to reconciled and reliable business-critical data—also known as master data—across the enterprise, empowering employees to effectively address business priorities. They realized that inconsistent and duplicate business-critical data—such as customers, products, partners, and suppliers—stored in different formats in disparate systems across the enterprise can impede strategic business imperatives, such as acquiring and retaining customers, making operational efficiency as a competitive differentiator, accelerating speed-to-value from acquisitions, and supporting informed decision-making across the enterprise. These companies were early adopters of multidomain master data management, (MDM) who have realized significant business benefits from the first phases of their initiatives.

Consequently, these multidomain MDM pioneers have further expanded the usage of their technology to solve other pressing business problems, and in doing so have proven the effectiveness of MDM throughout the enterprise. Now that MDM has caught the attention of the mainstream, companies that are evaluating MDM are looking for strategies to be successful, not only with their initial deployment, but also with their efforts to expand the use of multidomain MDM across the enterprise.

In response to growing demand, many industry analysts have published a flurry of maturity models advising mainstream MDM users how to get started on their MDM journeys, with the goals of reducing project risk and decreasing the data governance burden. Typically these technology-focused models include the following recommendations:

Start small with a single data type such as customer and then adding other domains like •product.

First implement MDM using a small footprint such as registry style and then migrating the •architecture to other styles such as hybrid, collaborative or transactional.

Deploy MDM solely with a data warehouse initially to improve reporting. Integrate it with •operational systems later to improve erformance.

Inherently these technology-focused approaches advocate starting with a simple deployment of a single MDM implementation and developing the implementation along a technology maturity curve. Companies may readily adopt these approaches as perfectly reasonable implementation methodologies in an effort to take a more risk-averse approach to their MDM implementation. By following the advice above, companies simply cannot to solve the most pressing and difficult business problems. This approach limits the scope and potential return on investment (ROI) from MDM, thereby decreasing the probability that MDM will be expanded throughout the enterprise.

This white paper points out the limitations of a technology-focused approach to MDM. It explains how a business-focused approach to MDM will set you up for a win by increasing the business value of your initiative, then enable you to expand your MDM system successfully across the enterprise. This white paper concludes with specific examples of companies in the pharmaceutical, banking and insurance industries, who have leveraged MDM to solve a pressing business problem in a particular department or division, delivered immediate results, and then leveraged their investment to address additional business problems in other departments, divisions and regions.

Executive Brief

3A GPS for Your MDM Journey

Beware of Technology-Focused MDM Strategies For the full MDM journey to be successful, the initial MDM deployment must be successful. The following business cases illustrate the results of restricting the initial phase of your MDM initiative to a single master data type, registry style and to analytical usage:

The result of restricting your deployment to a single domain: • A manufacturing company has a strategic imperative to optimize its supply chain processes, both on the buy-side and sell-side. Their goal is to more effectively manage the procurement of direct and indirect materials from vendors and the distribution of its products to its customers. Based on this information, the MDM technology that will be leveraged to solve this business problem must be able to manage the following types of master data: vendor, customer, material and product. Starting with only one of these would severely constrain the usefulness of an MDM solution for supply chain improvements.

The result of confining MDM to a registry approach: • A financial services company was pursuing the strategic imperative of improving risk management, more accurately calculating capital reserve requirements, and complying with Basel II regulations. This requires the ability to reconcile conflicting counterparty master data and legal hierarchies and store them centrally for immediate access. In this case, a registry approach would only identify counterparties as duplicates without consolidating this data into a “single version of the truth” and leveraging the correct definition for the counterparty. As a result, credit risk managers would be unable to determine which counterparty definition is current and accurate. In addition, a registry approach cannot identify the legal hierarchies required to calculate the aggregated risk exposure. Consequently, the credit risk managers would need to go through a lengthy process to determine the correct entry and combine information from different systems to arrive at that single definition and legal hierarchy representation. From that point forward, the information would act as the single best source of information for all credit risk calculations. A small footprint using the registry approach would not effectively solve this difficult business problem.

The result of limiting MDM to analytical usage: • A pharmaceutical manufacturing wanted to use MDM to improve the order-to-cash process, which requires the synchronization of reliable master data to operational systems, such as order management. Where the master data is only synchronized to a data warehouse, the efficacy of the order-to-cash business process cannot be improved since this process is inherently operational in nature. Therefore, limiting your MDM to analytical applications limits the business value that can be achieved. Measurable hard dollar benefits require the use of MDM for operations and business process improvements.

4

Starting Small the Wrong Way Can Limit You from Successfully Expanding MDM across the Enterprise While taking a technology-focused approach may enable your organization to get started with MDM quickly, it may not effectively solve your most pressing business problems or deliver the significant business value that is achievable. With this approach, the MDM project runs the risk of being perceived as another IT initiative incapable of addressing business needs, which will make it increasingly difficult to further evolve or extend the solution across the enterprise. In addition, a technology-centric start will not fulfill the most important needs around enterprise master data governance.

It is important to know that some MDM vendor technologies only support a single architecture style such as registry or can only be deployed for a single usage–either operational or analytical. These technologies cannot be extended to other architectural styles or address other types of business problems across the enterprise. Since these technologies can be deployed only for a single use, a different MDM technology, possibly from a different vendor, is required to solve the next critical problem. This approach opens a Pandora’s Box–first, it costs more to build two MDM systems, thereby significantly reducing the ROI; second, the investment, effort and skills from the first MDM implementation cannot be leveraged for the second one, which significantly increases the total cost of ownership (TCO); and finally, the two systems are not integrated or able to share information which ultimately leads to MDM silos. Ironically, instead of starting small and expanding across the enterprise, you will start small and then have to start again.

A Business-Focused Approach is the Right Way to Start Small, Succeed and Expand across the Enterprise Multidomian MDM is about empowering the business with consolidated and reliable business-critical data, such as customers, products, partners, suppliers, and so on—also known as master data—across the enterprise, to effectively address business priorities and improve operations. Consequently, how an MDM solution is implemented depends foremost on which business problems are being tackled. A business-focused approach to MDM enables you to generate significant business value as well as a strong ROI in a short timeframe. Based on this success, you can then leverage your investment and expand your MDM system to address other high-value business problems across the enterprise.

Set Yourself Up for an MDM Win How do you get started? A pragmatic place to begin is to answer these three questions:

Which pressing business problems need to be addressed quickly? Start by identifying the 1.business problems that are high value, and among those, which ones should be addressed first. By choosing a business problem to start with, the master data types that need to be managed will become evident. For example, two business processes within a company’s supply chain are driving up costs: different divisions within the company are procuring direct materials from the same vendor at different contracted rates, and sales people are competing for the same customer’s business with different prices. The master data integral to improving these business processes are vendor, contract, customer, materials and product.

How will the data be used? Next identify how business users will use the master data within 2.their business processes in order to determine the most appropriate architectural style and usage modes to support their needs. As an example, to ensure that employees across the

Executive Brief

5A GPS for Your MDM Journey

enterprise are leveraging the same contracted rates when procuring direct materials from a supplier, the MDM system needs to reconcile conflicting vendor, contract and direct materials data and then centrally store it–an architectural style analyst call coexistence or transactional. The data also needs to be made available to the supply chain and contract management systems. In order to ensure sales alignment, the MDM system needs to make customer and product information available to the data warehousing system for accurate and timely analysis and reporting.

What are the business requirements for master data governance? It is important to understand 3.the business requirements for governing master data to determine the requirements for master data availability, usability, integrity and security. For instance, the procurement department will require a high degree of integrity for vendor and contract data, and will need to be able to make this data available to procurement agents in real time. The contract negotiation team, on the other hand, may require the same degree of data integrity, yet not in real time. Similarly, the sales team may have a requirement that only sales managers are able to perform sales force alignment, while sales representatives only have access to information for their assigned territory.

What becomes obvious from these examples is that MDM will almost always require a multidomain deployment (such as customer and product) and an architectural style that is not restricted to registry. In most instances, synchronization with both operational and analytical systems may also be essential to effectively address the specific business needs of your organization.

By taking a business-focused approach to MDM, you can provide a complete solution to the most challenging of business problems–using only the required master data, implemented with the correct solution architecture, deployed for the correct business use and with the correct data governance structure. When a pressing business problem is successfully solved by an MDM solution, adoption of the solution dramatically increases among business users because it helps them achieve strategic business imperatives, such as increasing revenue with improved cross-sell and up-sell, improved risk management and compliance by better managing counterparties across the enterprise, streamlining operations, etc. Starting with a defined business problem allows you to start small and demonstrate success to build a case for expanding the MDM system to other departments, divisions and regions. Once business users experience the benefits of an MDM solution they will more readily support its use in other areas–paving the way for an enterprise-wide multidomain MDM system, which acts as a foundation for providing consolidated and reliable business-critical data to all systems.

Successfully Expand MDM across the Enterprise Incomplete, inconsistent and duplicate data rarely are confined to a single business problem. Having solved the most critical of business problems with a MDM solution, the focus can now turn to solving the next critical business problem. For instance, a financial services company that used multidomain MDM initially to improve risk management within the company might now focus on solving issues in trade processing. Likewise, a pharmaceutical company that used multidomain MDM to solve physician spend reporting compliance might now focus on solving issues in sales territory alignment.

6

The Key to Successful Expansion: A Flexible MDM Technology Companies that are now exploring MDM strategies can benefit from the success or failure and learned experiences of early adopters. As part of a complete due diligence, it is recommended that you speak with some of the MDM pioneers and ask the following questions:

Questions to determine a successful start:

What was the business problem for which they initially procured an MDM technology? •

Did the technology provide the flexibility to support the architecture required to solve the •business problem? Why or why not?

Is the MDM technology currently in production and actively used for the purpose for which it •was deployed? If not, why?

What was the duration of the implementation and ROI was realized from the initial deployment? •

Did the company initially select an MDM technology that was not able to solve the defined •business problem, and did the company subsequently choose another MDM technology? If yes, what were the shortcomings of the failed technology?

Questions to determine a successful expansion:

How has the company evolved their initial MDM solution to solve other business problems •within their organization? (Not from a technology maturity standpoint but from a business-focused approach?)

Was the company able to reuse the same MDM technology, learning and integration process •for subsequent business problems to help accelerate the implementation of subsequent solutions? If not, what constraints led the company to choose a different MDM technology? And how does the company integrate these disparate technologies? (if they don’t, it might lead to MDM silos)

What were the duration of the implementation and the ROI of the subsequent deployments? •

If the company is planning subsequent deployments, but hasn’t yet begun, do they feel •confident that their current technology will support the architecture required to solve other business problems?

What you will learn from these answers is that no two MDM journeys are the same. Companies within the same industry might approach MDM strategy quite differently–some may use a single, enterprise-wide MDM system to solve all of their business problems while others may use local MDM systems for each of their divisions and roll them up to a global enterprise-level MDM system. An approach that might work for one company might not necessarily work for another company. Whatever the approach may be, or even if you do not plan to evolve the solution beyond the initial deployment for now, the best insurance is to have a proven and flexible multidomain MDM technology capable of supporting both the current and future requirements of your company.

Executive Brief

7A GPS for Your MDM Journey

Comparison of Approaches

Technology-Focused MDM Journey

Business-Focused MDM Journey

Start Small and Achieve Significant Business Value

Key Purpose Reduce project risk Solve the most critical business problem

Approach taken for …

Entities Start small with a single data type such as customer

MDM deployments are multi-entity (business problems are not confined to a single entity)

Styles First implement MDM using a small footprint such as registry style

Architectural style is not restricted to registry alone

Usage Initially deploy MDM solely with a data warehouse

Synchronization with both operational and analytical systems may also be essential

Data governance

Relieve data governance burden

Correct data governance structure

Implication May limit the scope and potential return on investment (ROI)

Provides tangible business value and significant ROI in a short-term timeframe

Successfully Expand MDM across the Enterprise

Key Purpose Grow big by growing the complexity of a single MDM implementation along a technology-maturity curve

Solve the next and subsequent critical business problems

Approach taken for …

Entities Add other entities such as product

Use only the required master data

Styles Migrate the architecture from registry to other styles such as hybrid, collaborative or transactional

Implemented with the correct solution architecture

Usage Integrate with operational systems

Deploy for the correct business use

Data governance

Relieve data governance burden

Correct data governance structure

Implication Leads to MDM silos. Instead of starting small and growing big, you will start small and start again

Adoption of the solution dramatically increases among business users because it eliminates inefficiencies and improves productivity resulting in measurable cost savings and higher ROI

Figure 1: Comparison of Approaches

8

Examples of Successful Multidomain MDM Journeys Below are some examples of successful multidomain MDM journeys in the pharmaceutical, banking and insurance industries. What follows is an explanation of some typical business problems faced by companies in these industries and how they have deployed MDM to solve these problems. What becomes obvious from these examples is that greater value accrues to each of these companies when they are able to use the same MDM technology to not only solve the initial business problem; but also, to address subsequent business problems. This is because they are able to leverage the investment and learning from prior implementations by reusing the technology.

Pharmaceutical MDM Journey Pharmaceutical companies have been early adopters of multidomain MDM technology. These leaders typically began using multidomain MDM on a single platform within a single department such as sales, marketing, compliance, human resources or supply chain and within a defined geographic region to solve a specific business problem. Having experienced significant business value and success with an initial deployment, many of these companies chose to expand their MDM system to address additional business problems within other departments and geographies. These early adopters teach an important lesson for those looking to adopt multidomain MDM on a single platform—start small by addressing a pressing business problem, then expand the use of your MDM system to address business problems in other areas. Here are some of the business areas where pharmaceutical companies have typically deployed multidomain MDM:

1 . Physician Targeting

Insight into prescriber behavior demographics and prescribing behavior is at the center of effective sales strategies, but is highly complex as a result of the inaccuracy of data residing in most Customer Relationship Management (CRM) systems and the variety of data formats from third party aggregators. Third-party data in particular can be difficult to integrate into internal systems and is often delivered with a two month time lag. Yet, pharmaceutical companies need to overcome these data challenges in order to perform effective sales territory alignment, market segmentation and marketing analytics. To overcome this problem they use multidomain MDM to create a single view of prescribers, integrated delivery networks, hospitals, group purchasing organizations, accounts and affiliations across their CRM, Enterprise Resource Planning (ERP) systems and third party data. With MDM in place, pharmaceutical companies have been able to more accurately target key physicians over others, accelerate commission processing and produce insightful sales management reports to enable them to quickly react to changing market conditions.

2 . Compliance with Physician Spend Reporting Regulations

Many pharmaceutical companies have found it difficult to meet the requirements of new state-level physician spend reporting regulations in a timely fashion, which resulted in these companies being charged with expensive fines. To comply, they need to track and report their expenditures on each physician by expense type. In some cases they need to demonstrate that they have not exceeded a specific amount of expenditure on each physician, based on each state’s spending cap laws.

Executive Brief

9A GPS for Your MDM Journey

Pharmaceutical companies struggle to comply with these regulations because physician and payment data are stored in different formats and multiple systems across the enterprise. Payment data may reside in several payment systems such as reimbursement, grants or accounts payable. And these systems may reside within different organizational boundaries across sales and research and development, while the physician data found in each are often unreliable and inaccurate. To solve this challenge, pharmaceutical companies have deployed multidomain MDM on a single platform to create a single view of physicians, hospitals and affiliations so that the many different forms of physician payment can be accurately related and tallied within their business intelligence (BI) environment. Where stand-alone BI environments are able to count expenses effectively at the summary level, duplicates and inconsistencies in the data makes it difficult to calculate the expenses for each physician. Multidomain MDM systems handle this problem easily by providing consistent, complete and accurate physician, hospital and affiliation data to the BI environment.

3 . Managing Opt-Out Compliance and Tracking Key Opinion Leaders

Pharmaceutical companies and medical device companies that sell directly to consumers need to effectively manage compliance with patient marketing opt-out, direct marketing practices, recall processes and customer service. Consumers access different channels—web, phone and fax for example—to take advantage of warranty benefits, product updates, recall information and marketing promotions. Each of these communication channels allows the consumer to choose whether or not to opt-in to marketing promotion campaigns. Managing people’s continuously changing preferences across these channels has proved difficult resulting in regulatory exposure and expensive fines, costly and reputation-damaging marketing mailings , costly and ineffective recall processes, and longer than necessary customer service call times. To solve this problem, pharmaceutical companies have implemented multidomain MDM systems to create a single view of consumers, patients, the relationships among them and products purchased or used across various CRM applications.

Another related problem for pharmaceutical companies is their inability to market drugs to target physicians due to a lack of knowledge of influencers, called key opinion leaders, to promote the drugs. To solve this problem they use multidomain MDM on a single platform to create a single view of physicians, hospitals, specialty and affiliations across internal systems and third party data. The resulting reliable master data is then fed to BI systems to improve reporting.

4 . Drug Discovery and Site Selection

Drug discovery and clinical trials are the lifeblood of pharmaceutical companies, and each phase of these critical business processes presents significant challenges. In drug research, pharmaceutical companies lack an enterprise view of compound research across current and previous trials resulting in redundant research across therapy areas. Pharmaceutical companies are using multidomain MDM on a single platform to create a single view of compounds to quickly identify research that should be discontinued based on real-time results, to gain better insight into the researcher network, and to build a stronger drug pipeline. As the trend for licensing outside research continues, pharmaceutical companies are using MDM to scout compounds that may already be in development at outside research institutions such as medical universities.

During clinical trials, a non-performing site could delay the submission of the drug for FDA approval resulting in significant revenue losses. Pharmaceutical companies use multidomain MDM to create a single view of sites and investigators across clinical trial management systems for optimum selection for a given trial, to better track site enrollment and performance, to invoke earlier shutdown of non-performing sites, and to improve the efficient handling of FDA audits and inspections of trial sites.

10

Banking MDM Journey Banks are also leading users of multidomain MDM technology as they commonly invest in technology for competitive advantage and need to manage very large IT infrastructures typically comprising hundreds of systems. As a result, banks dedicate a large portion of their operating budget to IT compared with other industries. Whether for managing retail banking, wealth management or corporate and investment banking divisions, the banks deal with duplicate and inconsistent data related to clients, counterparties, securities, brokers and accounts. They use multidomain MDM for Basel II compliance, credit risk management and trade processing. After solving an initial business problem with an MDM system, banks are choosing to extend the same MDM technology to solve business problems across other divisions. Similar to pharmaceutical companies, these banks teach an important lesson to other financial service providers on how to start small, gain significant business value and expand to address other business problems. Below are some typical business solution areas where banks are deploying multidomain MDM on an single platform:

1 . Credit Risk Management

Basel II regulations have required banks to align their risk management practices with a new global standard. This standard requires participating institutions to have a very high degree of accuracy identifying and assessing credit risk. These new rules require calculating the risk associated with an entire corporate hierarchy across all subsidiaries and positions. However, banks typically have not stored exposure and transaction information in this way, instead using “doing business as” or colloquial naming convention (e.g. GE instead of General Electric Co.) for corporate entities. As a result, they have difficulty compiling accurate legal hierarchy data, reference and profile data, and cross referencing that with account and transaction data. A multidomain MDM system enables financial institutions to cross reference exposures to each legal entity and summarize the exposure, rolling up to the global parent. With all counterparty reference data cross-indexed to internal accounts, exposures and transactions, risk managers are able to analyze and measure risk exposure across many dimensions including counterparty, domicile, asset class, product type and any other arbitrary rating units.

2 . Trade Processing

Large financial services institutions have dozens or sometimes hundreds of trading platforms. With competitive pressures to rapidly launch new products into new markets, most trading platforms maintain their own security and counterparty reference data which is critical to trade automation. This presents several data management challenges: it is difficult to keep the data up to date, support for multiple external data providers is needed, more data is bought than is needed, and, it is difficult to integrate business process efforts that are outsourced. Further, when trades are executed, they are cleared through an independent firm, which is not linked to the original trading systems and does not share the same database of securities and counterparties. Even for trades that are self-cleared within the firm, there are differences among the internal databases. Invariably these differences cause trade reprocessing, exponentially raising the cost of the trade from pennies to dollars per trade. And reprocessing takes additional time to clear the trade–with the bank bearing the cost of interest and associated liquidity issues. To address this problem, banks use multidomain MDM on a single platform to keep hundreds of downstream trading systems synchronized with the most accurate security and legal entity information. This helps ensure that the trades flow through automatically without requiring manual intervention.

Executive Brief

11A GPS for Your MDM Journey

Insurance MDM Journey Insurance companies earn revenues two ways: through premiums paid for insuring individuals’ lives, health, homes, personal articles, automobiles, and so on, and from the interest earned by investing those monies. One way to maximize revenues from premiums is to ensure that all people within a household are insured for all of their assets— also referred to as “customer share of wallet”. To increase their share of premiums, insurance companies perform household penetration analysis to understand the relationships among all family members and a host of other factors for each family member such as their age and assets owned. A larger challenge for insurance companies is related to that fact that many use independent agents to sell policies, masking the relationship with the actual customers.

Many insurance providers are attempting to create a direct relationship with policy holders, but given that the policy data is dispersed across multiple systems and that much of the data is masked by agents, it is very difficult to create a total household view. The ability to track life-changing events within a household can also be a significant source of revenue. For example, an insurer can offer an auto policy to a household where a child has turned 16 years of age, or offer an increase in life insurance limits to parents that recently had a new child. Accessing and relating household events can be daunting in the case where the insurance company uses different systems to underwrite the policies and service different claims. Another challenge for insurance companies is customer attrition. Typically, if one family member changes his or her insurer, it is likely that other family members will follow suit. Insurance companies use multidomain MDM to address these business problems to integrate disparate data related to individuals, households, policies, claims and the relationships that exist among them. This empowers them with an extended customer view, so they understand all the policies a customer has across the institution as well as which other policies they may need based on relationships within the household, outside of the household and with organizations.

ConclusionAs you begin your multidomain MDM journey, find out as much as you can from the companies who have taken the journey before you. The MDM pioneers in the pharmaceutical, banking and insurance industries have moved beyond their first project successfully. They have expanded the usage of MDM to solve other pressing business problems, and in doing so have proven the effectiveness of MDM throughout the enterprise. They will likely be open to sharing their experiences with you, providing more detailed accounts of critical success factors and pitfalls to avoid. Our advice: Increase your chances of success. Use a business-focused approach when embarking on your multidomain MDM journey. Help the business improve operations and performance. This proven approach delivers faster-time-to-value, generates a superior return on investment (ROI), and decreases total cost of ownership (TCO).

ABOUT InFORMATICA MDM

Informatica MDM empowers business users to improve their operations with reliable views of critical master data, such as customer, product, supplier, and employee, distributed across data sources. The solution provides comprehensive, unified, open, and economical Master Data Management (MDM) on a single platform. It enables customers to start small and expand as their needs grow with comprehensive support for all MDM requirements—data integration, profiling, quality, and master data management—on the same platform. Informatica MDM solves any business problem with an unified architecture for managing multiple data domains using multiple architectural styles. It leverages existing investments and skills with open support for all heterogeneous applications and data sources. Informatica MDM delivers faster time-to-value, lower TCO, and superior ROI because it can be rapidly implemented and is easily configured to quickly accommodate ever changing business needs.

ABOUT InFORMATICA

Informatica Corporation (NASDAQ: INFA) is the world’s number one independent provider of data integration software. Organizations around the world gain a competitive advantage in today’s global information economy with timely, relevant and trustworthy data for their top business imperatives. More than 4,000 enterprises worldwide rely on Informatica to access, integrate and trust their information assets held in the traditional enterprise, off premise and in the Cloud.

LEARn MORE

Learn more about Informatica MDM and the entire Informatica Platform. Visit us at www.informatica.com or call +1 650-385-5000 (1-800-653-3871 in the U.S.).

E X E C U T I V E B R I E F

Worldwide Headquarters, 100 Cardinal Way, Redwood City, CA 94063, USAphone: 650.385.5000 fax: 650.385.5500 toll-free in the US: 1.800.653.3871 www.informatica.com

© 2010 Informatica Corporation. All rights reserved. Printed in the U.S.A. Informatica, the Informatica logo, and The Data Integration Company 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 trade names or trademarks of their respective owners. First Published: May 2010 7136 (05/27/2010)