Welcome to the second installment of the “Figure 8” series! Yes, I know it has been a little while since we looked at essential #1. In this blog, we look at essentials 2-4. These build on the vision, or goal, which was discussed in the first essential.
Note that working through these essentials doesn’t imply a complete waterfall approach – you may go back and rethink decisions or rework deliverables as you progress through the essentials. Just be cognizant that if it feels like you are caught in a spiral of revisiting issues that were thought to be closed, you probably need to make sure the end goal is clear, and is first and foremost in the minds of the team.
One pet peeve that I want to address before diving into the next three essentials is the misconception that MDM is just a technology or an implementation method. The first blog in the series spoke to why that wasn’t correct, so I will just supplement with:
MDM <> ERP
MDM <> RDB
MDM <> Repository
MDM <> Ontology
MDM <> Data Integration
Clear enough? Those techniques can be used as part of the architecture and implementation, but they do not equal MDM. Off soapbox, now on to the essentials.
Essential #2: Figure Out Who Cares
Essential two plays a key role in gaining sponsorship and establishing governance. At this point, you are looking for people who are engaged and, in many cases, are impacted by issues that MDM can solve. The primary goal here is to gain an understanding of the business processes, roles, and entities that are key to the success of the business. Through surveys, interviews, and workshops, you gather the pain points and stories that will prove valuable for a business case. Open ended questions or inquiries, that encourage discussion, provide the most information. Asking the interviewees to describe their interactions with other groups results in more information than asking a yes/no question like "Do you interact with other groups?"
As you collect responses, start to look for synergies and common themes. Are there certain groups that have similar issues or activities?
Essential #3: Figure Out What “It” Is
As you learned about the processes and stakeholders, information about the key entities to be managed should have emerged. The goal at this stage is to gain clarity on how each business group defines the entities. Definitions do matter – is it department? division? something else? Did all of the groups have the same understanding and definition?
As you dig into the entities, you start to get a feel for requirements, potential scope, and the probability of success in making changes. (were the groups resistant or open to change?) You may also gain a sense for how “good” the data needs to be in order to be considered high quality.
A number of artifact techniques are helpful for documenting and understanding the entities of interest. These include, but are not limited to, data models, matrices, life-cycle maps, and process flows.
One thing that I've found helpful is an archetype matrix. This is somewhat similar to what Bill Inmon describes for mapping out conformed dimensions in data warehousing. Put the business areas or interview groups on the left, list the entities across the top, and then check off where an entity is relevant. From this, you can cluster together similar themes.
Essential #4: Figure Out What You Have
Now is the time (if you haven't already) to take inventory of the resources that you have available. As you are looking at what "it" is (essential 2), you may have looked at where "it" is documented and/or implemented. You don't want to model from a blank page if you already have existing, relevant models.
Another thing you want to highlight are the "pockets of brilliance" – places where things are going well. Is there an existing governance group that could mentor others? Are there existing solutions that you can leverage? You might be able to reuse the architecture pattern even if the complete solution doesn’t fit the current case.
Depending on how difficult it is to find models, applications, databases, etc., you may find that this is a great time for a spin-off business case to create an inventory application (but that’s a blog for another day).
In essentials 2-4, we have moved from the vision stage through the assessment stage. We have a goal in mind, data collected from business areas, definitions of the key entities, and an inventory of potential resources. In the next installment, we'll move from assessment to architecture components.