Master Data Management and data sharing in the government environment

by Ramon Padilla Jr. | Aug 01, 2005 7:00:00 AM

Tags: Vertical industries, Ramon Padilla Jr., Master Data Management, data sharing, government, Government IT Newsletter

Takeaway: Implementing any kind of data integration or data sharing project is always a lot more complicated than it looks. Sometimes the technology solution is the easy part. Ramon Padilla has some tips for those embarking on a Master Data Management project.

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, and 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. An example would be the databases of those organizations involved in Homeland Security. Much of the post-9/11 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, and in many cases, the difficulty of data sharing even among different departments.

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 other agencies! And as icing on the cake, you have all the political baggage that can rear its ugly head as part of being involved with the bureaucratic processes of governmental agencies.

Data sharing is more than a technology problem

So what is the answer for government when it comes to MDM? Is it SOA (Service-Oriented Architecture)—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 important, who "owns" it and what barriers are in place to prevent the data from being shared.

So you see, when talking about MDM in government, you are talking about, first, 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 once again, 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 my observations 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 bullet above, OUs often are unclear about the rules and regulations regarding 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, however it will make 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 had that data other than them.
• Rules and regulations can be changed—it just sometimes takes a while.

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

• Realizing 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.
• Having 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/or bargains will have to be struck at higher levels. These situations require strong support and commitment from executive management.
• The devil is in 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.
• Get good analysts above all else—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!

Print/View all Posts Comments on this article

Amen to thatmadtechgirl  | 08/16/06