THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

James Luetkehoelter

Nearly any SQL topic presented at times in a slightly eclectic manner.

Agile Development and the "DBA"

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.

Published Thursday, July 5, 2007 1:40 PM by James Luetkehoelter



Adam Machanic said:

Just a quick comment to say that I'm glad to see your post on the topic... I will read it in depth shortly :)

July 5, 2007 3:11 PM

MattK said:

"Pay the DBA now, or pay them later." No way around it.

Unless the devs are at least as experienced in data modeling, SQL development, and system architectures as they are in the primary language the app is written in, they will design things that will cause bottlenecks at some point down the road. Simply working in a set-based language (vs procedural or object oriented), can cause confusion leading to evil "for-next" constructs   in the database (excessive use of cursors, temp tables, and nested subqueries instead of simple joins).

After nearly 15 years in software, I have yet to see a project that used a shared database, that did not have a DB"A", and did not sorely need one.

July 5, 2007 3:31 PM

Chris Hedgate said:

James, good thoughts here (and nice to see you have a blog, you could have told me ;)

As you know (since you where there), this is basically what I say in my Agile Data Practices (or Working with SQL Server in an agile development environment, as it was called when you where there) presentation. The number one factor for succeding with ANY data-centric project (which ones are not?) is having data professionals (I neither like the term DBA) working closely together with the developers. Just as an agile team will have testers, business analysts and even customers working together on a daily basis, so should there be data professionals included in that team. A developer and a data professional pairing on data centric tasks (database object creation, O/R mapping etc) are the best way to success.

July 6, 2007 12:45 PM

Chris Hedgate said:

Uhm, sorry dude, just realized you had a blog for a long time. I even used to have it in my reader before I did a big cleanup and started with a clean slate. Anyway, like the content here so far. :)

July 6, 2007 1:06 PM

James Luetkehoelter said:

Thanks for the comments all, and yes Chris, I am echoing essentially what you said in Denmark :)

The question that keeps tripping me up is: If this is so obvious to us, why is it so difficult to convince others of the same thing? I work primarily as a consultant and I fight this battle on a daily basis. Is it just people clinging to a waterfall development model, or obsessed with preventing overlapping job descriptions (in IT/IS, shouldn't there just be continual overlap from one end to another?)

July 6, 2007 1:49 PM

Jamie Thomson said:


I have one thing to say. THANK YOU!!!!

I have recurring battles with my superiors on my current (agile) project who think that it is satisafactory for the DBA not to be involved on a daily basis. They seem to think that the DBA doesn't have a part to play in development and I get the impression they would even be happy to outsource the DBA function to people that don't even know the purpose of the databases that they are adminstering.

So, for pointing out what to me seems glaringly obvious, thank you. I almost feel vindicated.


July 9, 2007 1:05 PM

Andy Leonard said:

This re-post from my Applied Team System blog (which was a repost from my old SQL Server Central blog)

July 10, 2007 9:33 PM

jim.wightman said:

I think this is an interesting direction to take SQL Server Development - and no reason why not of course!

My forthcoming SQL Server book has a chapter on Test Driven, Agile development - I'm happy to share if anyone is interested....?

This isn't just an advertising comment by the way ;-)

July 13, 2007 4:03 AM
New Comments to this post are disabled

About James Luetkehoelter

I am passionate about what I do - which is DBA, development, IT and IT business consulting. If you don't know me, haven't met me or have never heard me speak, I'm a little on the eccentric side. One attendee recently described me as being "over the top". Yup, that about says it - because I only speak on topics that I'm passionate about.
Privacy Statement