Master data management - it's about information not technology

The concept of master data management (MDM) is not a difficult one to grasp: It is the process of dealing with data that needs to be shared among different systems—accessible to multiple users — often by merging records into one authenticated master file. In the corporate world, the best example of this would be the customer master file: various departmental applications in a corporation store customer information; the organization needs to ensure that the customer data does not conflict from one system to another.

While simple in concept, those who have attempted to implement MDM will tell you that it is easier said than done. A great amount of effort is required to integrate applications so that shared data remains in sync.

Government has the same needs as corporations regarding MDM. In fact, you could argue that government's needs are even more critical due to the nature of some of that data. Take, for example, the databases of those organizations involved in homeland security. Much of the post-911 criticism of the United States' intelligence capabilities centered on the inability of the FBI, CIA, NSA, and related agencies to share information with one another - even, in many cases, the difficulty of sharing data between different departments within a single agency.

What outsiders fail to realize is that on top of all the regular challenges associated with MDM, governmental bodies are subject to rules and regulations that often prevent or discourage the sharing of data within their own departments - let alone with other agencies! And as icing on the cake, you have all the political baggage that can rear its ugly head.

Data-sharing is more than a technology problem

So what is the answer for government when it comes to MDM? Is it service-oriented architecture (SOA) or perhaps the latest software solution from SAP or IBM? No. While these solutions can play a part in the final answer, approaching MDM as only a technology problem will get you into trouble right away. The technology portion of this problem is not the challenge. There are lots of smart people and capable technologies that can move the data and merge it intelligently when the time comes to do it. Data transfer mechanisms, protocols, XML, database software, or hardware can be brought into play once the real challenge is met.

That challenge is identifying what data is being collected, why it is being collected, who is doing the collecting, where it is being stored, and most importantly, who "owns" it and what barriers prevent it from being shared.

So when talking about MDM in government, we are first talking about understanding complex business processes/systems and performing the appropriate data analysis, coupled with some strong management and negotiation skills.

I am currently early in my fourth major effort of this kind, and the same issues that I have encountered before are starting to make their appearances again. Just in case you are planning your own MDM/data-sharing efforts, here are some of the challenges you might face:

• The organizational units (OUs) involved in the MDM project are usually quick to identify issues of data inconsistency and other data-sharing problems, but the pain experienced from these issues is often not enough to make them want to share/play nice.
• OUs usually have strong feelings toward "their" data. Data is not usually viewed as belonging to the umbrella organization but rather to the unit/department that collects it.
• OUs will gladly express how willing they are to share data/participate in the process until you start getting into the nitty-gritty details of what is required of them — especially if those requirements mean compromising.
• OUs often do not understand their own business processes. Don't assume that this means that they don't know how to do their jobs. They do, but they don't often understand why they do things that way.
• Related to the point above, OUs often are unclear about what the rules and regulations say about what data they can and can't share. They may point back to a rule that has been followed forever, but after further analysis you will find that the rule or regulation has either expired, been misinterpreted, been too broadly applied, was only offered as guidance, or is otherwise outdated.
• Conversely, you will find a rule or regulation that is very clear on what data can or cannot be shared but makes absolutely no sense. Either circumstances will have changed since the rule went into effect (you'll find the same data is already available elsewhere in the organization) or it is clear that someone created the rule not to protect the privacy of the data but to make sure that no one else got their hands on the data.
• Rules and regulations can be changed — sometimes it just takes a while.

With these issues in mind, here are some of the most critical factors for success:

• Realize that MDM is not a technology-driven effort. There will be time enough for the technological solutions. This is mainly a process/data-gathering effort.
• Get support from top management. Even with the most skillful negotiations and consensus-building efforts, there will be times when rules/regulations/processes will need to be changed or removed, reluctant players will need to be "convinced" to cooperate, and bargains will have to be struck at higher levels. These situations require strong support and commitment from executive management.
• Look at the details. Do not take someone’s word for why they cannot share data. Find out the specifics, and research it as much as possible. Too much of what goes on in day-to-day operations is built on faith and misunderstood directives. Find out the "truth" behind all obstacles.
• Be creative and keep an open mind. Encountering an obstacle in the form of a rule or regulation or non-cooperation does not mean the end of the line. It just means you are going to have to develop a workaround.
• Create a participative environment and never stop touting the benefits of shared/consolidated data.
• Above all else, get good analysts - particularly the kind that are tenacious about getting the best information possible. This is the portion of the project where you do not want to skimp on manpower. The more thorough the effort, the better off you'll be in the end.

Master data management and data sharing is not an impossible effort in a government environment; it just happens to be a more difficult process than in other settings. Hopefully these insights into the process will help you get started on the right foot concerning your own efforts and help you plan accordingly. Best of luck!