THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Preface from the Author: In an open letter to DBAs, I'm attempting to persuade and inform our data management counterparts on the value and importance of the "softer" side of the business. I came to the data management business from the applications development arena, and had only passing familiarity with the practical problems database gurus solve on a daily basis. Working side-by-side with them over the past eight years has given me an appreciation for their challenges and, I hope, I've given them some appreciation of the need for real design activity. The design challenge in general, an art that takes a lifetime to master, may be key to stabilizing our profession and industry. The following article tries to lay the groundwork for future collaborative efforts.

You can just hear it now: At the table down the hall, there's a group of people having, (as it seems to you) yet another academic discussion on the merits of third-normal form and the structure of primary keys. You've heard many discussions like this before - it all seems so pointless. After all, doesn't it just boil down to "create table" commands and a bunch of DDL? You mastered all that in your first DBA class. What could be so hard?

DBAs, Data Administrators, and The Great Divide

There's a great divide between the roles and functions of DBAs and data administrators. Try as they might to get along, a mutual mistrust often seems to fester in the relationship. As DBAs, your day is filled with performance tuning, query debugging, backup and recovery, and a host of other issues just to keep the shop in good working order. So it can be frustrating when data administrators come to you with "theory" and some notion of "elegance" when you know, deep in your heart, that elegant theories don't keep the doors open every day. What good are these over-educated miscreants anyway?

From the DBA's point of view, data modeling is the most visible output of data administrators. Every shop has its own standards and methods of operation, but data models arrive on your desk in forms ranging from (supposedly) working DDL to scribbles on the back of a napkin. The lack of industry standards for this handoff, both in form and quality, contribute to the deeply seated mistrust. Similarly, what guarantee does the DBA get that those scribbles and hieroglyphics have any bearing on what the application developers and business people really want to build? Even worse, some companies have organized their DBAs and data administrators with a sort of Great Wall of China between them, with little reason or opportunity for interaction, let alone collaboration. How in the world will these companies ever seal this breach if DBAs and data administrators, who truly are interdependent, rarely ever see one another?

While the data management industry is maturing, data administration is an infant subdiscipline in a relatively immature IT industry. Nonetheless, more and more very smart people are coming together to lay down education, certification, and practice standards to define who data admins really are and what they stand for. They recognize that there are fundamental problems in the practice of data administration as well as the perception of their group, and, at the end of the day, want all the same things DBAs want: smooth, efficient, and reliable data operations. Without a doubt, overcoming the practice and perception problems is no mean feat, but a number of dedicated people have staked their careers on it.

"All well and good," you say. "But, what does that mean to me? I've got a database with a corrupted block. What good will a standardized data administration practice mean to me?"

The World According to the Data Administrator

Data modeling is an exercise in problem solving. Models, in general, do one of three things: describe, diagnose, or prescribe. When a data administrator creates a data model, he's trying to describe the data universe of that problem, diagnose the business issues presented by that universe, and prescribe a solution or remedy that application developers and DBAs can use to satisfy some business need. A common tool for data modeling is the entity-relationship diagram. This diagram has precise mathematical rules for construction, and, when well constructed, provides a straightforward path toward implementation. Good data administrators are sensitive to the needs of the business and application developers as well as DBAs, and orchestrate a work product that traces back to the requirements of all.

Data modeling endeavors can be highly complex exercises and can break down at many points. The two most common points of failure are simple and timeless: lack of communication and the misunderstandings and myths of data management science - by all parties involved.

We could debate for days on how this sorry state of affairs has come about, but I'll leave that to the historians. To be sure, many good working hypotheses have sprung from this debate, but too often, misunderstanding and mistrust only fuel the support of myth. All parties - DBAs, data administrators, application developers, and business people - need a new model going forward. This new model would prescribe the roles, responsibilities, boundaries, and limits of authority for what is a highly interdependent working relationship among specialists truly engaged in scientific and engineering practice.

I would propose some of the following as prerequisites to establishing this new model:

• Cross-Training. The different languages of our different tribes present pitfalls. Likewise, everybody on the team needs to know, at least at the basic level, what others are trying to accomplish and roughly how they do it. No one of us has a monopoly on the truth. Each of us could enhance our skills by understanding more about how their own work products are used by others..
• Heal Thyself. I can speak from personal experience that the most important things I know I learned by making mistakes - lots of them. Gaining depth and breadth in your own field comes with practice, experience, and a commitment to life-long education and training. These are also a ticket to securing yourself to a stable profession and career.
• Remember the Greater Good. No one is coming to the table to be purposely contentious. We all just want our unique points of view to be fully represented in the total work product. The greater enterprise goal, be it for profit or a public service mission, needs to be revisited regularly. Reminding ourselves about just why, ultimately, we are doing what we are doing should go a long way toward helping us put personal differences aside.
• Just Listen. Nobody gets smarter by talking about what they know. You may have a personal mission, but if that mission takes on the characteristics of a crusade, take a time out and check into what might be going on. Your teammates are probably pretty smart, too. If you can resist the urge to steer them once in a while, you'll be able to see where they take you. (I'll bet they amaze you now and then.)

If this all seems too "soft" or "touchy feely," you may have a point. Better interpersonal and interdisciplinary behaviors don't, by themselves, fix that trouble ticket you're working on. But wouldn't it be better if you get fewer and less severe trouble tickets? That's my final point. Making operational problems less frequent can only sustainably be achieved by improving the R&D effort. And, while technology may march on, chances are, ten years from now, we'll all still be working with the same old model of humans. So, data management science and engineering is ultimately a human endeavor, one where the diversity of thought and opinion must be acknowledged, accepted, and embraced.

This article was previously published in DBAzine.com's on-line community for database issues and solutions in September 2005. Jim is a long-time friend & colleague of mine who has the "survived" and always bettered his organization for many years. Thank you to DBAzine.com for permission to republish Jim's work.