This article captures a session at the recent conference of the Data Governance SIG of the Americas SAP User Group (ASUG) by George Bryce, Corporate Data Architect at Procter & Gamble. Read more
Today’s guest article is by Dalton Cervo, the co-author of a great new book titled Master Data Management in Practice – Achieving True Customer MDM. Read more
While I’m on vacation for the next two weeks, Hub Designs Magazine will be republishing some of our most popular articles and series. This article, from an ongoing series on Data Governance sponsored by SAP, was first published on March 20th.
The most important thing about data governance is to “start from where you are”. Most companies are just getting started on their data governance journey. It can be hard to admit that your company is at data governance maturity level 0 or 1. But the most critical step is the first one – getting started. Read more
In a new form of “shadow IT”, Line-of-Business (LOB) groups have been turning to cloud-based services to quickly set up technology solutions that support their business needs and objectives. Read more
Today’s guest article is by Dalton Cervo, the co-author of a great new book titled Master Data Management in Practice – Achieving True Customer MDM. Read more
This is the first article in an ongoing series on Data Governance sponsored by SAP.
The most important thing about data governance is to “start from where you are”. Most companies are just getting started on their data governance journeys. It can be hard to admit that your company is at data governance maturity level 0 or 1. But the most critical step is the first one – getting started. Read more
How many of us in the consulting profession can truly say we’ve been taught to develop, refine, and deliver a professional strategy roadmap based on a sound method with consistently repeatable results? Having been at this crazy business for years, I’m still astonished at the wide variety of quality in the results I see over the years – and it’s not getting any better.
I’m not sure I can identify why this is so. Maybe it’s the consolidation and changes in the traditional consulting business (Big Eight to what? two, maybe) or the depreciation of the craft itself among our peers. Then again, maybe sound planning went out of style and I just didn’t get the memo. No matter what the root cause(s) is, I want to take a little time and share some (not all) of what’s worked for me with great success over the years and maybe make your next roadmap better.
I’m no genius, I just believe I’ve been blessed to come into the industry at a time when the large management consulting firms actually invested in intellectual property and shared this with the “new hires” and up-and-coming people like me. Investing in structured thinking, communication skills, or just plain good old analytic skills makes sense. Why there isn’t more of this kind of investment today is truly troubling.
What I’m going to share works well across most transformation programs. You will struggle to find this in textbooks, class rooms, or your local book store (I’ve looked, but maybe not hard enough). The method I’ll share here is based loosely on the SEI-CM IDEAL model used to guide development of long-range integrated planning for managing software process improvement programs. You will most likely find something similar to this in the best and brightest organizations who’ve adopted an optimized way to think about how to guide their organizations to perform as expected (some of us call this “experience”). Now on to the summary of what I want to share, the balance will be revealed in an upcoming series using the adoption of Master Data Management technology and data governance organization and processes as an example.
The Overall Pattern
At the risk of over-simplifying things, here is the overall pattern ALL roadmaps follow:
1) Develop a clear and unambiguous understanding of the current state
- Business Objectives (not just strategy or goals, real quantifiable objectives)
- Functional needs
- High impact business processes or cycles
- Organization (current operating model)
- Cost and complexity drivers
- Business and technical assets (some call these artifacts)
2) Define the desired end state
First, (I know this is obvious) what are you trying to accomplish? Is there an existing goal-driven strategy clearly articulated into quantifiable objectives? This sounds silly doesn’t it, and if this exists and no one knows about it or cannot clearly communicate what the end game is, we have a problem. It could be a well guarded secret. Or what is more common, the line of sight from executive leadership down to the mail room is broken, where no one knows what the true goals are or cares (it’s just a job after all) becomes a annual charade of “Management by Objective” objectives with no real understanding. Some better examples I would expect include:
- Performance targets (Cash flow, Profitability, Velocity [cycle or PCE], Growth, Customer intimacy)
- Operating Model Improvements
- Guiding principals
3) Conduct Gap Analysis
Okay, this is where the true fun starts. Once here we can begin to evaluate the DELTA between who we realistically are, and what we truly want to become. Armed with a clear understanding of where we are and where we want to be, the actionable activities begin to fall out and become evident. Gap closure strategies can then begin to be discussed, shared, and resolved into any number of possibilities usually involving the following initiatives:
- Architectural (technology)
- Reward or economic incentives
For the enterprise architect, the following diagram illustrates a sample index or collection of your findings to this point, focused across the four architecture domains (Business, Information, Application, and Technology) related to the architecture. Note how this is aligned into the enterprise architecture meta-model you can see over at the Essential Project. The DELTA in this case represents the recommended Gap Closure Strategy between the current state and the desired end state. Or put simply, the actionable things we need to do to close the gap between where are, and where we want to be.
Now that we have the list of actionable items, it’s time to prioritize what is front of us. This is usually driven (in a technology road map) by evaluating the relative business value AND the technical complexity, plotting the results in a quadrant graph of some kind. It is critical here that the stakeholders are engaged in the collection of the data points and they are keenly aware of what they are scoring. At the end of the day, what we are doing here is IDENTIFYING what is feasible and what has the highest business value. I know, I know – this sounds obvious, and you would be astonished by how frequently this does not occur.
5) Discover the Optimum Sequence
Okay, now we have the initiatives, the prioritization, how about sequence? In other words, are there things we have to get accomplished first, before others? Are there dependencies we have identified that need to be satisfied before moving forward? This sounds foolish as well, and we sometimes we need to learn how to crawl, walk, run, ride a bike, and then drive a motor vehicle. And what about the capacity for any organization to absorb change? Hmmm… Not to be overlooked, this where a clear understanding of the organizational dynamics is critical (see step number 1, this is why we need to truly understand where we are).
6) Develop the Road Map
Now we are ready to develop the road map. Armed with the DELTA (current vs. desired end state), the prioritization effort (what should be done), and the optimum sequence (in what order), we can begin to assemble a sensible, defensible road map describing what should be done in what order.
How this is communicated is critical now. We have the facts, we have the path outlined, and we have a defensible position to share with our peers. We have the details readily available to support our position. Now the really difficult exercise rears its ugly head. Somehow, we need to distill and simply our message to what I call the “Duckies and Goats” view of the world. In other words, we need to distill all of this work into a simplified yet compelling vision of how we transform an organization, or enabling technology to accomplish what is needed.
Do not underestimate this task, after all the hard work put into an exercise like this, the last thing we need to do is to confuse our stakeholders with mind-numbing detail. Yes, we need this for ourselves to exhaust any possibility we have missed something. And to ensure we haven’t overlooked the obvious – not sure who said this but “when something is obvious, it may be obviously wrong”. Here is another example of a visual diagram depicting an adoption of Master Data Management platform in its first year.
So, this is the basic pattern describing how a robust roadmap should be developed for any organization across any discipline (business or technology) to ensure an effective planning effort.
I wanted to share this with you to help you with your own work; this is usually not an exercise to be taken lightly. We are after all discussing some real world impacts to many, all the while understanding the laws of unintended consequences, to come up with a set of actionable steps to take along the way that just make sense. This method has worked for me time after time. I think this may just work for you as well. More on this later in the next article in this series …
A member of that community, Mohd Khairi, reached out to me recently for help in his research. He’s collecting data about MDM architectural models for his Ph.D. dissertation. He’s put together some questions in the form of a survey. He’s already gotten some responses on the The MDM Community, which was great, but I thought we’d open it up to all of our readers here, in order to give him a better sample size for his research.
Here’s a brief writeup from Mohd on what he’s trying to achieve with his survey:
In Master Data Management (MDM), centralized and federated architectural models play a major role in managing master data. The centralized model allows an organization to organize and manage master data in a single, centralized repository. Alternatively, a federated model doesn’t keep the master data in one database, instead it allows users to query the master data from multiple sources using the MDM tool. Project leaders and company stakeholders have to choose the right model for their organizations. This study examines the centralized and federated models and provides decision makers with insights into determining the proper model for their organization.
Please help our colleague with his study by answering the survey questions using this link: http://www.surveymonkey.com/s/MDM_Survey_Update.
Thank you in advance for your help!
Image credit (c) 2010 Rob Nguyen
Well, another year has nearly passed, and I’d like to say “thank you” to everyone who has read and supported this blog over the past three and a half years.
Only one thing has made this blog possible: you. Whether you came here to learn about master data management (MDM) and data governance, or to follow the development of the consulting firm Hub Solution Designs, your support is what has kept us writing, with 265 articles to date.
We’ve had some great guest authors over the years, whose work you can see on the Top Series page. They’ve helped to bring great insights and ideas to the blog; I hope you take the time to check out their work.
Our MDM Best Practice series was very popular this October, with the series as a whole receiving more than 2,100 page views in the past two months. The shorter article on Ten Best Practices for Master Data Management, which led to the ten part series, has received 5,100 views so far.
A couple of the articles we’ve written about Oracle have proven popular as well: Oracle’s MDM Strategy and Roadmap, and the First Look at Oracle Fusion MDM Hub. Jim Parnitzke’s series on Modeling the Blueprint for MDM proved so popular, we re-ran it this summer, as did Rob DuMoulin’s series on Data Profiling for All The Right Reasons.
Our article on the Hidden Costs of Duplicate Customer Data has received 1,175 total views over the past year, and How Master Data Management is Similar to ERP has been averaging 200-300 views per year for more than three years now. MDM and Enterprise Architecture (also by Joan Lawson) is a good reminder of the central role that MDM plays in the practice of Enterprise Architecture.
I hope you enjoy reading the blog as much as I enjoy writing for you. And I hope your holiday season is filled with family, love and happiness, and that you have a safe, healthy and prosperous New Year!
Editor’s Note: Another great guest post by Joan Lawson, a talented enterprise architect who worked for one of my clients in the software industry in 2003. For more information on Joan, please see her LinkedIn profile — Dan Power
Master Data Management (MDM) may be one more Three Letter Acronym (TLA), but it’s a central point in the practice of Enterprise Architecture. Together with SOA-based applications and a robust middleware platform, an ideal architecture is readily achievable.
Let’s take an example using party data including customers and prospects. Party data may have a “system of initial record” in any of the many ERP or CRM applications that a company may have.
A message with new party data can be written to the integration platform from the CRM application. Based on business rules, a Business Process Execution Language (BPEL) system can orchestrate the data management services in the MDM hub, write the clean party data into the MDM hub, and then message the clean data to the other ERP and CRM applications.
Ditto with product master data.
In this example, customer and product dimensions in the data warehouse are managed by the “source of truth” – the MDM hub. And the fact data for the warehouse (such as quotes, orders, and service events) can be sourced from the OLTP applications.
For those interested in real time monitoring of transactional data, consider placing that data on the integration platform as well. A Business Activity Monitoring (BAM) platform taps into that data to monitor it against KPIs. And once again, the MDM hub provides the “source of truth” for the master data.
The end result? Clean, consistent master data, whether used in the business applications, the data warehouse and business intelligence platform, or in real time business activity monitoring.
Please let us know by commenting here or on the MDM Community if you’re using MDM as part of your enterprise architecture.
For more information on Joan, please see her LinkedIn profile — Dan Power
Let’s not allow Master Data Management (MDM) to become just another silo of data! MDM and Service-Oriented Architecture (SOA) together, create a strong partnership in your enterprise architecture.
1. Data Quality = Add Quality to SOA
SOA enables business functionality as a service. However, it does not guarantee quality of the data on which it’s operating. That’s a serious gap, which is filled by including MDM in a service-oriented architecture. True business value is realized as services start leveraging the high quality data in the MDM hub and the services which surround it.
2. Data Management Services Offered by the MDM Hub
MDM abstracts the governance of data by consolidating it into a central data model; conducting all data cleansing, augmentation, cleansing, and standardization; and creating a ‘gold standard’ source. These data management functions are centralized in the data hub and are hidden from the consumers of the cleansed data. Maximize the value of these services by consuming them from other applications that need to perform data quality processing external to the data hub.
3. Data Offered by the MDM Hub
Data services allow the consuming application to access and manipulate hub data from a service layer as a supported data source. Layering data services on the MDM hub hides the implementation of federated queries that gather the data requested by the consumer.
4. SOA, MDM, and middleware
SOA, integration middleware (Enterprise Service Bus or ESB), and MDM together can manage the detection of data changes in the source applications and propagate them from the source applications to the MDM – or from the MDM back to the consumers. With the addition of Business Process Execution Language (BPEL) and a business rules engine, a data change detected in a source can be captured, cause the data quality business rules to be executed on the data, and place the data back on the ESB to be consumed.
Are there other use cases for how MDM and SOA, together, add strength to the enterprise architecture? Please add your thoughts by commenting here or on the MDM Community.