Should the Data Architect be a business expert or a DBA? 2

[avjoshi]

I always had a question about who is an ideal candidate to be a data architect for a warehouse project. In my experience DBAs and/or Business Experts have been elevated to model a data warehouse.

DBAs plus points:
1. Better understanding of the underlying database
2. Know a lot about performance tuning and can contribute towards optimal design of the warehouse.
3. Performance tuning experience also helps to improve query response time.
4. Experience in implementing HA/ DR solutions.
5. Understands the need for surrogate keys, especially when more than one source system is involved.
DBAs minus points:
1. Know a diddly-squat about the business
2. Extremely oriented towards ER modeling and try to design highly normalized warehouse.
3. Not very clear concepts on denormalization, star schema design, slowly changing dimensions, aggregations etc, hence poor data mart design.
4. Insist upon creating database ‘referential integrity’ constraints between Fact and Dimension tables.
5. Often fret about increasing data volumes.

BEs plus points:
1. Has good understanding of business and hence understands user requirements for the warehouse.
2. Usually better communicator hence can get ideas across the team.
3. Can acquire the modeling concepts and apply them to the business data as they know the data better.
BEs minus points:
1. Usually not very familiar with the database properties and hence fail to incorporate database specific design principles in to warehouse model.

 

[bigscott]

Interesting question, but I think there is no definate answer. It depends upon the individual. Some DBAs enjoy the business side (modeling of business rules) and make the transaction very easy. Some Business Experts are able to pick on on modeling techniques and become great modelers). But a data architect is a different position from the BE and the DBA just because of this, it is a different job. DBA's do not necessarily make good modelers, and neither do BE's.

No that I claimed either can work, if I HAD to look within one group or another, I would look into the DBA group, and here is why. I disagree with your point of DBA's "Not very clear concepts on denormalization, star schema design, slowly changing dimensions, aggregations etc, hence poor data mart design". Although they may not understand exactly whaat a star or a slowly changing dimension is, they do know about denomalization and aggregations. Even a star schema can have variations based upon the RDBMS it will be implemented upon. Is the star consolidated, or is it snow flaked, or is it "starflaked" (a combination of both techniques). How do the indexes relate. Is the fact working on bitmaps, star joins, table scans, etc. If teradata, how will it be distributed? So many aspects of the model depend upon the RDBMS. And a DBA will know more about this. I believe it is easier to learn the business to create a model that to learn a RDBMS.

It sounds like you have a definate pre-conceived notion about DBA's and what they will and will not do. But I know many DBA's that do not fall into your definition.

Are you looking for a data architect?

 

[avjoshi]

No, As a matter of fact, I have a DBA background. These were my observations on working several DW projects. Once, we had a modeling team in which we had members of both. Which is where most of the differences became more apparent.
When I gave negatives about DBA, I didn’t intend to say that they would become bad modelers. It’s just that ER modeling and referential integrity concepts are so ingrained in them that it is hard for them to unlearn them.
I agree with you that if one were to choose between the two, DBA would make better candidate.

 

[ganotedp]

Data Architects should comfortably work in both worlds, and more. DAs should be know enough (or be able to learn about the business in the usual discovery process) to represent the requirements in a logical model from an enterprise vantage, trace down data stewardship, etc. DAs should know enough about the database to get an reasonable first-cut physical model then work with the DBAs (the DBAs will probably sweat out the details of tablespaces, etc). In addition DA will probably work with ETL tools and programmers to ensure the data feeds are solid, which is outside the normal scope of the the Business Expert or DBAs.

To understand the DA's role (from the vantage of a DBA), I found the 4th part of Craig Mullin's multi-part article helpful at

http://www.dbazine.com/dba_4.shtml

In my opinion THE most outstanding article describing Data Architecture is one by Nirmal Baid at

http://sunsite.uakom.sk/sunworldonline/swol-07-1998/swol-07-itarchitect.html

I also recommend Rajan Chandras' article on Data Architecture entitled "Get the Complete Picture" at

http://www.intelligententerprise.com/010130/feat3_1.shtml