If your house were on fire who would you call?
Would you call the architect first? Or would you call the fire department? Of course you would.
Yet when your application performance is so poor as to be unusable, who do you call first? The architect? No! You call the database administrator. We’re the ones to put out the fires and restore performance to normal.
Much like a fireman, a good DBA is able to put out those corporate fires quickly while the architects are still busy deciding things like what bottle of wine to have with lunch.
Many people agree that good database performance starts with good database design. If that is true then why don’t the data architects get blamed for bad performance? I’m guessing it’s because they aren’t on-call like a DBA, probably from dining at restaurants that don’t allow cell phones to be used.
That being said, if and when you want your house built you don’t contract with the fire department, you call a builder. But the fire department does have a say into the guidelines that must be followed for home construction. The fire codes are there to protect not only the homeowner but the firefighters that will respond to fight the fire.
Your shop should have similar guidelines from your DBA regarding production application code. You let your architects design and build the system, but they should do so while keeping in mind the guidelines that the DBA team has laid out.
So who get’s to decide the final design choices in your shop? The architect? The DBA? Or someone else?
I suppose it depends on who you ask.
Or you could decide for yourself after listening to a DBA and an architect discuss why they feel they should be the one to decide. Come listen to Karen Lopez (blog | @datachick) and me present “Database Design Throwdown: The Blunder Games” at ER World on Tuesday October 23rd. It will be the last tune-up we have before we lay it all on the line at the PASS Summit in November where the winner gets a meat gift basket and the loser has to walk home.
There are a lot of generalizations in this post, among them that the architect is not helping to do support, and another that the DBA is competent enough to be able to fix things when they die. Putting that aside, my biggest complaint is architects who have never done support work. Therefore, they never learn from their mistakes, they simply run around exclaiming that they found a new whiz-bang way to do something that all of the experts said couldn’t be done. For instance, architects who insist on using EAV data models because they are “flexible” but then never have to support this mess when performance is tanking and data is not constrained. Or those architects who say, “Ah, we’ll let the DBAs worry about performance, we like this new design.” Or those architects who believe stored procs are bad and ORMs ensure that the Java Jocks never have to write SQL again. Or, lately, those architects who insist on using NoSQL because they don’t want to spend any up-front time creating a good data model (then wondering later why basic aggregation queries cannot be performed on the data and data constraints are repeated in 20 different Java classes). Whenever I interview an architect I’m always looking to make sure they have actually supported what they have designed. And hopefully they have learned from some of their mistakes.
Tom, it looks like an Architect did you wrong. Or are you setting expectations for “The Blunder Games”? Either way, this is a good topic. I have worked with good and bad architectures and there is a coorolation with how closely Architects/Modelers work with DBAs that makes the difference.
David,
Yes, it is a good topic. And yes, it is a preview. And yes, I’ve worked with both good and bad architects as well as developers.