Skip to Main Content

Breadcrumb

May 4th

Question and Answer

Tom Kyte

Thanks for the question, Arun.

Asked: August 12, 2004 - 11:41 am UTC

Last updated: September 15, 2004 - 3:49 pm UTC

Version: 9.2

Viewed 1000+ times

You Asked

Tom,

Without saying, your contributions are invaluable. My question is a bit strange, but I'll ask it anyway :)

Over the past 8 years, my primary skillset has been in Oracle development : PL/SQL, SQL*Plus, Pro*C, SQL*Loader, etc.. However, I've also been thrown into a DBA role such as in my current position, which I also enjoy very much. The other day, a good friend of mine asked if I consider myself a database architect. My initial response was no, but when he gave me specifics of a database architect position his colleague is trying to fill, it sounded as if the description falls completely under the tasks that I currently do. So, I considered myself somewhat "qualified" if my friend wanted to recommend me, even though I've never filled an architect position before. You've done a really nice job at describing what's expected of a DBA, and I was wondering if you had similar thoughts as to what's expected of a database architect.

Thanks Tom. Have a great weekend.

Best wishes,
Arun




and Tom said...

well, it is mostly a matter of opinion but a "database architect" or "data architect" to me is someone

o firmly grounded in the technology -- knows what is can and CANNOT do.

o stays grounded in the technology but might not be totally hands on with it (eg: stays super current)

o understands the business, the corporate business -- not joe schmoe down the hall, the corporate business

o is tough enough to be able to balance all of the joe schmoe's demands with the corporate business plans

o has a global view of what's going on

o sets the standards (eg: thou shall do backup like this, you will test recovery like this, our disaster recovery plan is X, our testing process is Y)

o is a pleasure to work with (perhaps the most important :)


maybe in a way, they are a super technical CIO/CTO like person without the "C" and they generally work in a team.



But everyone will have a different opinion -- just watch, i'm sure someone will chime in.

Rating

  (5 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

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




Tom Kyte
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