Data Administration: Part of the Problem?

Rick Orli, Technical Director, Kismet Analytic Corp.

Data administration is a vital job at the heart of the business of making good systems - data strategy, architecture, infrastructure support, data standards, and especially education of the above. It's an "overhead" job that is 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 DA strays from its core job, then it is part of the problem because the job won't get done.

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.

What is the problem? It 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.

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 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.

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 (only) publishing a soon-to-be-dusty-shelfware manual. It does not mean (only) a standards enforcement review the same week a system is to be delivered. I do not dispute that these and other exercises that are specific worktasks have their value. However, 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 good design principals such as integration within the enterprise, and serving the enterprise "view". It is a multi-faceted educational, mentoring, and standards enforcement role.

Perhaps 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 full of integrity problems. Let's be blunt: many systems and data are low quality today because no one took care of data administration yesterday. Building new data warehouses in no sense takes care of fundamental data administration responsibilities.

Data administration is not only what the DA does. When the staff with that title and development and other MIS people forget that, then the DA group is part of the problem.

© 1997 Richard J. Orli

HOME

Click to request more information!