Wednesday, November 08, 2006

What does a Database Architect do?

Even though I was the very first developer on the Microsoft SQL Server Team, I have to admit that databases don't thrill me .... You have to have a special mindset to deal with databases all day, and to tell you the truth, my interests lie elsewhere. In fact, the sure way to get me to fail an interview is to ask me to write any moderately-complicated SQL query.

I firmly believe that, for major systems, the developers should not be allowed to design the data model, set up the databases, nor write the DDL. I have seen a number of instances in the past where systems that have had their database components designed by non-database experts have performed very poorly. Slow queries, no indexes, lock contention, etc. The best projects that I have been involved in have had a separate person just devoted to the database. If I am leading a major project, I will always have a dedicated db expert as part of the effort.

Let's say that we want to hire a database expert for our Architecture Team. What duties would they have?

1) Advise teams on best practices.
2) Come up with DDL coding standards.
3) Review existing systems and provide guidance on performance improvements.
4) Know the competitve landscape (Sybase vs SQL Server vs Oracle) and affect corporate standards.
5) Be expert at OLAP, MDX, Analysis Services, etc.
6) Know how to tune databases and hardware in order to provide optimal performance.
7) Advise all of the DBAs.
8) Monitor upcoming technologies, like Complex Event Processing, time-series databases, etc. Be familiar with KDB+, StreamBase, Vhayu, etc.

A Database Architect is a full-time job that I think that all Architecture groups should have a slot for.

Know anyone who wants to join us?


©2006 Marc Adler - All Rights Reserved

5 comments:

Anonymous said...

Don't forget the ability to institute a change control process and manage changes to the datamodel. Efficiency here can make of break the timeline.

Robert Maldon said...

The DB architect should also be familiar with some of the O/R mapping technologies (e.g. Hibernate, iBatis, LINQ) that will be used to access the DBs, including strengths and weaknesses. Many applications start from an OO model, which doesn't always map nicely to a relational DB.

Anonymous said...

Would be very interested in your comments on streambase and kdb+. The latter in particular with its apparent database style capabilities.

Pieter Greyling said...

I am not sure that I have met up with anybody up to the standards the 3 previous posts propose.

Certainly, I know people who are more than up to the job in specific areas.

But the role described requires deep development understanding as well.

Pieter Greyling said...

I am not sure that I have met up with anybody up to the standards the 3 previous posts propose.

Certainly, I know people who are more than up to the job in specific areas.

But the role described requires deep development understanding as well.

A kind of sweet mix between understanding the guts and the view open to the consumer.

A raw description of the concept of mapping data upward and out.

In practice, presentation is more often the final barrier toward raw data becoming information than anything else.

A Data Architect should understand this intimately.