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!