Master Data Management Best Practice #4 – The Business Has To Own MDM and Data Governance
As tempting as it is to start and finish with the technology, it doesn’t work.
One model that I’ve seen work very well is for the business to lead the data governance initiative, with senior management being involved through a Data Governance Council (which makes policy for enterprise data), with Global Process Owners handling day to day activities in their own functional areas such as marketing, sales, channels, customer support, and finance, and with tactical aspects handled by business data stewards and IT stewards, under the direction of the Global Process Owners and the IT Global Solution Owner.
This three level model (Data Governance Council, Global Process Owners, Data / IT Stewardship) allows the business to set direction at the highest level and coordinate across the enterprise, while still letting the process owners manage activities within their own functional areas. It’s important to break down the silos which are so common in most of today’s corporations, because silos breed the “islands of data” problem. Reuniting and reconciling those “islands of data” is one of the major reasons companies are doing master data management initiatives in the first place.
When MDM is driven solely by IT, the business may not understand it or buy in. In some cases, the business may not even realize MDM is there, if it’s buried too deeply in the “infrastructure”.
The hard truth is that MDM’s nature as an ongoing program means that even if the initial project is funded by IT, the business may not pick it up in Year 2 & beyond – unless the business owns it.
I’ve seen many instances of MDM programs whose first iteration (driven solely by IT) failed, until they started over, recruited sponsors in the business, transferred ownership of the program to them, and took a more business-oriented approach to the initiative.
Please let us know – in the comments here, in the forums on the MDM Community or using the #MDM hashtag on Twitter – what you think of the need for business to own the MDM and data governance initiative.
The next article in the series is: MDM Best Practice #5 – Use Your Best Project Managers and People
Master Data Management Best Practice #3 – Emphasize the Organizational Change Management Aspects
Addressing the organizational change aspects of master data management (MDM) and data governance initiatives is critical to their success.
Outside perspective can be very helpful here. As I discussed in a recent article, “Org. Change and Data Governance”, organizational change management – as an applied discipline – is used far too rarely on MDM projects. They’re big enough to justify it, and they certainly involve enough corporate politics and cultural change to benefit from a structured approach to organizational change management. My firm, Hub Designs, applies org. change and communications strategy techniques to every project we do.
Most of what I know about organizational change management I learned from my friend, Dr. Burt Reynolds, who is now an Assistant Professor at Southern NH University. We first worked together on an Oracle ERP project at a software company in Massachusetts. One of the reasons that project was successful was the project leadership included a strong org. change component.
In MDM projects, a clear communications strategy that addresses all of the various stakeholders of the initiative, and communicates your messages to them using their preferred methods of communication, over the right time frame, will have a huge impact – particularly if you can tell those stakeholders how MDM and data governance are making a difference and helping the organization realize its strategic goals. Find every occurrence of increased revenue, reduced costs, and easier compliance and risk management, and pass those success stories on to the organization at large.
Please let us know – in the comments here, in the forums on the MDM Community or using the #MDM hashtag on Twitter – what you think of the need for organizational change management in MDM and data governance initiatives.
The next article in the series is: MDM Best Practice #4 – The Business Has To Own MDM and Data Governance
Master Data Management Best Practice #2 – Active, Involved Executive Sponsorship
MDM and data governance projects need strong executive sponsorship, more so than most projects involving technology.
To champion a change (towards managing master data as a true corporate asset) is going to mean significant cultural disruption. In most companies, that type of change is best driven “top down”.
Don’t try to start until this is in place. Work on your elevator pitch, reach out to senior management and educate them on master data management, and work on recruiting your executive sponsors.
MDM and data governance programs are typically not very successful from the “bottom up”. They may start that way, and even show a few small wins, but you’ve got to get the “C suite” interested and engaged at some point in order to get the budget money and the political “juice” you’ll need.
Don’t forget that data governance is largely a political function. I’ve always liked Jill Dyche’s definition of data governance: “Data governance is the decision-rights and policymaking for corporate data, while data management is the tactical execution of those policies.”
When you see the word “decision rights” and “policymaking” next to the words “corporate data”, you know that you’re dealing with an area that is more political than technological. But we need to embrace that, for that is the reality of data governance (or as my friends at Evaxyx in the UK like to call it, “data government”).
And if you think that anything in the enterprise can succeed that is so strongly political without the explicit and continuing support of senior management, I’ve got a bridge in Brooklyn that I’m dying to sell you.
Please let us know – in the comments here or in the forums on the MDM Community – what you think of the political nature of data governance and the need for active, involved executive sponsorship of MDM projects.
The next article in the series is: MDM Best Practice #3 – Emphasize the Organizational Change Management Aspects
Modeling the MDM Blueprint – Part 6
In this series, we’ve discussed developing the MDM blueprint by developing the Common Information (Part 2), Canonical (Part 3) , and Operating (Part 4) models in our work. Part 5 introduced the Reference Architecture model into the mix to apply the technical infrastructure or patterns we plan on using.
The blueprint has now moved from being computation and platform independent to one that expresses intent through the use of more concrete platform-specific models. The solution specification is now documented (independent of the functional Business Requirements) to provide shared insight into the overall design.
Now, it’s time to bring the modeling products together and incorporate them into a MDM solution specification we can use in many ways to communicate the intent of the project.
First, the MDM blueprint specification becomes the vehicle for communicating the system’s design to interested stakeholders at each stage of its evolution. The blueprint can be used by:
- Downstream designers and implementers to provide overall policy and design guidance. This establishes inviolable constraints (and a certain amount of freedom) on downstream development activities.
- Testers and integrators to dictate the correct black-box behavior of the pieces that must fit together.
- Technical managers as the basis for forming development teams corresponding to the work assignments identified.
- Project managers as the basis for a work breakdown structure, planning, allocation of project resources, and tracking of progress by the various teams.
- Designers of other systems with which this one must interoperate to define the set of operations provided and required, and the protocols for their operation, that allows the inter-operation to take place.
Second, the MDM blueprint specification provides a basis for performing up-front analysis to validate (or uncover deficiencies in) design decisions and refine or alter those decisions where necessary. The blueprint could be used by:
- Architects and requirements engineers who represent the customer. The MDM blueprint specification becomes the forum for negotiating and making trade-offs among competing requirements.
- Architects and component designers as a vehicle for arbitrating resource contention and establishing performance and other kinds of run-time resource consumption budgets.
- Development using vendor-provided products from the commercial marketplace to establish the possibilities for commercial off-the-shelf (COTS) component integration by setting system and component boundaries and establishing requirements for the required behavior and quality properties of those components.
- Architects to evaluate the ability of the design to meet the system’s quality objectives. The MDM blueprint specification serves as the input for architectural evaluation methods such as the Software Architecture Analysis Method [and the Architecture Tradeoff Analysis Method (ATAM-SM) and Software Performance Engineering (SPE) as well as less ambitious (and less effective) activities such as unfocused design walkthroughs.
- Performance engineers as the formal model that drives analytical tools such as rate schedulers, simulations, and simulation generators.
- Development product line managers to determine whether a potential new member of a product family is in or out of scope, and if out, by how much.
Third, the MDM blueprint becomes the first artifact used to achieve system understanding for:
- Technical managers, as the basis for conformance checking, for assurance that implementations have in fact been faithful to the architectural prescriptions.
- Maintainers, as a starting point for maintenance activities, revealing the areas a prospective change will affect.
- New project members, as the first artifact for familiarization with a system’s design.
- New architects, as the artifacts that (if properly documented) preserve and capture the previous incumbent’s knowledge and rationale.
- Re-engineers, as the first artifact recovered from a program understanding activity or (in the event that the architecture is known or has already been recovered) the artifact that drives program understanding activities at the appropriate level of component granularity.
Blueprint for MDM - Where this fits within a larger program
Developing and refining the MDM blueprint is typically associated with larger programs or strategic initiatives. In this last part of the series, I'll discuss where all this typically fits within a larger program and how to organize and plan this work within context.
The following diagram (click to enlarge and use your browser to magnify the png file) puts our modeling efforts within the context of a larger program taken from a mix of actual engagements with large, global customers. The key MDM blueprint components are highlighted with numbers representing:
- Common Information Model
- The Canonical Model
- The Operating Model
- The Reference Architecture
Click to enlarge
I have also assumed a business case exists (you have this right?) and the functional requirements are known. Taken together with the MDM blueprint, we now have a powerful arsenal of robust information products we can use to prepare a high quality solution specification that is relevant and can be used to meet a wide variety of needs.
Typically, use of the MDM blueprint may include:
- Identifying all necessary components and services
- Reviewing existing progress to validate (or uncover deficiencies in) design decisions; refine or alter those decisions where necessary
- Preparation of detailed planning products (Product, Organization, and Work Breakdown structures)
- Program planning and coordination of resources
- Facilitating prioritization of key requirements – technical and business
- Development of Request for Quotation, Request for Information products (make vs. buy)
- Preparing funding estimates (Capital and Operating Expense) and program budget preparation
- Understanding a vendor’s contribution to the solution and pricing accordingly (for example, repurpose as needed in contract and licensing activities and decouple supplier proprietary lock-in from the solution where appropriate)
We are also helping to ensure the business needs drive the solution by mitigating the impact of the dreaded Vendor Driven Architecture (VDA) in the MDM solution specification.
Summary
I hope you have enjoyed this brief journey through “Modeling the MDM Blueprint” and have gained something from my experience. I’m always interested in learning from others, so please let me know what you’ve encountered yourself, and maybe we can help others avoid the pitfalls and pain in this difficult demanding work.
The difference between success and failure on an MDM journey is taking the time to model the blueprint and share this early and often with the business. This is after all a business project, not an elegant technical exercise. In an early reference, I mentioned Ward Cunningham’s Technical Debt concept. Recall this metaphor means doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort we have to do in future development because of the quick and dirty design choices we have made. The technical debt and resulting interest due in MDM initiative with this kind of far-reaching impact across the enterprise is, well, unthinkable.
Take the time to develop your MDM blueprint and use this product to ensure success by clearly communicating business and technical intent with your stakeholders.
Data Governance: The People Make It Real
I was talking with a potential client the other day about their master data management program and how they’ve structured their data governance initiative. This company really seems to have gotten it right. They’ve put together a data governance framework that makes sense, and they’ve made some good technology choices along the way as well.
But the analogy that came to mind was that of the United States in its early days, after the Constitution was framed up but before any of the representatives had been elected.
The data governance framework (the Constitution) has been put together, but the people haven’t been hired yet. And in data governance, as in most other areas of business, it’s the people who make it really happen. A great business process is just a piece of paper or a drawing on a white board without the right person to make it happen.
What do you look for in an employee filling a data governance role? Depending on how senior the position, I’d look for a certain amount of political savvy, a drive to get things done, an ability to focus and be detail oriented, a combination of business and technical experience, and of course, the usual “strong written and verbal communication skills”.
Seriously, the more senior data governance people are taking on a pretty tough task. While I don’t believe that “data governance is career suicide“, I do believe that you’re asking a lot of someone:
- come into a new company (or change roles within their current company)
- start up a new organization with the company that has a somewhat vague mission (“data governance? what’s that?”)
- take on the task of forming the data governance group while overcoming the skeptics of its mission
- hiring people to round out the data governance group, lest you risk becoming a “team of one”
- sometimes, the new data governance leader is coming into a crisis situation and has to hit the ground running
So one way to support a new data governance program leader is to bring in a SWAT team around them temporarily, to support them while they build out their permanent team, and to have that SWAT team help with the definition of the job roles and responsibilities, explaining the mission to the rest of the organization, creating the communication strategy, and all of the other tasks associated with getting data governance up and running.
That’s a lot kinder than just handing a newly hired data governance leader a blank sheet of paper and saying “good luck!”
And until you’ve got the bodies in the seats, data governance probably isn’t fully real at your organization yet.
Philosophy of MDM
My philosophy of MDM is simple: all things being equal, enter and manage master data in its own repository or hub, and pay the same attention to the organization and business processes for creating, distributing, updating and retiring master data that you do for other types of data within the enterprise.
You’d be amazed how often that simple statement confounds people though. They want to enter master data in their ERP or CRM system, and then synchronize it over to the MDM hub. Or they’d like to somehow do without an organization to manage their master data for the enterprise. Or they’re willing to concede the need for a data governance group, but don’t think that group will need any formal processes or technology to help orchestrate their work or facilitate it and improve their productivity.
Even though the link between data quality tools and master data management is well established, I sometimes still see people try to do MDM projects without using data quality technology. And even though synchronizing the high quality master data available in the hub should be a high priority, people (typically for cost reasons) still try to skimp on integration technology and try to get by with only the most basic ETL tools.
One of the most popular articles we’ve had here on the Hub Designs Blog was the Five Essential Elements of MDM, in which I laid out what I thought were the most important related areas of technology. In it, I included the MDM hub itself, of course, and also data quality, data integration, middleware, third party content and data governance (which of course, is not really technology, but needs to be included because it too is so often forgotten).
So getting back to the focus of this article, my philosophy of MDM is to have all of the essential elements, to have a sound vision and strategy for MDM, a strong business case based on metrics, to create a governance framework and organization to carry it out, to design governance processes, and then (last but not least) to implement technology to facilitate the governance needed to support the enterprise’s master data requirements.
So often today, we see organizations taking a technology-driven approach, or leaving out important parts of the above approach. Have you thought your MDM initiative all the way through?
Recent eLearning Curve Webinar
Hub Designs recently hosted a 30 minute webinar on “Best Practices in MDM and Data Governance with Dan Power”, in concert with our friends at eLearning Curve and Information Management magazine.
To download the replay of the webinar (with audio), please go to http://bit.ly/hub-designs-webinar. To download just the slides, please go to http://bit.ly/mdm-best-practices and click “Download”.
For the “When Data Governance Turns Bureaucratic” white paper mentioned in the presentation, go to http://bit.ly/data-governance. Scroll to and click the link at the end of that article.
Thanks for attending the webinar (or the replay). We hope you found it valuable!
Kalido MDM and AB InBev
The Gartner MDM Summit in Las Vegas wraps up today, and this morning I caught a session by Kalido’s President and CEO Bill Hewitt and Jonathan Starkey, the Director of Business Intelligence at AB InBev North America.
AB InBev purchased Anheuser Busch in 2008 to become the largest brewer in the world, with over 116,000 employees worldwide and $39 billion in annual revenue.
AB InBev sees master data as a foundation element supporting supply chain management (SCM), enterprise resource planning (ERP) and customer relationship management (CRM). All of that data winds up in a data warehouse and is used for reporting and planning. This shared focus on both reporting and analysis, and planning and forecasting makes up their philosophy on business intelligence.
This integration approach is being to bring together the Canadian and US operations gradually over time, but to integrate the SCM, ERP and CRM pillars of the US and Canadian operations of such a large enterprise realistically is going to take three to five years.
Turning more to the master data side of things, the first way AB InBev is using Kalido is to synchronize and cross-reference product and customer information across SCM and ERP systems. Secondly, they’re using Kalido to look for active exceptions across all of the various domains – between plants and products, between employees in HR and in ERP, between any two systems where master data is not in agreement. Thirdly, they’re using Kalido to kick off requests for new master data – new employees, new products, etc. that then get passed to various systems around the company.
The “real world” benefits from Kalido at AB InBev include procurement savings, strategic inventory optimization, overhead and budget tracking, people and resource movement tracking.
AB InBev went through a rigorous selection process, and selected Kalido in large part because of its ability to change rapidly as their business needs changed. Jonathan Starkey said ”Kalido does a very good job at managing change over time”.
I really enjoyed this session. Both Bill Hewitt and Jonathan Starkey did a great job, and it was enlightening to hear how a large global enterprise has addressed their MDM and business intelligence needs. Hub Designs recently became a Kalido partner, and one of our goals for this Gartner MDM Summit was to learn more about the company and their products, and this session definitely helped us do that.
For more information on Kalido, please visit www.kalido.com.
Evolving from Product MDM to Multidomain MDM
I’m attending the Gartner MDM Summit in Las Vegas, and this morning I caught a great session by Andrew White on the evolution from master data management (MDM) of product data to “multidomain MDM”.
Andrew started by talking by talking about the strong intersection of product MDM with enterprise resource planning (ERP), workflow, product configuration, and business rules. The market for product MDM is fairly healthy and is actually a little larger than the market for customer MDM.
The initial need to master product data usually arises from having too many copies of product data in different places around the enterprise. Then typically, product data quality issues need to be addressed, but that needs to be addressed as a continuing process, not as a one-time process.
Multi-channel commerce is known as the “sell side” of product MDM, and procurement is known as the “buy side”. There’s involvement with fulfillment and supply chain management, and with ERP and operations. There are many different silos that need to be connected and synchronized (one client I worked with last year had 175 different applications, systems and databases, most of which used or created product data in some way).
At some point, governance has to be addressed. Companies have to go from departmental or business unit governance to enterprise-wide data governance, and expand from single domain (typically customer) to multidomain (customer and product) master data governance.
Andrew mentioned the level of Product MDM adoption – there was software license spending of $432 million in 2008. Certain industries such as discrete and process manufacturing, communications, retailing, and healthcare providers are classified as “hot” according to Gartner (as of Q1, 2010). Retail in particular is almost post-recession. Healthcare providers has more awareness on the buy side.
A common scenario for some is to have a product MDM hub as a system of record, connected to CRM systems for sales & marketing and customer service, to PLM (product lifecycle management) as a system of reference, and to ERP systems (which need the data for their Item Masters). So the CRM, PLM and ERP systems are process owners, but the MDM platform provides the product and material master data, attributes, hierarchies and so on, for consumption by the other systems.
Andrew talked about how the inquiries he gets break down: ERP and MDM: 50%, product data quality: 33%, information exchange: 15%, metadata management: 10% and content management: 20%, and “can I use my CDI hub to master product data?”: 10%.
Andrew talked briefly about the current vendors in the product MDM space: the specialists (handling just product data) such as Hybris Software, Heiler, QAD, Pindar, Tribold, Requisite Technology, EnterWorks. He categorized Stibo Systems, Riversand and Tribold as being somewhere in the middle between specialists and generalists (handling other domains).
Oracle, IBM and SAP are strong on product MDM and customer MDM. Tibco and Informatica (formerly Siperian) are customer MDM providers that are moving towards handling the product MDM domain. Microsoft is entering the MDM space but their solution (when it is released later this year) is really suited more for analytical use.
And other vendors such as Data Foundations and Orchestra Networks can model any domain of data, including product data.
Through the end of 2013, you might need two MDM platforms. IBM has three MDM products (IBM InfoSphere MDM Server, MDM Server for PIM which handles complex workflow, and their recent acquisition of Initiate). Other strong vendors include SAP, Oracle and Stibo Systems.
The five-year market growth rate is projected at 18%. The Top Five products have 51% of the market. Vendors to watch include Teradata, INformatica, Tibco and Hybris.
Over the next 12 months, product configuration remains an unsolved problem. Companies typically define business rules all over the place. Over the long term, in MDM, that doesn’t work – those business rules themselves need to be governed centrally. The master data and the business rules both need to be governed. Successful product MDM requires business rules governance.
Reference data is another area – price is NOT master data but it behaves like master data in a lot of ways. It needs to be governed and managed. Business process management and its intersection with MDM is another area of development.
Data quality for product data has its foibles. You need to know where you’re starting from. Most importantly, data quality is not a once and done thing, it’s an ongoing process.
The product master data life cycle looks like: Author > Store > Publish / Synchronize > Enrich > Consume > Analyze.
The picture for the future – there are three main “provinces” for MDM: the “thing” province, the “party” province and the “place” province. But vendors typically have a history in a single domain.
Andrew gave a couple of great example of companies that went through the evolutionary process of going from a single domain of MDM to multiple domains over time.
Andrew closed with recommendations for people beginning their MDM process: create a vision of what could be achieved with a “single view of product data”, to start small but think big and deliver value early, and to define data and process metrics early and then to revise then as needed as you go along.
I’ve been a big fan of Andrew White for several years now, and I thought he did a great job today (as usual). He brings a great deal of analysis to bear on the questions involved in product MDM, and provides clarity and insight into where the MDM market is headed over the next several years. If you’re attending the Gartner MDM Summit in Las Vegas, or have a chance to catch his sessions at a future event, I think you’d find those sessions very rewarding.
Building a Next Generation Business using AIA
This afternoon at Oracle OpenWorld, I attended a great session led by Darrin Pohlman, Enterprise Architect at LexisNexis and MK Rizwan from Infosys.
They talked about the enterprise transformation program at LexisNexis, and the strategic use of technology to enable and drive that transformation effort.
MK started by pointing out the constraints of the single, global instance application strategy. You’re constrained by the vendor’s application architecture, and not all the functionality is best-of-breed across the entire suite. There are inevitable customizations and extensions which pile up over time, which leads to ever-increasing Total Cost of Ownership. It’s difficult to introduce industry-specific functionality, and it takes a long time to introduce new business models or capabilities.
The trend recently has been toward unbundling of the packages through SOA integration such as Oracle’s Application Integration Architecture (AIA) and the accompanying Process Integration Packs (PIPs). Further trends include vendor consolidation – Oracle acquiring Siebel, Hyperion, BEA, etc.
Interestingly, MK mentioned the important of prioritizing master data management, which got my attention, and he mentioned that would be particularly as people started to migrate in the future to the Fusion Applications products.
They went on to talk about AIA, particularly foundation packs, process integration packs and direct integrations. The foundation pack provides shared services, design patterns and standards. It runs on Fusion Middleware.
Darrin discussed the pro’s of AIA: good reference model for building composite applications, standards-based, extensible for unique characteristics of your business, and where Oracle is eager to demonstrate successful implementations. On the con side, PIPs can be tightly coupled, and the versioning of the AIA foundation pack can depend on specific versions of Siebel and other Oracle applications. Also, there are change management considerations of the IT team. There are licensing and maintenance considerations as well.
LexisNexis is an early adopter of this technology but has to plan for multiple upgrades over the next 12-18 months.
The audience was very engaged and asked some great questions during the session.
I found the session very helpful in better understanding the underlying enterprise architecture and technology strategy that LexisNexis is pursuing, and how Oracle’s Application Integration Architecture fits into that strategy, and Darrin and MK did a great job in explaining the pro’s and con’s of the approach and the experience that LexisNexis has had with it so far.
Like this:
New Data Governance White Paper
A new white paper by Dan Power of Hub Designs is available on Siperian’s web site.
The white paper underscores the importance of a proactive data governance approach, and is designed to help organizations develop a sound and sustainable data governance initiative.
Data governance is a vital component of any master data management effort, since it defines who owns the data, who establishes policies, and who the decision-making authority is when it comes to an organization’s critical data assets. However, many companies tend to take a limited and reactive approach to data governance.
In this new report titled, “When Data Governance Turns Bureaucratic: How The Data Governance Police Can Constrain the Value of Your Master Data Management Initiative”, we outline the limitations of a reactive data governance strategy and urge organizations to adopt a proactive data governance approach, whereby master data is corrected and validated right at the source and often by the business user. This removes potential data stewardship “bottlenecks” and eliminates critical time lags that may occur between the initial entry of a new master record, its certification/ publishing, and its ultimate availability to the rest of the enterprise.
To access the full report, visit http://forms.siperian.com/content/PowerGovernancePR.
Modeling the MDM Blueprint – Part 6
In this series, we’ve discussed developing the MDM blueprint by developing the Common Information (Part 2), Canonical (Part 3) , and Operating (Part 4) models in our work. Part 5 introduced the Reference Architecture model into the mix to apply the technical infrastructure or patterns we plan on using.
The blueprint has now moved from being computation and platform independent to one that expresses intent through the use of more concrete platform-specific models. The solution specification is now documented (independent of the functional Business Requirements) to provide shared insight into the overall design.
Now, it’s time to bring the modeling products together and incorporate them into a MDM solution specification we can use in many ways to communicate the intent of the project.
First, the MDM blueprint specification becomes the vehicle for communicating the system’s design to interested stakeholders at each stage of its evolution. The blueprint can be used by:
- Downstream designers and implementers to provide overall policy and design guidance. This establishes inviolable constraints (and a certain amount of freedom) on downstream development activities.
- Testers and integrators to dictate the correct black-box behavior of the pieces that must fit together.
- Technical managers as the basis for forming development teams corresponding to the work assignments identified.
- Project managers as the basis for a work breakdown structure, planning, allocation of project resources, and tracking of progress by the various teams.
- Designers of other systems with which this one must interoperate to define the set of operations provided and required, and the protocols for their operation, that allows the inter-operation to take place.
Second, the MDM blueprint specification provides a basis for performing up-front analysis to validate (or uncover deficiencies in) design decisions and refine or alter those decisions where necessary. The blueprint could be used by:
- Architects and requirements engineers who represent the customer. The MDM blueprint specification becomes the forum for negotiating and making trade-offs among competing requirements.
- Architects and component designers as a vehicle for arbitrating resource contention and establishing performance and other kinds of run-time resource consumption budgets.
- Development using vendor-provided products from the commercial marketplace to establish the possibilities for commercial off-the-shelf (COTS) component integration by setting system and component boundaries and establishing requirements for the required behavior and quality properties of those components.
- Architects to evaluate the ability of the design to meet the system’s quality objectives. The MDM blueprint specification serves as the input for architectural evaluation methods such as the Software Architecture Analysis Method [and the Architecture Tradeoff Analysis Method (ATAM-SM) and Software Performance Engineering (SPE) as well as less ambitious (and less effective) activities such as unfocused design walkthroughs.
- Performance engineers as the formal model that drives analytical tools such as rate schedulers, simulations, and simulation generators.
- Development product line managers to determine whether a potential new member of a product family is in or out of scope, and if out, by how much.
Third, the MDM blueprint becomes the first artifact used to achieve system understanding for:
- Technical managers, as the basis for conformance checking, for assurance that implementations have in fact been faithful to the architectural prescriptions.
- Maintainers, as a starting point for maintenance activities, revealing the areas a prospective change will affect.
- New project members, as the first artifact for familiarization with a system’s design.
- New architects, as the artifacts that (if properly documented) preserve and capture the previous incumbent’s knowledge and rationale.
- Re-engineers, as the first artifact recovered from a program understanding activity or (in the event that the architecture is known or has already been recovered) the artifact that drives program understanding activities at the appropriate level of component granularity.
Blueprint for MDM - Where this fits within a larger program
Developing and refining the MDM blueprint is typically associated with larger programs or strategic initiatives. In this last part of the series, I'll discuss where all this typically fits within a larger program and how to organize and plan this work within context.
The following diagram (click to enlarge and use your browser to magnify the png file) puts our modeling efforts within the context of a larger program taken from a mix of actual engagements with large, global customers. The key MDM blueprint components are highlighted with numbers representing:
- Common Information Model
- The Canonical Model
- The Operating Model
- The Reference Architecture
Click to enlarge
I have also assumed a business case exists (you have this right?) and the functional requirements are known. Taken together with the MDM blueprint, we now have a powerful arsenal of robust information products we can use to prepare a high quality solution specification that is relevant and can be used to meet a wide variety of needs.
Typically, use of the MDM blueprint may include:
- Identifying all necessary components and services
- Reviewing existing progress to validate (or uncover deficiencies in) design decisions; refine or alter those decisions where necessary
- Preparation of detailed planning products (Product, Organization, and Work Breakdown structures)
- Program planning and coordination of resources
- Facilitating prioritization of key requirements – technical and business
- Development of Request for Quotation, Request for Information products (make vs. buy)
- Preparing funding estimates (Capital and Operating Expense) and program budget preparation
- Understanding a vendor’s contribution to the solution and pricing accordingly (for example, repurpose as needed in contract and licensing activities and decouple supplier proprietary lock-in from the solution where appropriate)
We are also helping to ensure the business needs drive the solution by mitigating the impact of the dreaded Vendor Driven Architecture (VDA) in the MDM solution specification.
Summary
I hope you have enjoyed this brief journey through “Modeling the MDM Blueprint” and have gained something from my experience. I’m always interested in learning from others, so please let me know what you’ve encountered yourself, and maybe we can help others avoid the pitfalls and pain in this difficult demanding work.
The difference between success and failure on an MDM journey is taking the time to model the blueprint and share this early and often with the business. This is after all a business project, not an elegant technical exercise. In an early reference, I mentioned Ward Cunningham’s Technical Debt concept. Recall this metaphor means doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort we have to do in future development because of the quick and dirty design choices we have made. The technical debt and resulting interest due in MDM initiative with this kind of far-reaching impact across the enterprise is, well, unthinkable.
Take the time to develop your MDM blueprint and use this product to ensure success by clearly communicating business and technical intent with your stakeholders.
Go back to Part 5.
2009 Predictions
digg this | 
del.icio.us | 
Reddit | 
Stumble It!
In November, I attended Gartner’s second MDM Summit conference in Chicago.
One of the topics people were talking about at that conference was how well the Master Data Management market would fare in an economic downturn.
Certainly, companies that were just “testing the waters” on MDM may cancel or slow down their initiatives, and anyone making the front pages or the nightly news (and not in a good way) is probably going to see some disruption to their Master Data Management efforts.
But I’ve been pleasantly surprised by how much interest and activity we’ve seen, particularly since 2009 started.
Friends in the MDM space report getting a slew of new opportunities recently, especially in the healthcare and pharmaceutical industries. Industries like that are doing relatively well, and even in affected industries like retail, some companies are “swimming against the tide” and investing into the downturn, looking to take market share and revenue from their competition who are cutting investments and going into hibernation mode.
Barney Beal on SearchDataManagement.com described the picture at BJ’s Wholesale Club:
[John Polizzi, senior vice president and CIO] “Our plan was not an investment in a master data management (MDM) system, or an ERP implementation, or a point of sale (POS), but rather all of them — and more. BJ’s is embarking on a five-year transformation of its IT infrastructure and systems.”
Philip Lay, managing director of TCG Advisors, who spoke at the Gartner conference, said “now is the time to buck conventional wisdom and ‘think like a contrarian’ when it comes to MDM.” Lay advised the attendees “the key to making a successful business case for MDM is to tie MDM to specific, broken business processes” and quantify that impact.
I wrote an article for DM Review on “Easing into Master Data Management” which describes how to get started by building a data governance program first, with existing resources and applications, and tackling data quality and data integration as predecessor steps to MDM.
Certainly, one of the classic drivers for MDM has always been reducing costs – and that’s even more important in a recession (look for a guest post on this topic in a few days from Ravi Shankar at Siperian).
But even more important is to grow the “top line” – to increase revenue and pull customers away from your competitors, through better information, better customer service, better products, better pricing, you name it.
In 2009, I predict the MDM market will be affected somewhat by the recession, but it will still be one of the fastest-growing software segments, as Gartner has been predicting too.
But let’s tap into YOUR collective intelligence – what do you think? Please comment here or on the MDM Community.
Building the Business Case (Part 4) – Gaining Alignment
digg this | 
del.icio.us | 
Reddit | 
Stumble It!
In the previous installments of this series, we covered three key drivers for building your business case: Risk Management, Cost Reduction, and Revenue Growth.
Now, we’ll review the importance of and the process for gaining organizational alignment with your strategy.
When you’re building support for your business case, it’s critical to gain alignment at all levels of the organization throughout the whole process. Making the case for an information management strategy cannot rest with only one executive. And it can’t be the brainchild of IT only, or lack executive sponsorship altogether.
You need as many areas aligned as possible. More than likely, a comprehensive information management strategy needs to consider all of the data streams across the enterprise (at some point), and will therefore be fairly time and resource intensive.
If you take a three-pronged approach to gaining alignment, then you’re well on your way to obtaining approval to implement your strategy:
(1) Get front-line employees and customers to identify the problems with the data. You should have been gathering their feedback and facts as you built your case. So when you can readily articulate that customers are frustrated with your company, or that your employees are performing workarounds, rework, or aren’t as effective as they could be, then you’ve got your “first-level buy in”.
(2) You need their individual management teams to agree that these issues exist. They need to agree that they’d be more effective in achieving their goals if they had a solution to their information problems. And most importantly, if you can get them to agree that an information management strategy should be a priority and they support the contents of the business case (which shouldn’t be too difficult if you had their support during the development of the business case), then these folks become your best allies.
(3) Have those management teams bring this message forward to their leadership. When the leaders hear, directly from their own people, that they should understand and support the business case, then your business case has achieved a level of credibility you wouldn’t have gained on your own. And your role then becomes one of subject matter expert, business case developer, and valued business partner.
I do recommend getting several executives aligned to the strategy. Because of the size of the undertaking, you’ll need several leaders to prioritize and support the effort. Providing headcount, funding and the time to deliver on the plan will be crucial from these leaders.
Once again, the more compelling your business case (whether it’s to comply with regulations, reduce costs or improve revenues), the more chance you’ll have in gaining attention and alignment.
Which brings us to the final point: set up your program so that small wins are achieved throughout.
Whether you need to set up prototypes, pilots, or small projects while you are driving the entire strategy over time (probably several years), you need to prove results. Otherwise, no matter how great your plan, the organization will lose interest along the way.
So, if you set expectations appropriately, have a good measurement plan in place, and keep communicating constantly with all levels of the organization, then you’ve got a great chance of succeeding!
Is There Such a Thing as a “Quick MDM Strategy”?
digg this | del.icio.us | Reddit | Stumble It!
Well, the short answer is – “it depends”! Putting aside the conventional answer for the moment, I’d say that a critical first step in achieving a pragmatic MDM strategy is that your company must agree and commit to developing a 3-5 year MDM strategy.
This is not as simple as it may sound. Successfully executing an MDM strategy with a 3-5 year vision requires a considerable cross-functional effort and substantial agreement on some vexing political, business and technology issues. More on this later.
The following situation is not uncommon. A senior executive at the company decrees that the company needs an MDM solution to remain competitive or to fix nagging data issues. The vendor selection team jumps into action, solicits requirements from business owners, puts together a vendor questionnaire and contacts vendors.
The next few months are taken up with defining selection criteria, sitting through vendor demonstrations and digesting different vendors’ current approach to MDM and their future roadmaps.
The promise of a business intelligence solution, with a Single View of Customers, across CRM and ERP systems, through a federated or persistent hub is now only months away.
The demos were impressive and installation is promised to take only 8-12 weeks. After all, the company has already implemented CRM and ERP solutions, so the next solution should be much quicker – right?
Which brings us back to “it depends” The reality is that this approach may work for certain companies. Those companies who have matured through CRM and ERP implementations, who have well defined business needs and change management projects under their belts, with well documented business processes and a Project Management Office already in place stand the best chance to succeed.
But then these are the very companies who already know that they need to develop an MDM strategy, often with the help of consultants.
And this leads us to the question of developing an MDM strategy. How comprehensive does the strategy need to be? How much time is reasonable to spend developing a strategy? Can a staged approach be taken on the strategy, for example just start with customers and worry about other domains once that is working? Can we just bring a hub up with our current customer data and go from there? These are all valid questions.
One of the biggest factors that will help answer these questions is an organizational readiness assessment.
The strategy process should develop a vision for data governance, business outcomes, business processes and technology for the company. The process will touch on situation analysis, goals and objectives, strategy development, implementation plans and change management. Involving consultants through the process can greatly speed the process for many companies.
Our recommendation is that no matter how tempting a “quick win” approach to implementing MDM may seem – make sure you take some time up front to develop your strategy with both short and long term goals. Make sure that strategy is accepted throughout the organization and that the short term goals are on the correct path to solving the longer term business objectives.
This can help you avoid having to “rip & replace” your MDM solution shortly after building it, and help prevent you from creating MDM “data silos” because your strategy didn’t take into account other critical enterprise data domains beyond the immediate situation.
MDM can be a “game changing” initiative, giving the enterprise clean, consolidated, complete data for the first time, driving increased revenue, decreased costs and improved compliance. But as Stephen Covey says, make sure you “begin with the end in mind”.
