Jul 12

Written by: Karen Lopez
Wednesday, July 12, 2006 3:39 PM

Over the years, I've worn many hats, from project manager to 3-hole paper puncher - seriously.  And I've had a variety of titles, including Senior Systems Analyst, Senior Consultant, List Mistress, Chief Methodologist, Data Architect, Data Modeler...the list goes on and on.

When I present or write, I tend to use very flexible terms for talking about roles.  I don't make a significant distinction when I write Data Modeler, Data Architect, or Data Administrator.  The latter term has fallen out of fashion in most shops, but it is still used.   This flexibility often gets me in to terminology trouble when I speak, though, as many organizations have formal distinctions tied to responsibilities and compensation based on the specific title used.   And some professionals are insulted when I refer to their role as a Data Modeler, when no slight was intended.

The same thing happens when I speak about DBAs.  In some shops, a DBA is someone who runs pre-scripted jobs and changes passwords. In other it is the only person allowed to access the database via means other than an application.  I recently posted something about this title issue on another list:

Terminology gets us all the time. The role of a DBA can vary, something along the lines of:

• operational DBA:  keeps databases up and running. Has few planning, design, or development assignments. Sets up accounts and checks the status of jobs. Usually first line on-call person. Probably what you are referring to as "administrator".
• planning DBA:  plans for database activities to keep them up and running. Things like capacity planning, security, backup strategies, compliance issues, replication strategy etc. Most likely the one who sets database architecture standards and processes. May also supervise other DBAs. May be second or third tier on-call support person.
• developer DBA:  designs databases, often on a project by project basis, builds triggers and stored procs, etc. Might even be responsible for writing applications. Might even be responsible for logical designs.  Typically optimizes designs for ease of development. Usually on call for database and application issues.
• Jack of all trades DBA: "I'm the only person in the shop that knows how to spell SQL, so I'm the only DBA" and I'm a part time developer, too. On call all the time for all data stuff. And some application, too.

Larger shops tend to have these roles separated across multiple positions (people). Smaller ones tend to lump them all together.

Lately I've been working in shops that have 1-5 DBAs, so pretty much they are Jacks (and Jills) of all trades DBAs. Sometimes there is a junior DBA who performs mostly operational DBA jobs. SOX compliance issues are taking their toll on these all trades DBAs, as many organizations are interpreting SOX as requiring a great deal of separation between development and operational roles.

All these are generalizations, I'd admit. I once worked with an end-user who was first line DBA support. And he was really good at it, probably because he had more to lose than a typical DBA if the data were fubarred.

I'd be interested in reading about your use of data management related titles, what they mean to you, and what pecking order are embedded in them.

 

Copyright ©2006 Karen Lopez

Tags: