We’re doing a short blog series highlighting commonly overlooked facets of in the MDM. The series in to help set the stage for our Sept 19, 2012 webcast with Andy Hayler on “Best practices in MDM vendor selection.”
In part 1 (31 Aug 2012) we covered the following questions
● Can I use someone else’s model?
● How will I capture, or document, my master data requirements?
● How can I deal with different data models patterns?
● How can I define business rules to enforce validation?
Today, in part 2, we’re focusing on these
● How will I deal with models’ lifecycles?
● How will I verify that what I’ve documented is accurate?
● How will I integrate my models into the MDM platform?
● Can I use the models for more than documentation?
Part 1 was more focused on the model creation process; documenting what your MDM will be focused on. Today’s questions are really about what’s next…
How will I deal with models’ lifecycles?
Whether or not you choose to use an external tool or your MDM platform’s built-in modeling feature, how you will manage multiple versions of your model over time is an important consideration. MDM is all about governance of your master data. While people immediately focus on the values and relationships (tracking changes in your customer’s DUNS number, incorporating new SKUs), you should also remember what you choose to govern may expand and change over time, especially if you are moving from managing a single domain to a much broader, multi-domain implementation. This expansion in scope translates into a change in the model and necessitates a means of maintaining model versions.
How will I verify that what I’ve documented is accurate?
Your staffs’ skill levels are related to how well you’ll be able to verify if the models accurately describe what you’re mastering. Do your developers and business users understand UML or ER models? If only a few individuals in your group can read and understand UML then the models will be tough for them to analyze and vet. If using a built-in modeling tool, how will the models be evaluated for accuracy? Do the users read reports? Look at models? Is access only provided through a proprietary modeling interface?
Skill with the tools is also a concern. UML and Data Modeling tools are technical pieces of software. A fair amount of training is required to use these tools effectively. If looking at a built-in modeling tool, how easy is the tool to use? There’s also cost concerns, do you have licenses for everyone who will be modeling? Are special (or components) required to read the models?
How will I integrate my models into the MDM platform?
Standards based integration always looks great on paper, but vendors have subtly different interpretations of the standard. This means If you are planning on using an external tool, be prepared to perform moderate processing work to clean up your model after importing your into the MDM platform. In theory, built-in modeling tools don’t suffer from this integration problem. But this depends on what “built-in” really means. Some vendors “built in” modeling by grafting multiple products together.
The hodgepodge work as you would expect (generally, not so swell).
Can I use the models for more than documentation?
While the purpose of your model is to document what you are choosing to govern; the purpose of your master data management project is to define, execute and maintain a governance protocol for this information. The usefulness of the model is directly related to what you get out of the modeling exercise. Don’t fall down the rabbit hole and assume that you need a comprehensive and exhaustive view of your entire universe — stay focused on the MDM problem.
As documentation the model has significant value. It provides a common platform for achieving consensus between all interested parties. It guides the development and maintenance processes, as your teams will use these “blueprints” to build and maintain your MDM platform (provided you’ve sorted out the lifecycle is But what if you could do more than just read the documentation?
Using the models for more than just documentation is an area where MDM platforms that are model- driven stand apart. Unlike MDM platforms that use models as documentation as guidance (indirect input); Model-driven MDM platforms use their models as direct input into the development and maintenance processes. The model are used to generate the authoring and review screens, data interfaces, and repositories. While, generation reduces your up-front development costs, this is only a first order effect.
Having a model-driven MDM also means that you can take more agile, collaborative approach in designing your MDM platform. Instead of using paper- or PDF-based documentation as the heart of your verification process; use the models to breadboard, or generate prototypes, that are tested by your users or subject matter experts. Prototyping provides your team with immediate feedback and it helps capture requirements that may be unrelated to the data you wish to master, such as usability, look feel and issues.
Model-driven platforms also help resolve the lifecycle management problem. In construction there is a often a difference between as-designed and as-built plans. This is because during the construction process the plans altered to address events on the ground. This can lead to unintended consequences. Software is no different — user feedback, changes in scope, corporate restructuring — are events that affect the development of the end product. With a traditional paper-based approach, someone needs to continually revise the documentation as changes are made. With model-driven systems, because the models are used to generate the artifacts your documentation is always in sync.
In this post (and in Part 1) we put down a few of the main elements of modeling that we think many people miss in the early days of their MDM program.
Please feel to send along any comment (challenges?) on our post in the area beneath. And look for our next post in which we cover issues related to model lifecycle management, vetting (or verify your model’s accuracy), model integration and using the models for more than just documentation.
By Conrad Chuang