There is no such species as a DBA. Well, the term disguises such a wide range of job-roles and skills that I often wonder if it is a helpful term at all. There is such a broad range amongst those who work with databases that it is becoming absurd to try to speak of DBAs as though they were a homogeneous group, with the same skills, opinions, stresses and predicaments at work.
I'm an unreconstructed developer. In a corporate setting, I'd be working with strategists, Analysts, data architects, technical architects, production DBAs, Development DBAs, web designers, Technical Authors, and a whole lot of other technical specialists who are working in the same general space. Sometimes, when developing an application by myself, I have to pick up all sorts of skills to get by: but that doesn't really turn me into a DBA, or client-application developer.
It is useful to remember that we are all different, with different roles and with varying education, training, cultural backgrounds, and skills. It is this wide diversity in the community of people who are working with databases that make such work so rewarding. It enriches discussion and brings a huge range of skills and knowledge to bear. It has downsides. It seems increasingly difficult to recruit Database-savvy people without having to wade through the CVs of people whose training and skills are entirely inappropriate for the job description. Recruitment agencies just see the initials DBA and all reason leaks out of their skulls. Another problem is that Microsoft often forgets our diversity. Their eagerness to persuade us all to use PowerShell is a wonderful example of this. Whereas I will fall on PowerShell, or any new toy, with clucks of joy and playfully construct recursive-descent language parsers with it, I know of many DBAs whose knowledge of Klingon far exceeds any level of skill they are likely to reach with the damned thing. Microsoft, and any other software provider, needs to be continually reminded that no single software solution fits all. There will always need to be solutions to suit the point-and-click brigade, the raw-code propeller-heads, the swivel-eyed tinkerers, the Object-Oriented Zealots (OOZers, we call 'em ), the Box & Arrows wallahs, and a wide range of other types.
If we really have outgrown the term DBA, what are the various categorisations we should be using? Even if we decide to be consistent and refer to database developers, production database administrators, data architects and so forth, how can we persuade the more general public, and company management at large of the change? What is the current reality of the different database-related jobs being demanded by IT departments?
