Don’t “default” to one methodology or another – the right guides know which road to take and how to overcome barriers, avoid potholes, and bypass sidetracks that exist on all of them. Whether tried-and-true or new iterative approaches, the right expertise can navigate the roads to a successful MDM conclusion.
Originally published on Information-Management.com
Written by John Tuttle, Senior Director of Master Data Management
In ancient times, all roads led to Rome as the center of the Roman empire. Fast forward to the present, and just as many can lead to a successful Master Data Management (MDM) implementation within a digital transformation journey.
Past tried-and-true implementation methods still result in predictable and known methods for managing project work. Essentially a waterfall methodology, Enterprise MDM Methodology is an updated approach to the methods which brought success to early adopters of MDM technologies.
This road follows the same journey as a majority of past MDM adopters and utilizes standard practices employed by consulting firms and client companies to manage scope of work, estimate task durations/effort, define a work break down structure and utilize existing and known tools to drive successful outcomes. A very well-worn road!
But times change and many organizations are deserting this heavily project management-oriented path to allow teams to “self-organize” and shift to an iterative path. Naturally, the question is, “will this road lead to MDM?” Fortunately, the answer is a resounding, “Yes!”
Increasingly, clients are moving to agile, iterative approaches, which means data scientists are re-evaluating how MDM projects can be successfully implemented using these methodologies.
A large government-mandated mortgage loan guarantee organization held a pilot program in moving to an agile methodology. The team was the first to use this practice in building a reference data master solution. A main concern, based on extensive experience with the “tried and true” approach, was the impact of data modeling. With short sprints (timeboxed iterations of a continuous development cycle) designed to result in a fully functioning system, concern was that early sprint decisions on the data model might be impacted by future sprints.
Reworking an MDM data model is particularly difficult after building all the components that are required to deliver a functioning user interface application. While a data model can be easily extended, once built, any future alterations could create more effort later on. In fact, reorganizing the model and regenerating what was already built and deployed could consume all the pilot team’s time.
The team was well aware of this potential impact. From the beginning, focus was on ensuring the model had a solid core before adding on user stories. Core entities were expanded upon and the UI components were added systematically from sprint to sprint.
For an MDM program with larger data models, this risk is mitigated by early iteration and sprint planning periods.
Segmenting epics (large chunks of work with one common objective) is important in ensuring the necessary data and system analysis, as well as data profiling is completed in order to inform the data modeling required for ultimate success of the project. While this approach breaks with the core tenets of iterative approaches (there won’t be a working system from early sprints), it will allow other benefits of an iterative approach.
The business or product owner can adjust priorities to identify what stories are run first once the core of the data model is solid. This doesn’t mean modeling must be completely finished before development is completed, but for any user story to begin, the data model components supporting that story must be ready to build. The epic structure is an important way to verify the underlying constraint of an MDM project can be merged with the flexible, iterative approaches being used by organizations today.
Release planning is also important as many user stories need to be completed before the overall system can be fully tested and integrated. As such, iterative programs deploy into a testing environment, not directly to production. This is another adjustment to true agile methods, but one that is necessary for critical, core IT systems (MDM). There have been successful iterative approaches to enhance existing systems that follow agile sprints, however initial MDM deployment is planned after multiple sprint iterations and intensive testing have been done first.
Regardless of the adjustments made to new iterative approaches, the road can still lead to MDM success while gaining the benefits of self-managing agility.
All (or at least many) roads can lead to a successful MDM implementation within a digital transformation journey. It’s important to work with clients to identify the road that best fits the organization.