Data administration is part of the job of making good systems. Sub-parts typically include data strategy, architecture, infrastructure support, data standards, and especially education of the
above. These are “overhead” tasks that are typically thankless, and for most people very boring. The quality of person required to do this kind of work well is very high, and requires a deep
interest in business as well as technical issues. The resources available to do these tasks are typically inadequate, and the Data Administration (DA) organization is often the only one available
to carry the ball. When the DA organization strays from its core job, then it is part of the problem because the data administration job won’t get done.
What is that problem? Permit me to first digress. I’ve tried to sell the idea of data standards enforcement tools to many people who manage software development projects. They have been to a
person uninterested – often monumentally uninterested. When pressed they usually say something to the effect of, they do not care much about data standards, but about getting their system up ASAP.
And besides that is what the DA or DBA organization is for, that I should perhaps talk to them. In my view, this is a symptom of the most profound underlying problem affecting the ability of
today’s enterprises to develop quality systems. The problem is: still, after years of fuss and theoretical lectures and enabling technology, stovepipe systems developed by teams with a parochial
mentality. Same problem as 15 years ago.
The basic DA mission is to help stamp out stovepipe systems, by which I mean critical applications and databases that can’t exchange data or work with other relevant systems. Every data
administration task should help guide movement toward that end.
Who’s responsibility is it to see that systems can exchange data (which is to say, that data standards are enforced, and also that the system has a well designed data architecture)? Well,
EVERYBODY’S: users, system developers, managers, and even data administrators. To often, the entire job gets thrown into the lap of a powerless and ineffective data administration shop that
everyone somehow pretends can take responsibility for carrying out what is truly a massive job – so massive that it cannot be accomplished through a set of neat worktasks by a small staff. The real
objective of data administration can only be accomplished when quality methods become a way of doing business for the entire organization; when is part of the culture.
Above I said that data administration may be the only one available to carry the ball. If that really is true in your organization than you are in big trouble. A DA is not a running back,
quarterback or lineman – DAs don’t do the line work. Nor is the DA the head coach. Maybe offensive coordinator or special teams coach is the closest analogy. The DA can at best hope to give the
rest of the team the direction, organization and will to get the main job done.
The DA coaching job is at least threefold. Its maintaining data standards and insinuating data standards into the development culture. This includes seeing that people know the scope of what should
be standardized, so that, for example, they know it’s OK to make up their own end-user meta data. Second it is championing the enterprise view of all data and all systems, such as through a
unified architecture and conceptual schema. This includes a repository of shared system meta data (which in it’s organization logically embodies the conceptual schema), and making sure that people
both understand and act on the necessity of good documentation. Third it is facilitating consolidated database development and the creation of standard data objects that can be reused, and seeing
that designers take the trouble to know what exists and how they can add to the body of components.
If the organization called DA cannot identify and do their part of the job, and do it right, then they are part of the problem. Doing it right does not mean publishing a soon-to-be-dusty-shelfware
manual, or a standards enforcement review the same week a system is to be delivered, even though these and other specific exercises have their value. Doing it right mostly means making sure that
the people who have the real responsibility – system developers, managers, and sometimes users – have the knowledge, tools, and desire to use data standards and design systems in accordance with
principals such as integration within the enterprise, and serving the enterprise “view”. Doing the data administration job right means taking on an ill-defined and multi-faceted educational,
mentoring, and standards enforcement role.
That is such a tough job that it is no surprise that many data administration shops have latched on to the sexy end-user-support data warehousing work that has nothing to do with the data
administration mission. They and the CIO would do well to remember, however, that well over half of all data warehousing projects exist only to make up for the sin of past inattention to data
standards and to enterprise data modeling principles. That is to say, the existing systems can’t exchange data and databases can’t be joined because their data is inconsistent and rife with
integrity problems. Let’s be blunt: many systems and data are low quality today because no one took care of data administration yesterday. I do not wish to imply that DAs are not in a great
position to do the analysis needed to build a data warehouse, because they are. However, building new data warehouses in no sense takes care of fundamental data administration responsibilities.
So ask yourself who implements good data standards in your organization. If your first answer is not “the designers and developers” but instead “DA” or “nobody”, something is amiss. Data
administration is not only what the DA does. When the staff with that title and other MIS people forget that, then the DA group is part of the problem.
(c)1998, richard j. orli
