Let us look at the core architecture principles, which should govern the architecture solution for MDM-CDI. Each of the MDM-CDI architecture options should deliver to these principles:
De-coupling modeling from source systems
While MDM picks-up the master data from the source system, it does not need to driven by the data-structure and process of getting the data. For example, the source system could be having a data model as per the specific requirement of that system. However, as you decide upon the Customer data model for MDM, it will be based upon multiple factors, include industry best practices for customer data model, and also on the needs of the applications.
Another example can be on how you standardize the data. For example the CRM system may have a customer address in a single line, whereas you would like to have separate fields for house number and street name.
Decoupling information flow across source system and destination system
An MDM-CDI (we are using Customer Data Integration interchangeably with MDM as that is most popular MDM application) solution should be de-coupling the information flow in way that information extraction from the source system is not influencing the windows on when a destination system can access MDM-CDI. This is part of the integration services using open frameworks, and service oriented architecture. This principle is different from Data warehouse, because MDM-CDI platform is used for operational real-time purpose. Therefore, you will be updating the MDM on real-time (or nearly real-time) basis and also accessing it on the real-time basis.
Flexibility to accommodate changes in the modeling
This is another such principles, which are same across MDM and Data Warehouse. The MDM platform should enable it to detect changes in the data structures and schemas in the source systems. As soon as it detects the changes, it should invoke the MDM stakeholders to change:
- The associated integration services for extraction, transformation, synchronization
- The universal data model for the master entity (say customer) in MDM
- The access routines for client system, which are using MDM platform
Ability to accommodate the business requirements
Business requirement change could result in:
- Addition of a new source system
- Change in the data model of master entity in master data management hub.
- Addition of a new destination application.
The MDM-CDI platform should be able to address these needs in a flexible and extensible manner.
Security, privacy and compliance
MDM, especially in the case of customer MDM-CDI and Employee MDM need to adhere to strict privacy and compliance laws. The architecture needs to provide a secure environment to ensure ownership, integrity, Auditability and security of data.
Open computing architecture
The MDM solution should be based upon industry accepted open computing standards to support the use of multiple technologies and techniques for interoperability with external systems and systems within the enterprise. This guides development of the architecture to remain open and flexible so it can easily integrate with a variety of vendor software that may already exist within the enterprise and future 'unknown technologies' The openness is both in terms of connect with source systems as well as the systems, which are using the data.
Maximize the use of existing enterprise technologies
An MDM solution (with the help of its open framework) should be able to leverage on the existing technologies like messaging, synchronization, middleware, EAI etc.... For example- If the organization is using TIBCO, MDM should be able to ride on that.
Incremental implementation of MDM
MDM-CDI architecture should enable incremental implementation. For example, if you want to have the Customer MDM for only Asia region, you should be able to do it whereby the MDM platform is able to pull out the customer data related to Asian region only. Other way to look at it is that, if you want to use MDM-CDI for only a certain set of product lines, one should be able to do it. You should be able to gradually add additional source system. In real-life also sometimes it is not possible to have all the source systems, which are carrying customer data to be part of MDM solution from the day 1. |
