Tuesday, September 14, 2010

Should a data architect be more adept on the logical or the physical model? What are important traits of a data architect?

I recently replied to a LinkedIn group discussion asking the question in this post's title. 

For the complete discussion, use the following link.

My Answer:

To use a house analogy, would you want to hire an architect to design your house who had no idea what was needed to actually build it at the "physical" level or what the zoning and building requirements were for the location you chose?  You wouldn't?  Then why would you expect a data architect NOT to understand what is needed at the physical level?  That is not saying that a data architect has to have experience as a DBA or database engineer, but, since the physical data model and implementation is the ultimate goal, a data architect should understand what is needed for the physical design.

Depending on the organization a data architect is working at, the actual tasks given to the data architect may vary.  My list below shows what I think are the duties of a data architect in their order of importance.  I will not go into in-depth explanations for each step.  I know of organizations that limit a data architect's role to items 1 and 2, while others include 1 through 4, and some include all of them.
  1. Understand the data requirements.  Get agreement from client that data requirements are complete and understood.
  2. Create Conceptual Data Model that documents the data entities needed and how they relate to each other.  Confirm with the client that the entities are complete and fulfill the high level data requirements
  3. Create Logical Data Model that documents the attributes assigned to fully describe each entity.  Confirm with the client that sufficient detail is captured for each entity.  Also, plan for future growth and needs by showing how new data types can be added without requiring a new design (using super-type, sub-type, lookup tables, etc).
  4. Provide traceability matrix to show how each data requirement has been met in conceptual and logical data models.
  5. Determine and document volume and user constraints.  Determine initial load volumes and future growth rates.  Determine initial user load: total users, maximum (peak) users, how connected, administrative users, power users, limited access users, ....  Determine future user growth rates.  These are important for physical database selection.
  6. Determine suitable database engine needed.  This task should not be done until steps 1 through 5 have been done, but quite often, the client has already decided what the database engine will be.  Results from Step 5 will then be useful to forecast the database engine's future scalability.  Clients should at least know what the risks are based on their choice of database engine.
  7. Create Physical Data Model.  Working with the DBA and/or other experts for the chosen database engine, transform the Logical Data Model into a physical data model.  It is unusual that a Logical Data Model can be converted directly into a "best fit" physical data model.
Other duties of a data architect may include:
  • Enterprise standards: naming, modeling, architecture, data warehouse, more.
  • Data profiling.
  • Gap analysis.
  • Data dictionary.
  • Data governance.
  • ETL design
  • Source-to-target data mapping.
If you look at recent postings for Data Architect positions, you will see many of them requiring expertise with the already chosen target database engine, reporting / BI tools, CASE modeling tools, etc.  But I do not agree that a data architect's duties and requirements include these tools, but rather knowing what needs to be done using these tools.  Tools can be learned and are an aid to doing what needs to be done.

I have elaborated on the duties of a data architect on my blog site.

Data Architect, Duties of a
Data Architect Job Description
Data Architect versus Database Architect

No comments:

Post a Comment