-
Interesting debate we have going here. Okay, let's take a different spin on a couple of the last posts. Again, you must consider that there are responsibilities that get grouped into roles that get assigned to positions. Once you start simplifying the job of administering the database, that *position* begins to weaken, IMHO. Again, I point to SQLServer, and remember that SQLServer runs many very large and important sites - it's not just for breakfast anymore :). The idea is that as you simplify the job of administering the database, you need fewer administrators. Yes, administrators know many other things and do many other things, but think about it. The future of databases belongs to the designers and programmers. Even the design is a limited function. Most places cannot justify a full-time designer. However, the development process is usually lengthy. So the database programmer *position* becomes the consolidation of:
- Designing and implementing the model
- Coding and optimizing the SQL
- Troubleshooting production issues.
There will always be production support and, hence, an administrator of a fashion. This person may be a Net/Server/OS/DBMS admin with basically the role of watching a lot of little lights. When a red light pops on for the database, the developer is called to fix the problem (assuming its complex enough).
This was definitely the path that was being taken in many of my previous clients using SQLServer. I would design the database, spec, buy and install the server, implement the database, write and tune all the code, and deliver it into production, complete with a customized set of alerts and tasks (including automated backups), and finally supporting it until production services could take it over. Again, these were not *huge* shops, but were of respectable size.
The point is that the smaller shops do not currently need DBAs. As that function simplifies, more medium and probably some larger shops will start dropping DBAs. This doesn't necessarily mean that DBAs will be out of work, as our industry continues to grow. They will simply represent a smaller percentage of the whole. Even those companies that don't eliminate the position completely will cut back. More and more power will go to the programmers. Of course, this will mean a change of structure, as you still want centralized standards and control, most likely. So picture senior database programmers that float between projects giving oversight and guidance as projects are developed.
I'm getting ahead of myself, but just like the IT towers of yesteryear fell, so will the DBA towers of today. More control will be dispersed to the individual projects and the sun will set on the current reign of the DBA. (Eloquent, no? ;))
Even Oracle has seen the light. One of the biggest compaints in the industry about Oracle is its complexity to administer. This means costly DBAs or poor performance - not much of a choice. Oracle could get away with this previoiusly. It was to their advantage to keep things interesting for their programming army (us). However, SQLServer is now seriously nipping at their heels. And people see how easy SQLServer is to administer. They realize that they don't need a fleet of DBAs to run their shop and they like the idea. Oracle has realized that it can't continue the way it has. It *has* to simplify the database. Hence, the idea of auto-tuning and the like. So, as always, keep your eyes and ears open to what the industry is saying and always stay ahead of that technology wave.
Thoughts and comments welcome,
- Chris
(But that's just my opinion. I could be wrong)
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|