Last Updated on Monday, 27 December 2010 11:39

I was asked recently to prepare a 1-day training guide on Data Modeling. They gave me a comprehensive list of topics to cover and then, I started wondering why do we need another course in data modeling and more importantly why most data models that I QA or refer to, in companies from various industries, are still weak. Weak data model could be described as: inconsistent, cumbersome, no pattern, no generalization, not flexible, incomplete, unclear, contradictory and so on.

There is no question that proper knowledge and experience is required (I have put a list of items that Data Architects should know in the second list) but I think that this knowledge & experience must be coupled with certain essential behaviours traits to find good Data Architects.

I am not a specialist in psychometrics, but in interviews, I will ask questions in the following areas to gauge a Data Architect's soft skills, approach and dedication. A Data Architect:

  • Will make sure to spend enough time with users formally and informally with ultimate goal of business understanding
  • Understands the business processes and the interactions with the data model (he/she is not in a 'data only' silo)
  • Defines the architectures required by the business and then scope it down based on projects constraints (he/she never does the opposite, despite projects pressures)
  • Knows that data and process models define the application capabilities
  • Will take whatever (but still politically correct) actions to get the info that he/she needs
  • Is curious, use common sense and is able to allocate his time efficiently (he/she does not suffer from paralysis analysis)
  • Is creative, which means he/she can define new concepts, if this is what it takes to support the business
  • Will do whatever numbers of hours to meet the dates (paid or not)
  • Will not be satisfied until the data models and process models reach stability and are clear
  • Will not have the scope dictated by the IT project manager (the scope will be defined based on business requirements priorities, architecture required to support it and time and budget considerations)
  • Will define acceptable options to be selected by the project management
  • Is self-managed (very often being the first resource on a project in the making)
  • Does not expect to receive congratulations for a project well done  (a data architect typically starts on other projects and do not stay long enough with his/her creations)

In terms of knowledge, the more items they know, in the following list, the better, but this is not a recipe! When I choose a Data Architect, I use both lists. So a knowledgeable Data Architect know:

  • Various formalisms (and their pros and cons)
  • The various layers (conceptual, logical and physical)
  • How to physicalize the data models
  • How to use data modeling tools
  • How to design an application architecture using data and process models
  • The normal forms
  • How to denormalize
  • How a CIM (Common Information Model) can simplify applications integration
  • About MDM (Master Data Management)
  • About dimensional modeling
  • About industry models
  • How to extend industry models
  • How to get business requirements from all levels
  • How to have the models built by increments
  • How to conceptualize from Large Subjects down to Attributes
  • Model management
  • Architecture Frameworks and methodologies (Togaf, ZIFA, IAF, FEAF, NGOSS, RUP, P+, etc.)

To these, you add the standard HR questions and dig into their best and worst projects. This interview should last at least 2 hours but you increase your chance of hiring the right resource!