Nov 29, 2010 (09:11 AM EST)
Three Guidelines For Implementing MDM
Read the Original Article at InformationWeek
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.
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
An Enterprise MDM Approach
To align the approach, architecture, and design of MDM solutions to your business requirements, apply these three guidelines:
• The primary business drivers determine the methods of use
METHODS OF USE
Collaborative MDM (CMDM) is aligned with the business process layer. It is used to manage entities whose attributes are owned and maintained by a diverse, yet interlinked, group of users. Although often associated with the product domain alone and deployed to track the evolution of products, from definition through engineering and market launch, CMDM can and should be used to manage the master data of other entities, such as customers, for the appropriate life cycle activities such as prospecting, acquisition, delivery, and support, etc.
Architecturally, CMDM needs the support of enabling technologies such as Business Process Management (BPM), workflow, role-based security, etc. It is through CMDM that new records of master data get created.
Operational MDM (OMDM) is more closely aligned with the services layer and works closely with the SOA stack. OMDM needs to be built to support core business systems as they handle transactions with customers, suppliers, etc. These transactions could be generated from any customer-facing business channel, such as interactive voice response (IVR), phones, Web, ATMs, RFID, and wired/unwired devices. OMDM supports access to master data for the purposes of validation, and incidental updates to master data attributes as necessary.
Analytical MDM (AMDM) works on the side, with business intelligence (BI) applications to push out changes related to master data integrity. It also receives summary level metrics from BI applications and to make them persistent in master data, as needed, to make certain key statistics available centrally. Entity (or Identity) analytics is a specialized area with AMDM that deals with customer/citizen background checks and name services.
The Registry Style is a rudimentary implementation style that is more concerned with managing the master data records, as opposed to managing a comprehensive set of all the related attributes. It provides read-only access to master data for the purposes of restoring uniqueness and validation.
There are two other styles where master data is more of a database with full support for all the attributes and differing approaches to data synchronization with the application systems. In a relatively non-volatile environment, the Coexistence Style (or Convergent consistency) will suffice to keep the master data refreshed periodically. In a real-time environment however, the Transaction Style (or Absolute consistency) is used. Needless to say, Transaction Style requires robust support for SOA, messaging, and transactional monitoring to ensure that the master data is always in sync with transactional systems.
MDM solutions have been steadily expanding beyond the traditional turf of customers and products. As the scope grows to include multiple domains, as listed earlier, the architecture needs to incorporate additional services such as identity analytics, event management, etc. and products which specialize in newer domains and niche verticals (support for 'patients' could be very different from support for generic 'customers,' for example).
Reference Architecture and Vendors
Although the influencing criteria listed above might appear like options to pick and choose among, realize that these represent a set of mutually inclusive technical requirements that need to be considered as a sum in determining the overall conceptual architecture for an MDM system.
The Future of MDM
Business expansion, the drive for efficiencies and compliance demands will continue to drive MDM growth. Multi-domain MDMs is definitely drawing interest from product and service providers.
By its very nature, MDM is a services-heavy deployment, and the projects tend to be multi-year, requiring a combination of upfront consulting (on data governance strategy) and architecture and downstream development services (involving data quality and integration services).
The optimization efforts that, for many years, have been slanted toward infrastructure, process logic, and user interfaces, have to be realigned. Renewed focus on data will restore much-needed balance. It's time to deliver on the promises of industrialized IT and to live up to the service-level agreements of IT as a Service. Not the least of these promises is access to a single source of truth. The road to get there goes through MDM.
Sreedhar Kajeepeta is Global VP & CTO of Technology Consulting Practices for the Global Business Solutions & Services division of CSC. He previously worked for Convansys (now merged with CSC), Cambridge Technology Partners, and Tata Consultancy Services. Write him at firstname.lastname@example.org.