Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos
Imagine a Fortune 100 global organization XYZ Inc, with a complex IT landscape, many master data consuming systems, poor data quality and lack in visibility in business process. A perfect case for an MDM implementation. But the organization of its scale will obviously not decide for big-bang approach and one fine day decide to close all enterprise systems and MDM would be my single point of contact. It would go in a phased manner- may be by business units, by geography, by master data object or simply by similar type of systems.Consider that XYZ has following landscape which it wants MDM to be point of contact over period of time.
  • 3 Instances of SAP R3 across geos
  • Siebel as one of its CRM system + 2 Legacy CRM systems
  • 3rd Party BI system
  • Few other legacy systems that hold business partner master data

XYZ decides to go for a phased MDM implementation for Business Partner master data object and selects 2 R3 systems, 1 Legacy CRM and 2 other legacy systems to start with. 

 

Data Modeling is done, repository is built, data is imported, de-duplication is done and talks for using MDM for Central Master Data Management is already begun in XYZ Inc. All great so far! And the management is happy with the results and hence decides to include more systems in the MDM landscape.

While doing the data analysis for these new systems, the team faces a strange issue. In addition to many new fields, some of the fields of the new remote systems have either a different data type or their width is more or something else!

 
FieldCurrent DesignNew Requirement

Weight

Data Type – Integer

Data Type – Real

Description

Width 50

Width – 90

Address

Fields like City, Street, Pin Code in main table

Multiple address per customer. Hence Qualified table is required

 

The new fields can obviously be added to the repository, but what about the existing fields? Some of the options in front of the team are:

  • If they decide to delete the field and create a new one with different data type, value for all the records in repository for that field will be deleted.
  • If they decide to keep the width unchanged, the values for these fields will be truncated.
  • They can move address data from main table to a new qualified table but it will involve lot of efforts.

These are just some of the examples; there could be many more complex issues that might arise with respect to assignments, workflows etc.

 

Hence, coming to the main question of the blog: Is it possible to predict and design the data model considering the future requirements or is it is just all fiction?

 

I agree that you cannot design a repository considering all consuming systems across geos in huge global organizations when you are only targeting an MDM initiative for limited systems. But yes, if sufficient efforts and time is given to system study and data analysis stage before jumping into an MDM project, some of the issues can be predicted and the design can be made flexible enough to incorporate more systems.

4 Comments