Three Guidelines For Implementing MDMLet business drivers, data volatility and project scope determine your approach and deployment style for master data management.
When we look for common features across IT "killer apps" over the decades, there has been a consistent level of apathy toward data management. As a result, the quest for a single source of truth has been getting progressively more complicated.
The emergence of master data management (MDM) solutions represents the pendulum swinging in the other direction, bringing much-needed balance by focusing on the data problem. MDM is not for every enterprise, but for a broad spectrum of financial services, manufacturers, health care providers, retailers, government agencies and other organizations, it is an essential next step to driving growth, improving operational efficiency, and easing regulatory compliance.
Implementing MDM is easier said than done. Should it be collaborative, operational or analytic MDM? And should it be a registry-, coexistence- or transactional-style deployment?
This article presents three guidelines that will help you determine appropriate MDM methods of use, implementation styles and domain scope.
Data Goes Uncontrolled
Excluding the brief attention data management received from Object-Oriented Programming "data hiding" principles and from Services-Oriented Architecture (SOA) data services, data has largely been allowed to grow uncontrolled.
Mainframes had flat files, VSAMs, and many flavors of hierarchical/relational databases. The days of client/server computing were even more flexible and indulgent. They brought in 4GLs that made it easier to have surrogate line-of-business (LOB) databases and corporate distributed databases that weren’t always synchronized. Enterprise Resource Planning (ERP) packages placed even greater emphasis on process logic that was ready-made with built-in, and often vendor-controlled, data models. The best-of-breed approach of building process-rich systems with multiple ERP packages was a great recipe to let data conflicts grow between data models of different vendors and those belonging to custom, mission-critical transactional systems.
The current virtualization (server consolidation) and cloud computing trends make it easier to manage storage proliferation; but they also come with limitations of scope and additional complexities. These efforts don’t go beyond the issues of physical storage to look inside the complex world of data. In addition, they introduce the management challenges of synchronizing data across public and private clouds.
As shown in the timeline at right, our decades-long apathy toward centralized data and focus on infrastructure, process/business logic, and presentation layers has been hurting us whenever we try to get a hold of the fragmented view of business-critical master data. We keep finding that there is no easy way to get a unified view of the business when we try to promote growth through cross-selling and up-selling and when we try to extract business efficiencies from current operations. The adverse effects are felt the most in the customer and product data domains, but businesses have been feeling the same pinch in other critical areas, including partners/suppliers, contracts, locations/shipping and so on.
MDM has been around for a while now, earnestly so for the last five or six years. The recent spate of consolidation in MDM, with IBM acquiring Initiate and Informatica acquiring Siperian, confirms market growth and also indicates a trend toward MDM as a multi-domain discipline. Early master data initiatives had a limited focus on customers (often called CDI, for Customer Data Integration) or products/services (often called PMI, for Product Management Information).
Given the pervasive nature of the data management problem that MDM tries to address, it would seem natural that most enterprises would automatically have an interest in applying MDM solutions. But MDM isn't really for everyone. First, MDM's appeal all depends on the complexity of the landscape of applications and how master data is strewn among them. Second, not every business can make a legitimate business case for using MDM to drive growth, operational efficiency, and ease of regulatory compliance.
Qualifying enterprises cross the spectrum of vertical industries, including financial services, chemicals, energy and natural resources, healthcare, automotive/manufacturing, retail and the public sector. Requirements revolve around customers/citizens/patients, suppliers, locations, products, pricing, contracts, assets and so on. In these and other verticals, companies that could benefit the most from MDM have a combination of the following requirements:
• Greater compliance and privacy obligations such as Sarbanes-Oxley (SOX), Basel II, Basel III and meaningful use
• Portfolios of broad, retail-oriented offerings that can benefit from cross/up sell.
• A complex supplier network that can benefit from a consolidated view of transactions
• Multiple data-entry and data-transfer channels that require a centralized data-quality and governance process, including activities related to data cleansing and authorization/validation
• A federated business services strategy based on SOA that demands a complementing data-services strategy using MDM.