I find this article and the ensuing discussion highly entertaining.

As a contract/consultant, I have quite often been thrust into the midst of small to mid-sized companies that seem to be nearly entirely bereft of DBA experience, or were brand new implementations in a formerly paper-driven company with some sort of a contact application. Most of my paying work has been paid from the need or want of the development side. I first cut my teeth on RDBMS design before I ever learned how to code any of the modern languages. Personally, I feel that every developer should learn this most common and fundamental data model before ever writing a line of code.

It is mighty difficult to get an organization of any size to see light of value in a real DBA if they do not already have a sponsor for one. I have won the battle in a few places, but almost always as the sacraficial one. Basically I have had to leave or be going before the change would take affect. I have tried the soft TLC route, the golden sledgehammer route, and the "just live with it" route... but I cannot just live with it. Change is almost always painful, and sometimes, a position would come with too much pain and effort, to continue it. I don't fear leaving, and I don't fear staying... what I do evaluate is the "is it worth it to me to try". The phrase, "Tripping over dollars to pick up a dime" is something that I have seen far too applicable to organizations in many industries.

What I would like to see is the compilation of success stories/senarios where "conversion" was made. I do agree with Jeff Moden where he noted that white papers and other peoples stories are not good tools for convincing others. I have experienced this in fact several times... the white papers and such have the MOST effect AFTER the hard test proof is sitting in front of the right nose(s). It is very hard sometimes to not call a current situation bad names (like trying to explain why 2GB RAM on a WIN 2003 Server with SQL 2005 DB on core operations for a company is categorically inadequate, not to mention that reporting is running from the same box).

Solutions may be specific to specific companies, but the mental mindset on the need of a real DBA in such companies is quite common, I think, and I think many would benefit from such a discussion. Things like having a Sponsor, a Champion, and a Technician (the DBA). A DBA cannot easily stand alone... s/he'd have to be perfect, awesomely right in every circumstance, and have a very hard shell, without being viewed as a bulldozer!

It seems that in today's world, a great DBA needs to have experience in Humanities and Psychology too. I dare say most DBA's never dreamed they would have to learn to work the corporate psychology in order to be successful and effective. Most that I know are better known in the back rooms, not mingling in the corporate mindset.