I have to be honest and tell you that you'll have a hard time finding a good independent DBA or group of DBA-type consultants. First, you must make sure of their technical skills. Many high-level consultants out there haven't written a single SQL phrase for years. Yet for a breathtaking amount of money they'll quickly suggest a DBMS for you. It's easy. Their jobs aren't on the line.

And check their experience and alliances. A DBA can make any DBMS sound good. Most DBAs have a favorite DBMS—one they were trained on, or one they would like to get experience on, so they can pump up their resume on your nickel. You can at least balance their prejudices by contracting several DBAs with different backgrounds for the evaluation. Only pin the evaluation down as well. It shouldn't take more than two months; perhaps less, if they know their stuff.

Start the process by having one of them carefully draw up a complete list of requirements, with all the applications and future extensions in mind, then generate a short list of DBMSs that meet these requirements.

Compelling Project Statistics
Match the DBA to the task...

During the ensuing analysis period, drag a DBA—an independent one or your own employee—along with you to attend several user group meetings. That will help you get the most from even highly technical presentations. And in the social gatherings afterwards, have your DBA (and yourself for that matter) mingle with the real users and other DBAs, as far as possible from the vendor reps. Just watch out for the headhunters who lurk at such gatherings.

Once you've selected the DBMS, you'll require a development DBA to help you design, build and deploy your database application systems. Development DBAs design new data models, change existing data models, create tables, implement integrity constraints, write stored procedures and triggers, and design and implement indexes (the latter often in collaboration with production DBAs).

	DBAs come in a range of flavors. Click here.

Development DBAs liaise with production DBAs about the production database, and the database objects they want created in it. They also liaise with the application developers about the tables, views, stored procedures and other database objects needed for the apps. Like their production counterparts, development DBAs need to know a lot about the DBMS product you've chosen. They need to know what objects can be created, how to do it, and which objects can and should be used in combination.

These DBAs also need database design skills, including knowledge of CASE tools and normalization, and usually data warehousing skills as well. They should know how to design and implement data marts, design star schemas, and map the operational data structures to the decision support structures used in the data mart. In this context, some experience with a data warehouse loading tool will also be an advantage.

Do You Need Development and Production DBAs?
Once you're in production, you need a production DBA to help ensure that your users will trust you with their crucial data. I cannot stress enough how important this is. A production DBA is, in essence, a watchdog. This DBA monitors your production database, to check, among other things, whether performance is stable and acceptable. He'll make sure that the locking strategy doesn't cause too much contention, that security constraints aren't violated, that disk space is utilized as expected, and that necessary backup tasks are performed as specified.

The DBA's biggest value comes when things go wrong. And believe me, they will. Disks do fill up, and then they pack up—always at the worst possible times, in keeping with Murphy's Law. Also, all DBMSs have bugs. The DBMS may crash unexpectedly one day, or just hang up and go on strike.

Production DBAs are responsible for rectifying such situations: to fix the disk space problem, get the DBMS server up and running again, restore the database, catch up the journalled transactions, and so forth. So your production DBA needs excellent "firefighting" technical skills and in-depth knowledge of the DBMS and your databases, as well as dedication, loyalty, meticulousness, and thoroughness.

There's one more position to consider. You need data administrators if you handle a large variety of user data, with complex interrelationships.

Data administrators are responsible for the data content—typically on a nontechnical level. They know the business, the subject, and they know what data is required by the different groups of users. They determine who should own and be responsible for which data. They can discuss the department's informational requirements with users, in terms that users can understand. They know how to design data models, but usually rely on the development and production DBAs to implement the data models in the database.

Selectively Integrate
In a small department you may need to integrate these three functions. I suggest integrating the data administration and the development DBA functions. In a small department a single person could easily perform this combined function. However, I recommend keeping the production DBA function separate, preferably staffed by at least two people.

Production DBA work can be stressful. It requires dedication and quick response times. Some DBMS products require a lot of DBA handholding and watchdogging in production.

You'll find that development work is often slowed down if it's performed by production DBAs, due to the attention and priority they must give to the production database. Or the production DBA tasks may be skimped if they have to be performed by a development DBA who'd rather focus on development work. You usually need different personality types for production and development DBA work.

The workload, skills, and dedication of the DBAs you employ will determine how many bodies you need to fulfill this function. But however you distribute the work, you should look after your DBAs. They're a valuable human resource, and you'll discover a world of hurt if they all up and leave at the same time.

You may expect your database adminstrators to work overtime, but be sure to remunerate them for their effort. Most DBAs, I've found, prefer cash in the pocket to public honors and approbation. And make sure you have enough production DBAs to rotate their after-hours duties. They also have sports, hobbies, social lives and families, even if they spend 12 hours a day at the console.

Make sure you keep your DBAs' skill levels up to date. Give them interesting tasks to do as well. Most of them want to extend their skills in particular areas. And most firefighting DBAs want to move on to less stressful jobs after a number of years.

Send them on training courses, to user group meetings (again, watch out for headhunters), and to technical conferences. Invest in them, keep them happy and stimulated, and groom them for other posts in your group. They're valuable assets who know your data, applications, and organization very well.

Stay Out of Your DBA's Face
To what extent must you become involved in the work performed by the DBA function? The head production DBA of a substantial departmental database for one of our clients often said he wished his manager would leave him alone to perform the tasks he knew best to do.

He found it stressful to have to explain to his nontechnical manager (who was always looking over his shoulder) exactly what he was doing while he was trying to fix an inconsistent production database and make sure the indexing and disk space allocations were correct for the recovery run.

He'd complain that "it takes me three times as long to get each task done if I have to explain each step to him in layman's terms and disprove all his useless suggestions. Meanwhile, the users are jumping up and down."

This particular production DBA was excellent—a dedicated firefighter, like no other. He knew his job, knew what he had to do, knew his DBMS inside out, and worked many late nights when users wouldn't be disturbed. He moved on to another organization.

This true story should answer the question. Enable your DBAs, especially the production DBAs, with the skills and resources they require. Make sure they know what's required, and that they regularly provide for all possible eventualities that may arise.

Regularly examine their checklists and discuss work in progress as often as you need to, but stay the hell out of the ops room when your DBAs are fighting fires and have the users shouting on different telephone lines.

Sure, bring them pizza and strong coffee when the going gets rough. But let them fight the battle. You all can analyze it in a debriefing session afterwards. Then give them praise if it is due, or jump on them if need be, or, better yet, help them get more organized or better equipped if it proves necessary.

Development DBA work is a different kettle of fish. Development DBAs must work closely with the application developers—preferably directly with the development teams, and under the same project management. The data administrators need to liaise with the end users, often require their manager's buy-in with this process, and sometimes even require your negotiation with the project sponsor and user representatives to establish smooth and open communication channels.

By all means, manage your data administrators and development DBAs like the other development team members. But don't hide them deep in the bottom of the project's reporting structure. Make them a highly visible service group, placed so as to report directly to project management, from where they can provide a service to all the development team members.

Align Your Allies
When you run with your own divisional database, the glass house IT section may withdraw all support, especially if you should decide to use a DBMS other than the one prescribed by the corporate standards document.

But from your side, don't burn your bridges. Try to keep your relationship with the glass house professional and stay in close contact with them. Chances are that you'll want to share and exchange data with them not too far down the line, or possibly even borrow a few of their resources.

You'll be viewed as the breakaway group, and the corporate IT section's DBAs may be instructed not to assist your DBAs (though after hours you might still find them shooting hoops or discussing their work over a beer). So make sure you align your allies so you can run on your own.

Establish a good relationship with your DBMS vendor and make sure you can rely on its support. Stay in touch with other users of the same DBMS.