It seems that I'm finding myself gravitating towards two non-technical discussions related to the world of the DBA these days. The first is the nature of the changing world of the DBA. The second has to do with support, using support efficiently and getting what you want from support.
In this Blog post I think I'll address some of my thoughts on the changing world of the DBA. I've talked about this at several presentations and have gotten good feedback on some of my comments. In fact I'm thinking of putting together a presentation on this topic as a whole.
The bottom line is that our world (as a DBA) is changing. It used to be that we were all kept busy with the day-to-day drudgery of managing our databases. We were busy trying to keep the thing up and and running, responding reactivity to user requests and imminent fires and really didn't have time for much of anything else, or perhaps we didn't make time for anything else. I think many of us liked working in reactive mode, liked being the hero in spite of the 2am calls. We liked being the DBA, who was talked about in hushed reverent silence in the halls because of our awesome skills and how we saved the day. This kind of thing appeals to our ego, and is a very positive reinforcement behavioral loop. We were DBA's, Database Administrators.
I'd like to propose a new definition of the acronym DBA. I'd like to change it to one of the following:
Database Articulater (which I don't think is a word, but I'm not above making words up if they serve my purpose).
The point is that DBA's (administrators) can no longer afford to do our jobs in a "Business as usual" type of mentality. If so you will find yourself becoming a dying breed. We can no longer spend our time huddled in our cubes (or at home!) looking at tablespace available space, looking for disk space, helping users tune SQL statements, creating accounts, unlocking accounts, and so on. All of these things are time consuming tasks that are easy to automate.
Why are we spending our time tuning SQL statements? Why are we spending out time fighting COTS applications that don't work well? I propose that the reasons we are doing these things is because we are not doing the job we should be doing, and that we have not communicated effectively to management and the business what our jobs really should be and what we should be doing to really provide the best value to the enterprise.
I'll have some more thoughts about this in my next post...