Prod DBA 2.0 says no**
September 17, 2010 5 Comments
Dominic Delmolino has made a welcome return to regular blogging and it’s good to see that I’m not the only one forgetting the basics.
In the body and comments of Dominic’s*** first few posts back, the subject of database development is very much in focus.
So, DD got me thinking and here is my stream of random ramblings – they jump about a bit, it must be a Friday.
Production DBAs have no place on most development teams!
When was the last time you saw a production DBA in a scrum standup? (Genuine question – do you do that?).
Today’s production DBA is a busy man whether he’s 0.x (seen a lot of these), 1.0 (met a handful), 2.0 (heard tale of a few) 🙂
Some might say they’re too busy coming up withinsane “policies” and standards.
At the very least, even if he has automated everything that he can automate(*), with the vast estate of DBs that a small, modern production DBA team *should* be able to support, the ebb and flow of urgent production issues means that he’s unsuited to the predictability of the resource availability that modern agile project development demands.
That vast estate of DBs that a small, modern DBA *should* be able to support also means that the knowledge that the production DBA of any one specific application or schema tends to be very limited.
However, for most enterprise-level data-centric applications (caveats and clarities due to previous sweeping statements), the data model is still so important and it’s just not being done right in so many places.
Here is a link post to a selection of other writings on the subject.
What Dominic D says strikes a chord with me. (But I’ve got a vested interest. The role he describes is essentially what I do or what I try to find.)
Most agile development teams (caveat again – most agile development teams developing enterprise-level data-centric applications) need access to a database development specialist.
Someone who knows SQL, knows PLSQL (in the case of Oracle), knows performance and knows the features and functionality of a database ideally to at least the same level expected of a production DBA (albeit with different peaks and troughs in specific areas) but without the irregular demands on their time from urgent priorities.
Most of them need this to be able to build data models that scale.
And to keep everyone on track with the data model and the big data picture – this can quickly get lost in translation especially with commodity developers (plug and play).
Most of them need this to write or at least QA SQL and PLSQL that will scale.
Most of them need this to strike a balance between new features and stability.
Most of them need this as a regular interface to the production DBAs as a communication conduit and filter, and to uphold the requisite standards and policies for development to move into production.
And absolutely this database specialist should take full responsibility for what goes into production – it’s all about control and responsibility.
Two other thoughts occur (and I’m not sure I’d finished on the previous thought but it’s gone now, flushed).
Firstly, and I commented this on DD’s blog, there is belief that all developers are equal and that you can plug and play any developer into any project without any consequence. I don’t believe at all in this approach. I’ve never seen it work effectively apart from in the presentation layer – i.e. coding input fields and buttons, etc – and even then I’m far from convinced.
What I am definitely convinced about is that this in no way works for any layer that requires significant business knowledge and goddamit does that include the database.
On the subject of the second of the two thoughts mentioned above, the phone rang before I could write it down and so that thought has now disappeared. If I remember, I’ll update this. Until then my mind’s gone blank….
Update:
Oh yes, the second thought. Development DBA is sometimes the starting point for a junior DBA – en route to the production DBA. This is a nonsense given the control, responsibility and knowledge required. As mentioned they need to know at least as much as the typical production DBA.
*I’m not a production DBA. Never have been. And although I’ve thought about it, not sure I want to be. Development’s where it’s at for me. But how DBA teams have much automated? And automated well? Everywhere I’ve been recently, the DBAs are firefighting constantly. Or they’re refreshing environments. Or they’re just completely overloaded with stuff that sounds like it should be automated. I mentioned this to someone else recently and they commented that it was because a large percentage of the production DBA team were contractors and has no vested interest in automating. I don’t know if that’s true. Any thoughts? There should be no greater compliment than going into a company and improving it to such an extent that the manual intervention you were providing was no longer required. But I can see the conflict.
**Prod DBA 2.0 says no -> Not sure how many, people outside the UK are familiar with Little Britain. Think it was way overhyped myself, followed by way overplayed. Personally (as comedy appeal always is), although there have been exceptions like the Armstrong and Miller fighter pilot sketch, there’s not much sketch comedy that has regularly and consitently tickled my fancy in the last decade since the Fast Show.
*** Confusing – am I referring to Dominic Delmolino or have I taken to the convention of referring to myself in the third person.Did you know that the latter is known as Illeism? I didn’t.
Stylistic device or a form of narcissism?
My CV is in the third person and I’ve never been even 83.2% happy with that approach.
But I’ve never liked it when I’ve rewritten it with a personal pronoun – “I” – neither with the modern trend of no pronoun whatsoever, e.g. “Worked on an oil rig. Implemented XYZ. Put out lots of fires.”
It stems from my time at a consultancy – that was their style.
Then again, I don’t agree with the narcissism interpretation (e.g. a bit like celebrities and some sports persons).
If anything, for me at least, it’s completely opposite – a form of anti-narcissism, a self-demotion which I think of as being particularly British.
It can be easier to say “X achieved this” than “I achieved this” and maybe there’s a comforting distance between this CV character “Dominic Brooks” and myself?
Don’t know if there’s an established phrase of “take the blame but share the glory” but maybe it’s something like that …
OraStory 
The age old question.
Would you rather be a Production DBA having to support poorly designed databases thrown over the wall with no idea how the application works, what it expects, how it is going to grow and what the end-users expectations are with you now being responsible for making it perform by flipping the ‘_make_run_fast’ parameter or being able to come up with some other silver bullet ….
or would do you want to be a Development DBA that can design databases that are stable, flexible, maintainable and can grow with the organization while at the same time having to work with development teams that are increasingly looking at databases as being black boxes that are in some way supposed to read their minds and configure themselves accordingly and business users that bring huge lists of requirements to the table that are usually to be done an arbitrary date that they have selected with no concern for the resources that it will take ( i.e. developers, servers, storage, etc) and what other projects are already in progress or have been promised.
My belief is that if you are going to have separate groups you need to have experienced people on both sides that work and communicate very well to insure that it is designed right up front and can be implemented in Production as a stable platform.
Small organization DBA’s have to be jack of all trades. Its getting harder and harder to find those kind of DBA’s especially those that have knowledge across multiple platforms with more experience than reading a book and attending some webcasts.
Tony,
Thanks for stopping by and leaving something behind.
No-one can disagree with experience.
I believe that with a small team of trusted, experienced people you can achieve pretty much anything.
With small organizations things are slightly different. Then again small can be IMHO so much better than big – I can’t stand the locked down, pigeon-holing that happens with big.
I agree with pretty much everything you say. I have been in both a production role and development role (and in a consultancy role as well) and can say that a prod DBA should not be in a development situation – not because they can’t but because of the responsibility demanded of production systems. Peaks and troughs in knowledge can be addressed easily so that’s not really an issue. Preference yes – I much prefer being in a consultancy role because it straddles the two for specific periods of time. And hell yeah developers are not created equal – give me a seasoned pro over a coop anytime (and yeah I know the catch-22 of that statement but come-on we know those that can will survive and flourish and those that can’t “well seeya!”).
This ties into your second point – a junior DBA should not start in development. From my point of view a development DBA should be a seasoned professional who should be inclined into putting development effort into making the software practical, efficient and sound. A junior wouldn’t know where to start with that – they may have a lot of theory but theory (in my experience at least) has mostly failed when making an application run smoothly. I don’t mean not being creative. I mean to make it work efficiently and fast – it takes a lot of creativity to make that happen.
Rui,
Thanks for commenting. Sounds like we’re pretty much in agreement – we must be right 🙂
Cheers,
Dominic
Damn right we are 😉