A Note on This Article

This article was originally written in 2010, prompted by a request to develop a one-day Data Modeling training guide. The question it raises — why do weak data models persist across industries despite decades of accumulated knowledge — remains as relevant today as it was then. The answer, as this article argues, has less to do with technical knowledge than with the behavioural traits that separate good Data Architects from great ones.

Finding the Right Data Architect

When preparing a Data Modeling training guide, we found ourselves asking a more fundamental question: why do most data models we review — across companies, industries, and project sizes — remain weak? Weak data models share recognizable characteristics: inconsistency, lack of pattern, no generalization, inflexibility, incompleteness, and contradictions that accumulate over time and become increasingly expensive to unwind.

There is no question that proper knowledge and experience are required — we have outlined the technical knowledge a Data Architect should possess below. But that knowledge must be coupled with specific behavioural traits that are harder to teach and easier to overlook in a standard interview. In our experience, these traits are what separate a good Data Architect from a great one.

Behavioural Traits — What to Look For

When interviewing Data Architect candidates, we probe the following areas to assess soft skills, approach, and professional dedication. A strong Data Architect:

  • Invests sufficient time with users — both formally and informally — with the ultimate goal of deep business understanding
  • Understands business processes and their interactions with the data model — they do not operate in a data silo
  • Defines the architecture required by the business first, then scopes it down based on project constraints — never the reverse, regardless of project pressure
  • Understands that data and process models define application capabilities
  • Takes whatever politically appropriate steps are necessary to obtain the information they need
  • Is curious, applies common sense, and manages their time efficiently — they do not suffer from analysis paralysis
  • Is creative — capable of defining new concepts when the business requires it
  • Is deeply committed to delivery and takes ownership of outcomes
  • Is not satisfied until data models and process models reach stability and clarity
  • Does not allow project managers to dictate modeling scope — scope is defined by business requirements, architectural needs, and time and budget considerations, in that order
  • Defines acceptable options for project management to select from — rather than accepting arbitrary constraints
  • Is self-managed — often being the first resource engaged on a project still taking shape
  • Finds satisfaction in the quality and longevity of their work rather than in project recognition — a Data Architect typically moves on to the next engagement before their models are fully tested in production

Technical Knowledge — What They Should Know

The more items a candidate knows from the following list, the stronger their foundation — but this is not a checklist or a recipe. We use both lists together when evaluating candidates:

  • Various data modeling formalisms and their respective strengths and limitations
  • The conceptual, logical, and physical modeling layers — and how to navigate between them
  • How to physicalize data models for specific platform and performance requirements
  • Proficiency with data modeling tools
  • How to design application architecture using data and process models
  • Normal forms and when and how to apply them
  • How and when to denormalize
  • How a Common Information Model (CIM) simplifies application integration
  • Master Data Management (MDM)
  • Dimensional modeling
  • Industry data models and how to extend them
  • How to elicit business requirements at all organizational levels
  • Incremental model development
  • How to conceptualize from large subject areas down to attributes
  • Model management and version control
  • Architecture frameworks and methodologies — TOGAF, IAF, Zachman, FEAF, NGOSS, and others

Conducting the Interview

Combine both lists with standard competency-based HR questions, and dig into the candidate's best and worst projects — the worst projects are often the most revealing. This interview should last at least two hours. The investment is worth it: a great Data Architect is a rare resource, and the quality of their models will shape the flexibility, cost, and reliability of your data platform for years to come.