JPJobPrepfull-stack interview
RoadmapsJS CompilerStar on GitHub
Career Roadmaps · Data Architect

Career roadmap

Data Architect

Decide how an organisation's data is structured, stored, governed and shared, and make those decisions stick.

Time
9-12 months part-time
Entry bar
Substantial data engineering, modelling or DBA experience.
Stages
5 · 25 topics
0/25 studied0%
All roadmaps

Before you start Data Architect

  • Years of hands-on data work
  • Modelling and warehouse experience
  • Ability to write and present design documents

Modelling and design

6-7 weeks · 0/5 topics

Architecture is modelling decisions plus the reasons behind them.

  1. Starting from the business, not the tables. Frequently skipped, always missed.

    • Entity relationship modelling
    • Business glossary and definitions
    • Conceptual to logical to physical
    • Domain-driven data boundaries

  2. Kimball, Inmon and Data Vault, and knowing when each is appropriate.

    • Dimensional modelling in depth
    • Data Vault for auditability
    • Normalised enterprise warehouse
    • Choosing an approach for the context

  3. OLTP design constraints differ sharply from analytical ones.

    • Normalisation for transactional systems
    • Access pattern driven NoSQL design
    • Event modelling
    • Polyglot persistence decisions

  4. How data moves between systems is the bulk of enterprise data architecture.

    • Batch, CDC and event streaming
    • API-based data exchange
    • Master data management
    • Integration anti-patterns

  5. Quality is architectural: it comes from constraints and contracts, not cleanup jobs.

    • Constraints and referential integrity
    • Data contracts between systems
    • Reference data management
    • Quality measurement design

BuildProduce conceptual, logical and physical models for one business domain, with rationale.

Platform architecture

5-7 weeks · 0/5 topics

Choosing and arranging the components an entire data organisation will live with.

  1. The central platform decision, and one you must justify rather than assume.

    • Warehouse versus lake versus lakehouse
    • Open table formats and portability
    • Storage and compute separation
    • Vendor lock-in assessment

  2. Data mesh is often misapplied. Knowing the preconditions is the senior view.

    • Central platform team model
    • Data mesh principles and prerequisites
    • Domain ownership and products
    • Federated governance

  3. Deciding what genuinely needs to be real time, which is usually less than requested.

    • Latency requirements gathering
    • Streaming platform selection
    • Serving layer design
    • Cost of real-time versus batch

  4. Feature stores, vector stores and the data foundations AI programmes need.

    Ch — Embeddings & Vector Search
    • Feature store architecture
    • Vector storage for retrieval
    • Training data lineage
    • Serving data to models

  5. Most architecture work is moving from a state nobody designed.

    • Current state assessment
    • Phased migration and coexistence
    • Legacy decommissioning
    • Risk and rollback planning

BuildA target-state architecture with an options analysis and a phased migration plan.

Governance and compliance

5-6 weeks · 0/5 topics

The half of the role that determines whether the architecture survives an audit.

  1. Ownership and stewardship, defined so decisions have an owner.

    • Ownership and stewardship models
    • Data governance councils
    • Policy definition and enforcement
    • Making governance non-obstructive

  2. You cannot govern what nobody can find or trace.

    • Data catalogue implementation
    • Automated lineage capture
    • Business glossary integration
    • Adoption and metadata quality

  3. Regulation drives most enterprise data architecture funding.

    • GDPR and regional privacy law
    • Classification and PII discovery
    • Masking, tokenisation and pseudonymisation
    • Right to erasure in analytical stores

  4. Fine-grained access without making the platform unusable.

    • Role and attribute-based access
    • Column and row-level security
    • Access request and review processes
    • Cross-domain sharing

  5. Keeping everything forever is a cost and a liability.

    • Retention schedules by data class
    • Archival and tiering
    • Legal hold handling
    • Defensible deletion

BuildA governance framework with classification, ownership, retention and access policies.

Delivery and influence

4-5 weeks · 0/5 topics

An architecture nobody implements is a document. Adoption is the real deliverable.

  1. Decision records are the daily artefact and a common interview request.

    • Architecture decision records
    • Options analysis with trade-offs
    • Diagramming standards
    • Writing for mixed audiences

  2. Reusable patterns beat bespoke review for every project.

    • Reference architecture publication
    • Reusable patterns and templates
    • Exception handling process
    • Keeping standards current

  3. Platform choices commit large budgets for years.

    • Total cost of ownership modelling
    • Vendor evaluation and proof of concept
    • Contract and licensing considerations
    • Exit strategy

  4. Architecture is decided in meetings as much as in documents.

    • Working with engineering leadership
    • Presenting to executives
    • Handling competing domain interests
    • Building consensus on standards

  5. Architects who stop building lose the ability to judge feasibility.

    • Prototyping proposed patterns
    • Reviewing pipeline code
    • Understanding operational reality
    • Keeping current with platform changes

BuildTake one architectural decision from proposal to implemented and adopted by a delivery team.

Interview preparation

3-5 weeks · 0/5 topics

Interviews are design discussions, case studies and evidence of past decisions.

  1. Design a data platform for a described organisation, live.

    • Requirements before technology
    • Justifying every component
    • Handling constraints and legacy
    • Phasing the delivery

  2. Model a domain on a whiteboard and defend the grain and keys.

    • Entity identification
    • Grain and key decisions
    • History requirements
    • Handling ambiguity in requirements

  3. How would you make this estate compliant and still usable.

    • Classification approach
    • Access model design
    • Erasure and retention handling
    • Balancing control and velocity

  4. Common in consultancies: a written brief and a presented recommendation.

    • Reading a brief for real constraints
    • Options analysis
    • Cost and risk estimation
    • Executive presentation

  5. Influence without authority, and decisions that turned out wrong.

    • An architecture decision you got wrong
    • Convincing teams to adopt a standard
    • Handling a vendor-driven decision
    • Balancing ideal with achievable

BuildA portfolio of architecture decision records and one full target-state design.

Data Architect tools on your CV

  • Snowflake / Databricks
  • Kafka
  • dbt
  • Data catalogue tooling
  • ER modelling tools
  • Terraform
  • C4 / ArchiMate

What Data Architect employers ask to see

  • A target-state architecture with options analysis
  • A set of architecture decision records from real projects
  • A governance framework with classification and retention
  • A completed platform migration with measured outcomes

Senior role in enterprises with real data estates. Regulatory pressure and AI programmes both increased demand, since neither works on ungoverned data.

Content last reviewed 2026-08-31. Guidance only — no institute or paid placement is endorsed anywhere in this book.