Adam poked me with a stick to discuss this further (that was 5 stiches plus a tetanus shot, thanks Adam), since I alluded to it in my first post on the site. I had a conversation with a developer friend of mine that believed 100% Agile development. It was a very interesting discussion because the phrase "What good is a DBA anyway?" Needless to say I almost fell over after hearing that. I did my best to convince him of a DBA's necessity, but he was never convinced.
In the title of this little diatribe I put the acronym DBA in quotes. Here's the problem: Exactly what is a DBA, and what do they do?. It has long been a fluctuating job functioning, sometimes grouped under infrastructure, sometimes under development. Then there were the concepts of having a hybrid DBA, or a "DBA+": plus DTS, plus .NET, plus AD, plus networking, etc.
The first thing I need to make clear before I discuss how a DBA fits into Agile (or any flavor there of), is what I mean when I say "DBA". Everyone has their own take on this, but since I have the keyboard at the moment, here's mine. A DBA (for any RDBMS) is responsible for the following:
- Ensuring Data Security
- Ensuring Data Integrity
- Ensuring Scalability
- Providing Disaster Recovery
- Providing High Availaibility if needed
- Provide programmatic assistance to optimize any code for a given RDBMS
- "Own" the knowledge of the structure of the data and the content of the data
It's this last bit that usually gets me in trouble, but I firmly believe it. Who else is going to do it? Just glancing at this though, it is clear that a DBA must cross many boundaries to uphold these responsibilities - they must know a little AD, networking, development, even the business usage of the data.
With this as a model of a DBA, I think it can fit nicely with Agile. I never mention change control, or any processes that would effectively roadblock a rapid iterative process (yes, there's much more to Agile than that, but that's all I'm gonna say - if you don't like it, tough :) ).
When it comes to development, a DBA has very specialized knowledge that simply *must* be included in development, even though a large portion of that knowledge is not directly related to development itself. The way I see it, the DBA is the intersect point between development, the business and IT (infrastructure). I say that not with arrogance but rather with fear and loathing - that's a tough spot to be in.
Here's how I see things working:
- The developer and the DBA meet with business owners to determine requirements
- The developer begins while the DBA communicates logistical requirements to IT
- First iteration comes out with whatever SQL code is there; DBA makes changes to optimize for performance and security - the developer leaves the SQL code at this point to focus on other areas
- The business owners request a change - the change is made by the developer, the DBA repeats SQL code optimization. In working side-by-side the developer and the DBA ultimately leverage each other for optimizing on the object-oriented side and the relational side.
- IT is included as physical requirements change, as determined by the DBA (and ultimately the DBAveloper....
- Ad infinitum
Heck, I even use Test-Driven Development when I write stored procedures. The problem is if you leave the DBA out of the picture (well, my picture at the moment). You loose the link to IT (creating a potential halting point), as well as ownership of the business meaning of the data (or a developer has to retain all of it). Interaction with the RDBMS may be less than optimal, perhaps going so far as to point the design onto a dead-end street.
The DBA does less actual coding, but plays more of a "glue" role during the process. Not from a project manager perspective but real action items that have a cascading effect (which is why I love the WITH SCHEMABINDING option for stored procedures, functions and views - that's tomorrow's post).
Yes, this a superficial representation of everything. All I'm offering is food for thought. Please point out where you think I'm wrong, right, or just plain crazy.