Database Professionals: An Enterprise Requirement

andyleonard — Fri, 13 Jul 2007 01:53:00 GMT

A friend (who shall remain nameless) recently told me his company interviewed a competent database developer and DBA. All seemed in agreement an offer would be forthcoming until the very end of the recruiting process. At that time, someone made the comment "we don't need a DBA."

It would be notable if this sentiment wasn't so widespread - but I see it often. How often? Well, I would have to tell you how I see it to qualify that statement:

You see, people rarely say to me "We don't need a DBA." Mostly I see it in their applications - many of them prominent companies in which you may even own stock. I can tell when I examine their schema. I can see it when I execute Profiler against their SQL Server database.

Now, there are lots of reasons to design a denormalized schema. And there are lots of reasons to encapsulate the business rules in code. This is not what I'm talking about - though some of these systems would clearly perform better (or at all, in extreme cases) if they took advantage of better design patterns.

I'm talking about designs where this much is obvious:

1. At least two people designed the data layer; and
2. They did not communicate during the process.

Often, enterprise-level database design is shoveled onto developers as a secondary task. No, I'm not making this up - it's too tragic to joke about. There are developers who can handle this task. But there are more who believe they are database developers than actually are. (Before I became a SQL Server DBA I was a developer who thought I was a SQL Server DBA...)

There will doubtless be readers who can provide examples of how their enterprise application was built by junior developers who did the database and code work and whose systems are performing just fine. I'm happy for you and sincerely hope the system scales.

Designing a scalable solution - database, application, or enterprise architecture - is one of those things that consumes time, thinking, resources, and money during the early phases of an enterprise development cycle. But it is - hands down - one of the best investments (if not the best) in the solution.

In today's market, scalability is as optional as security. And like security, a scalable design is not something you "add later." It's not part of the foundation - it is the foundation.

My experiences with designing scalable solutions has proven there is no free lunch nor any shortcuts that work. If anyone - me included - skips the work of designing for scalability, there comes a day when they (or I) must pay the fiddler. From what I hear and have experienced, designing in this fashion is most often sacrificed on the altar of the deadline. Trust me, if it falls apart in six weeks or six months, you haven't saved any time - and you may have lost a job or a customer.

Someone told me this and I remember because it has proven true several times over: "Deliver quality late, no one remembers. Deliver junk on time, no one forgets."

If you're building (or upgrading to) cutting edge technology, you need a DBA.

:{> Andy

Technorati Tags: Software Business scalable database design quality

Search results matching tags 'Database Design' and 'Software Business'

Database Professionals: An Enterprise Requirement