Data Architect
Jeff Hunter, August 12, 2004 - 1:33 pm UTC
I've been in jobs where the "Data Architect" was the primary database designer. They did most of the data modeling and weren't concerned with how the structures were implemented in the database. Of course, when things went wrong it was the DBA's fault because "the database was slow" but the UML model was perfect.
Right On!
Patrick, August 12, 2004 - 2:22 pm UTC
The role of a DA is global/local; global to the business needs, yet local for the application requirements.
A DA must:
- gather requirements from business and technology areas
- express business data and rules in a meaningful and consistent manner
- pick the right technology (DBMS's, messages, flat files, paper, etc.)
- determine the high-level design (system structure)
- understand the operations within a system of it's tables, views, triggers, SPs, APIs, messages and documents
- know the domain of acceptable values in a system
- participate on design of operations outside of or across systems
Letting an application developer or engineer do this job is a big mistake; nearly always results in an application-centric solution that is painful to rebuild. No slam on developers or engineers, just that their focus is (and should be) on a much, much narrower scope than a DA. Anyone can build an app, much harder to build a reusable, extensible and scalable business system.
Nice responses
Arun Mathur, August 24, 2004 - 10:26 am UTC
Thanks guys. Vague question, but how does one get more familiar with the corporate business? Also,
"In the last 4 weeks, I've taken 152 new questions, read 1,635 followups, and responded to 1,238 of the followups" is very impressive. Thanks Tom!
Arun
August 24, 2004 - 10:45 am UTC
poke your head up from the desk and network..... (not sarcastic, only way I know to do it)...
Patrick, September 09, 2004 - 5:08 pm UTC
Arun,
Requirements Definition is the phase is where business requirements are identified; think of it as the front-row seat in the development lifecycle. You get to meet business users, the development team, analysts, etc. and ask lots of questions.
It's always useful to have a few business contacts just to reality check some of the things that the developers build. Way too often, a database design is driven by application design, not business rules; many developers confuse a requirement with a solution.
When the application rules change (which is pretty often), the DB is broken and a painful restructuring is needed. True business rules are most stable and should be the foundation of any business system.
Nice post, Patrick!
Arun Mathur, September 15, 2004 - 3:49 pm UTC
I enjoyed reading it.
Take care,
Arun