Thanks a lot to everyone who makes a comment here, your comments are great!
I'd like to shed some lights on why I coined this DBAA term here. My personal background is a DBA with a MBA degree (Wayne, we have some same thoughts reading your email)
My ex-employer is a company that needs to be heavily audited due to its organization nature (non-profit). However, to meet these rigious auditing requirments, we spent tons of time in doing anything that can satisfy those auditors. This practice leads me to continuously think of one thing, how can we meet the auditing requirments without compromisng our database administration quality if we have to put so much time to auditing? How come there is no technical auditing regarding database administration quality such as db admin process, db admin efficiency, db admin cost, etc, etc? But these topices are no doubt beyond my daily responsiblity as a dba, who simply takes care of the health of my db environment plus doing all those mandatory checklist work required by the auditors. Finally, this leads me to believe these "big" topics should be the call of somebody who has expert knowledge of db administration while on the other hand, need to spend time in thinking these strategic questions. Database administration is a young career field compared with software development. We see lots of software engineering books, but I never see a book dedicated to database administration, but I believe with time going as db administration becomes more mature and plays more important role in our real life, we will see this type of books coming out in near future.
I noticed MS has a new certification for data architect, but this is different from my proposed DBAA role (no doubt there is some overlap). To me a data architect is more of data model build, data layer design and data process. But DBAA thinks more of administration in terms of efficiency, ROI and the framework of achieving the administration goal. In some sense, it has lots of common aspects as business administration but in more technical way and in much smaller scope.
Anyway, if my article can trigger some useful disscussions and lead to some fruitful thoughts to our DBA community, I'd say I have achieved my original intention already
Thanks again for all our great comments which also help me to think from other perspectives.
< SQL Sever developer can move into a database architect position easier than a DBA.>
It is not true
These titles (SQL Server Developer, DBA) are so generic that a blanket statement like that doesn't really help. Just start looking for a job and see what activities and responsibilities show up under a help wanted add for a DBA.
In some companies, SQL Server Developers are just developers who can query a database. In some companies, DBAs just make sure that the backups ran last night, etc.
Sometimes, SQL Server Developer is a title for someone who knows SQL Server inside and out and optimizes, tunes, etc. In some companies, DBAs do both t-sql development and administration, and much more.
My title is DBA, but I do some coding, some database administration (server jobs, manage security, add users, etc.), and a lot of performance tuning and research.
Like I said above, the titles and responsibilities just vary too much from company to company to use a blanket title to define what a person is capable of.
Thanks Chris. In my company, I am the developer, DBA (manage both development and production jobs, security, create database, create user sign on even apply patches.), also I do database modeling, index tuning....
The fun goes on and on ...