Welcome to the third installment of the “Figure 8” series! In last month's post, we reviewed essentials 2-4 and discussed guidance for conducting the current state assessment and inventory. With essentials 5-7, we move past the analysis (understanding the "what") and into building the architecture (the "how").
You might be wondering why self stick notes (a.k.a. "sticky notes") are featured in the graphic and what they have to do with the essentials. Mostly, I featured them because I have an unhealthy obsession with those gluey little darlings and their electronic siblings. I have them everywhere and I love using them in the analysis and design phases because they are easily moved around or removed completely when an item is no longer relevant. To me, they serve as a reminder that as we work through the essentials, we continue to experiment and adjust as new information arises. Grab your self-adhesive notes and let's explore the next three essentials!
Where, oh where, should our data be? Since we already figured out "what" we want to manage and took an inventory of existing solutions, some key questions arise during this step. If we already have the data stored somewhere electronically, is it accessible? (not just via one method, but a variety of methods?) Is it on a platform that will be supported in the future? Is the data stored in a single location (or will it be)? Does it need to be? In addition to all the questions swirling around, the terms hub, data store, replication, service, and virtualization may be on your mind at this point. Since there are several articles that contrast the various types of hubs, I won't delve deeper into that topic within this blog.
Another thing to determine is the scope of the master data store. Defining the key, sharable attributes can help you clarify scope, determine estimates for sizing, and frame the security needs. If the proposed solution spans multiple business areas, be clear on the boundaries of what the central store will include. Some business areas may want to include attributes that are not applicable to the wider audience. Consider implementing the business area-specific attributes within a local application.
A key principle for this essential is that a repository without an integration plan adds little value. Don't lock up your master data. There may be occasions where governance, rather than technology, is the main factor in limiting access to the master data. Understanding what the governing bodies will be willing to share with others can influence the direction for both the storage and access mechanisms. Because the ability to access information impacts the value of our master data, making this information readily available rises to the top of our priority list.
Looking realistically at what can be done is tough, but necessary. Although the end goal may be to implement something company-wide, there may be barriers that require a smaller scale implementation to prove value more rapidly. In a previous blog, I contrasted "little e" and "Big E" MDM. Either one can add value to the business - it's just a matter of scale. Figure out which one your stakeholders will support.
The interview notes also play an important role in defining what you can solve. A combination of a difficult pain point, engaged stakeholders, and a clear problem to solve are master data program nirvana. (assuming that time, money, and resources are available, of course!) Although a particular group may have been vocal about their needs during the interview process, that doesn't guarantee support when money or resources are requested.
MDM, like other complex programs, requires a wide breadth of skills. Data expertise is at the heart, but both business process and technology experience are necessary for a successful implementation. You may need to bring in outside consultants either for their guidance or to validate your proposed architecture. If MDM is new territory for your organization, expect some skepticism and requests for external validation.
Although there are many promises made by tools in the MDM space, you need to consider whether they cover your use case and requirements for a variety of components, including: infrastructure, governance, data sharing, meta data management, identity resolution, syndicated data, and data quality.
In essentials 5-7, we have moved from the assessment stage through the architecture and determined the "how" for managing the data. With that, we wrap up the "what" and "how" phases of the essentials. Stay tuned for the fourth and final installment of the series.
NOTE: Thoughts expressed in this article are those of the author and not her employer (or probably anyone else, for that matter).