Career PathJuly 2026 Edition.Detailed roadmapMonthly research refresh
Data Architect
Design data models, warehouses, governance, integration patterns, and architecture decisions for scale.
$137K-$190K
US base range
4% growth
growth signal
8 stages
Beginner to job-ready
12-18 months
Full-time timeline
Data Architect salary ranges by market. US: $137K-$190K, source Robert Half 2026 Data Architect; Europe: EUR 75K-145K, source Robert Half UK 2026 Data Architect; India: INR 17L-35L, source ERI SalaryExpert India data architect proxy; China: CNY 500K-1.00M, source Robert Half China 2026 Data Architect; Remote: $120K-$230K, source Remote senior data architecture proxy. Salary ranges are shown by market because one global average would mislead learners. Ranges are annual base or fixed cash proxies unless the source states otherwise.
Salary range
Annual base or fixed cash
$137K-$190K
US market/Annual range
Scope
Annual base or fixed cash range. Equity, bonus, tax, benefits, city tier, company tier, and seniority can move the final offer materially.
Market note
Role-specific US national starting salary range; BLS database architects anchor the occupation at a $135,980 May 2024 median.
Salary ranges are shown by market because one global average would mislead learners. Ranges are annual base or fixed cash proxies unless the source states otherwise.
Design entities, relationships, grain, history, and lifecycle rules.
02
02
Warehouse architecture
4-5 weeks
Plan layers, marts, performance, cost, and platform boundaries.
03
03
Integration patterns
3-4 weeks
Choose batch, streaming, CDC, APIs, and file exchange patterns deliberately.
04
04
Governance and metadata
3-4 weeks
Make ownership, lineage, catalogs, definitions, and access rules operational.
05
05
Data quality architecture
2-3 weeks
Design checks, contracts, observability, and incident response at system level.
06
06
Cloud and lakehouse design
4-5 weeks
Understand table formats, storage, compute separation, and platform tradeoffs.
07
07
AI-ready data architecture
2-3 weeks
Support vector search, feature stores, privacy controls, and model-facing data products.
08
08
Architecture portfolio
3-4 weeks
Create architecture decision records and diagrams that explain tradeoffs clearly.
Complete topic index
Full definitions, proof artifacts, LDS resources, and external references for every roadmap topic.
View
01
Data modeling foundations
4-5 weeks
ER modeling
core
Data modeling foundations: Design entities, relationships, grain, history, and lifecycle rules.
What it is
Data modeling decides how business events become facts, dimensions, entities, history, and reusable semantic definitions.
Why it matters
The model is where downstream trust is won or lost. Bad grain creates duplicated revenue, broken retention, and dashboards that disagree even when every query is syntactically correct.
Proof to build
Model one domain as source tables, facts, dimensions, semantic metrics, and tests. Include a grain statement and one example query that proves the model answers a real business question.
Data modeling foundations: Design entities, relationships, grain, history, and lifecycle rules.
What it is
Data modeling decides how business events become facts, dimensions, entities, history, and reusable semantic definitions.
Why it matters
The model is where downstream trust is won or lost. Bad grain creates duplicated revenue, broken retention, and dashboards that disagree even when every query is syntactically correct.
Proof to build
Model one domain as source tables, facts, dimensions, semantic metrics, and tests. Include a grain statement and one example query that proves the model answers a real business question.
Data modeling foundations: Design entities, relationships, grain, history, and lifecycle rules.
What it is
Data modeling decides how business events become facts, dimensions, entities, history, and reusable semantic definitions.
Why it matters
The model is where downstream trust is won or lost. Bad grain creates duplicated revenue, broken retention, and dashboards that disagree even when every query is syntactically correct.
Proof to build
Model one domain as source tables, facts, dimensions, semantic metrics, and tests. Include a grain statement and one example query that proves the model answers a real business question.
Create proof that this stage is more than passive study.
What it is
A data modeling foundations portfolio artifact is a public proof piece for this stage: a small but complete deliverable that shows how a Data Architect frames the problem, chooses tools, validates the result, and explains the tradeoffs.
Why it matters
This is the work product that makes the stage credible. For Data Architect, the artifact should show inputs, assumptions, methods, validation, tradeoffs, and a decision-ready output rather than a tutorial clone.
Proof to build
Publish one data modeling foundations artifact with README, inputs, assumptions, method, validation checks, screenshots or outputs, caveats, and a short summary of what the artifact proves for Data Architect readiness.
Know how this stage appears in screening, take-homes, and role-specific interviews.
What it is
The interview signal for data modeling foundations is your ability to explain the work under pressure: assumptions, tradeoffs, failure modes, implementation choices, and how the output would help a real team decide what to do next.
Why it matters
Hiring teams need to see judgment, not just vocabulary. This topic turns data modeling foundations into interview-ready stories, diagrams, live explanations, and examples that map to real Data Architect work.
Proof to build
Prepare a two-minute explanation, one diagram or query/notebook walkthrough, and three follow-up answers for this stage: why this approach, what could fail, and how you would improve it in production.
Warehouse architecture: Plan layers, marts, performance, cost, and platform boundaries.
What it is
Warehouse architecture covers storage, compute, marts, permissions, cost controls, performance tuning, deployment layers, and how data products are exposed.
Why it matters
Data architects and analytics engineers need enough platform judgment to avoid expensive, slow, or brittle designs. Cost, query latency, lineage, and ownership are architecture decisions, not afterthoughts.
Proof to build
Write an architecture decision record comparing two warehouse/lakehouse designs for the same workload, with cost, freshness, governance, and performance tradeoffs.
Warehouse architecture: Plan layers, marts, performance, cost, and platform boundaries.
What it is
Data modeling decides how business events become facts, dimensions, entities, history, and reusable semantic definitions.
Why it matters
The model is where downstream trust is won or lost. Bad grain creates duplicated revenue, broken retention, and dashboards that disagree even when every query is syntactically correct.
Proof to build
Model one domain as source tables, facts, dimensions, semantic metrics, and tests. Include a grain statement and one example query that proves the model answers a real business question.
Warehouse architecture: Plan layers, marts, performance, cost, and platform boundaries.
What it is
Warehouse architecture covers storage, compute, marts, permissions, cost controls, performance tuning, deployment layers, and how data products are exposed.
Why it matters
Data architects and analytics engineers need enough platform judgment to avoid expensive, slow, or brittle designs. Cost, query latency, lineage, and ownership are architecture decisions, not afterthoughts.
Proof to build
Write an architecture decision record comparing two warehouse/lakehouse designs for the same workload, with cost, freshness, governance, and performance tradeoffs.
Create proof that this stage is more than passive study.
What it is
A warehouse architecture portfolio artifact is a public proof piece for this stage: a small but complete deliverable that shows how a Data Architect frames the problem, chooses tools, validates the result, and explains the tradeoffs.
Why it matters
This is the work product that makes the stage credible. For Data Architect, the artifact should show inputs, assumptions, methods, validation, tradeoffs, and a decision-ready output rather than a tutorial clone.
Proof to build
Publish one warehouse architecture artifact with README, inputs, assumptions, method, validation checks, screenshots or outputs, caveats, and a short summary of what the artifact proves for Data Architect readiness.
Know how this stage appears in screening, take-homes, and role-specific interviews.
What it is
The interview signal for warehouse architecture is your ability to explain the work under pressure: assumptions, tradeoffs, failure modes, implementation choices, and how the output would help a real team decide what to do next.
Why it matters
Hiring teams need to see judgment, not just vocabulary. This topic turns warehouse architecture into interview-ready stories, diagrams, live explanations, and examples that map to real Data Architect work.
Proof to build
Prepare a two-minute explanation, one diagram or query/notebook walkthrough, and three follow-up answers for this stage: why this approach, what could fail, and how you would improve it in production.
Integration patterns move data between systems through batch loads, CDC, APIs, streams, files, and event contracts.
Why it matters
Architecture quality shows up at the boundaries. Poor integration design creates late data, duplicate events, broken replay, and governance gaps that every downstream analyst inherits.
Proof to build
Design a source-to-warehouse ingestion plan with expected latency, failure modes, idempotency strategy, schema-change handling, and data-quality checks.
Solution architecture is the shape of the deployed system: application boundary, data access, authentication, APIs, logging, deployment path, security controls, and ownership after launch.
Why it matters
Customer-facing AI engineers are judged by adoption, not prototypes. A clean architecture lets the first pilot become a maintainable deployment instead of a demo that dies when it meets permissions, audit logs, or messy enterprise data.
Proof to build
Draw an architecture diagram for an AI workflow with auth, data sources, retrieval or tools, evals, observability, and rollback. Add the tradeoffs: what you deliberately left out and why.
Integration patterns move data between systems through batch loads, CDC, APIs, streams, files, and event contracts.
Why it matters
Architecture quality shows up at the boundaries. Poor integration design creates late data, duplicate events, broken replay, and governance gaps that every downstream analyst inherits.
Proof to build
Design a source-to-warehouse ingestion plan with expected latency, failure modes, idempotency strategy, schema-change handling, and data-quality checks.
Create proof that this stage is more than passive study.
What it is
A integration patterns portfolio artifact is a public proof piece for this stage: a small but complete deliverable that shows how a Data Architect frames the problem, chooses tools, validates the result, and explains the tradeoffs.
Why it matters
This is the work product that makes the stage credible. For Data Architect, the artifact should show inputs, assumptions, methods, validation, tradeoffs, and a decision-ready output rather than a tutorial clone.
Proof to build
Publish one integration patterns artifact with README, inputs, assumptions, method, validation checks, screenshots or outputs, caveats, and a short summary of what the artifact proves for Data Architect readiness.
Know how this stage appears in screening, take-homes, and role-specific interviews.
What it is
The interview signal for integration patterns is your ability to explain the work under pressure: assumptions, tradeoffs, failure modes, implementation choices, and how the output would help a real team decide what to do next.
Why it matters
Hiring teams need to see judgment, not just vocabulary. This topic turns integration patterns into interview-ready stories, diagrams, live explanations, and examples that map to real Data Architect work.
Proof to build
Prepare a two-minute explanation, one diagram or query/notebook walkthrough, and three follow-up answers for this stage: why this approach, what could fail, and how you would improve it in production.
Governance and metadata: Make ownership, lineage, catalogs, definitions, and access rules operational.
What it is
Metadata and lineage explain what data exists, who owns it, how it changes, where it flows, and which downstream assets depend on it.
Why it matters
Governance without operational metadata becomes policy theatre. Real users need searchable definitions, lineage for impact analysis, and owners who can fix broken data.
Proof to build
Document a mini data catalog: glossary, table owners, lineage diagram, access level, freshness SLA, and a downstream impact analysis for one schema change.
Governance and metadata: Make ownership, lineage, catalogs, definitions, and access rules operational.
What it is
Metadata and lineage explain what data exists, who owns it, how it changes, where it flows, and which downstream assets depend on it.
Why it matters
Governance without operational metadata becomes policy theatre. Real users need searchable definitions, lineage for impact analysis, and owners who can fix broken data.
Proof to build
Document a mini data catalog: glossary, table owners, lineage diagram, access level, freshness SLA, and a downstream impact analysis for one schema change.
Governance and metadata: Make ownership, lineage, catalogs, definitions, and access rules operational.
What it is
Metadata and lineage explain what data exists, who owns it, how it changes, where it flows, and which downstream assets depend on it.
Why it matters
Governance without operational metadata becomes policy theatre. Real users need searchable definitions, lineage for impact analysis, and owners who can fix broken data.
Proof to build
Document a mini data catalog: glossary, table owners, lineage diagram, access level, freshness SLA, and a downstream impact analysis for one schema change.
Create proof that this stage is more than passive study.
What it is
A governance and metadata portfolio artifact is a public proof piece for this stage: a small but complete deliverable that shows how a Data Architect frames the problem, chooses tools, validates the result, and explains the tradeoffs.
Why it matters
This is the work product that makes the stage credible. For Data Architect, the artifact should show inputs, assumptions, methods, validation, tradeoffs, and a decision-ready output rather than a tutorial clone.
Proof to build
Publish one governance and metadata artifact with README, inputs, assumptions, method, validation checks, screenshots or outputs, caveats, and a short summary of what the artifact proves for Data Architect readiness.
Know how this stage appears in screening, take-homes, and role-specific interviews.
What it is
The interview signal for governance and metadata is your ability to explain the work under pressure: assumptions, tradeoffs, failure modes, implementation choices, and how the output would help a real team decide what to do next.
Why it matters
Hiring teams need to see judgment, not just vocabulary. This topic turns governance and metadata into interview-ready stories, diagrams, live explanations, and examples that map to real Data Architect work.
Proof to build
Prepare a two-minute explanation, one diagram or query/notebook walkthrough, and three follow-up answers for this stage: why this approach, what could fail, and how you would improve it in production.
Create proof that this stage is more than passive study.
What it is
A data quality architecture portfolio artifact is a public proof piece for this stage: a small but complete deliverable that shows how a Data Architect frames the problem, chooses tools, validates the result, and explains the tradeoffs.
Why it matters
This is the work product that makes the stage credible. For Data Architect, the artifact should show inputs, assumptions, methods, validation, tradeoffs, and a decision-ready output rather than a tutorial clone.
Proof to build
Publish one data quality architecture artifact with README, inputs, assumptions, method, validation checks, screenshots or outputs, caveats, and a short summary of what the artifact proves for Data Architect readiness.
Know how this stage appears in screening, take-homes, and role-specific interviews.
What it is
The interview signal for data quality architecture is your ability to explain the work under pressure: assumptions, tradeoffs, failure modes, implementation choices, and how the output would help a real team decide what to do next.
Why it matters
Hiring teams need to see judgment, not just vocabulary. This topic turns data quality architecture into interview-ready stories, diagrams, live explanations, and examples that map to real Data Architect work.
Proof to build
Prepare a two-minute explanation, one diagram or query/notebook walkthrough, and three follow-up answers for this stage: why this approach, what could fail, and how you would improve it in production.
Cloud and lakehouse design: Understand table formats, storage, compute separation, and platform tradeoffs.
What it is
AI-ready data architecture extends the warehouse into feature pipelines, vector indexes, lakehouse tables, privacy controls, and data products that models can safely consume.
Why it matters
AI teams are constrained by data access, data quality, permissioning, and retrieval quality. The best architecture work makes model-facing data reliable before an ML or LLM team depends on it.
Proof to build
Design an AI data product with source tables, feature or embedding pipeline, access rules, freshness checks, and an evaluation query for retrieval or model input quality.
Cloud and lakehouse design: Understand table formats, storage, compute separation, and platform tradeoffs.
What it is
AI-ready data architecture extends the warehouse into feature pipelines, vector indexes, lakehouse tables, privacy controls, and data products that models can safely consume.
Why it matters
AI teams are constrained by data access, data quality, permissioning, and retrieval quality. The best architecture work makes model-facing data reliable before an ML or LLM team depends on it.
Proof to build
Design an AI data product with source tables, feature or embedding pipeline, access rules, freshness checks, and an evaluation query for retrieval or model input quality.
Cloud and lakehouse design: Understand table formats, storage, compute separation, and platform tradeoffs.
What it is
AI-ready data architecture extends the warehouse into feature pipelines, vector indexes, lakehouse tables, privacy controls, and data products that models can safely consume.
Why it matters
AI teams are constrained by data access, data quality, permissioning, and retrieval quality. The best architecture work makes model-facing data reliable before an ML or LLM team depends on it.
Proof to build
Design an AI data product with source tables, feature or embedding pipeline, access rules, freshness checks, and an evaluation query for retrieval or model input quality.
Create proof that this stage is more than passive study.
What it is
A cloud and lakehouse design portfolio artifact is a public proof piece for this stage: a small but complete deliverable that shows how a Data Architect frames the problem, chooses tools, validates the result, and explains the tradeoffs.
Why it matters
This is the work product that makes the stage credible. For Data Architect, the artifact should show inputs, assumptions, methods, validation, tradeoffs, and a decision-ready output rather than a tutorial clone.
Proof to build
Publish one cloud and lakehouse design artifact with README, inputs, assumptions, method, validation checks, screenshots or outputs, caveats, and a short summary of what the artifact proves for Data Architect readiness.
Know how this stage appears in screening, take-homes, and role-specific interviews.
What it is
The interview signal for cloud and lakehouse design is your ability to explain the work under pressure: assumptions, tradeoffs, failure modes, implementation choices, and how the output would help a real team decide what to do next.
Why it matters
Hiring teams need to see judgment, not just vocabulary. This topic turns cloud and lakehouse design into interview-ready stories, diagrams, live explanations, and examples that map to real Data Architect work.
Proof to build
Prepare a two-minute explanation, one diagram or query/notebook walkthrough, and three follow-up answers for this stage: why this approach, what could fail, and how you would improve it in production.
AI-ready data architecture: Support vector search, feature stores, privacy controls, and model-facing data products.
What it is
LLM application engineering connects prompts, structured outputs, retrieval, tool calls, and evaluation into a product workflow that users can trust repeatedly.
Why it matters
AI roles in 2026 are less about toy prompts and more about building systems that survive ambiguous inputs, private data, latency budgets, source grounding, and regressions after a model update.
Proof to build
Ship a small RAG or structured-output app with traces, citations, an evaluation set, fallback behavior, and a short writeup explaining the failure modes you found.
AI-ready data architecture: Support vector search, feature stores, privacy controls, and model-facing data products.
What it is
AI-ready data architecture extends the warehouse into feature pipelines, vector indexes, lakehouse tables, privacy controls, and data products that models can safely consume.
Why it matters
AI teams are constrained by data access, data quality, permissioning, and retrieval quality. The best architecture work makes model-facing data reliable before an ML or LLM team depends on it.
Proof to build
Design an AI data product with source tables, feature or embedding pipeline, access rules, freshness checks, and an evaluation query for retrieval or model input quality.
AI-ready data architecture: Support vector search, feature stores, privacy controls, and model-facing data products.
What it is
AI-ready data architecture extends the warehouse into feature pipelines, vector indexes, lakehouse tables, privacy controls, and data products that models can safely consume.
Why it matters
AI teams are constrained by data access, data quality, permissioning, and retrieval quality. The best architecture work makes model-facing data reliable before an ML or LLM team depends on it.
Proof to build
Design an AI data product with source tables, feature or embedding pipeline, access rules, freshness checks, and an evaluation query for retrieval or model input quality.
Create proof that this stage is more than passive study.
What it is
A ai-ready data architecture portfolio artifact is a public proof piece for this stage: a small but complete deliverable that shows how a Data Architect frames the problem, chooses tools, validates the result, and explains the tradeoffs.
Why it matters
This is the work product that makes the stage credible. For Data Architect, the artifact should show inputs, assumptions, methods, validation, tradeoffs, and a decision-ready output rather than a tutorial clone.
Proof to build
Publish one ai-ready data architecture artifact with README, inputs, assumptions, method, validation checks, screenshots or outputs, caveats, and a short summary of what the artifact proves for Data Architect readiness.
Know how this stage appears in screening, take-homes, and role-specific interviews.
What it is
The interview signal for ai-ready data architecture is your ability to explain the work under pressure: assumptions, tradeoffs, failure modes, implementation choices, and how the output would help a real team decide what to do next.
Why it matters
Hiring teams need to see judgment, not just vocabulary. This topic turns ai-ready data architecture into interview-ready stories, diagrams, live explanations, and examples that map to real Data Architect work.
Proof to build
Prepare a two-minute explanation, one diagram or query/notebook walkthrough, and three follow-up answers for this stage: why this approach, what could fail, and how you would improve it in production.
Architecture portfolio: Create architecture decision records and diagrams that explain tradeoffs clearly.
What it is
Portfolio and interview work turns learning into proof: a public artifact, decision memo, reproducible repo, diagram, dashboard, notebook, or interview story.
Why it matters
Hiring teams cannot infer readiness from a list of tools. They need evidence that you can frame a problem, make tradeoffs, validate your result, and explain the business impact.
Proof to build
Publish one role-specific artifact with README, assumptions, dataset notes, validation checks, screenshots, and a short hiring-manager summary of what the work proves.
Architecture portfolio: Create architecture decision records and diagrams that explain tradeoffs clearly.
What it is
Portfolio and interview work turns learning into proof: a public artifact, decision memo, reproducible repo, diagram, dashboard, notebook, or interview story.
Why it matters
Hiring teams cannot infer readiness from a list of tools. They need evidence that you can frame a problem, make tradeoffs, validate your result, and explain the business impact.
Proof to build
Publish one role-specific artifact with README, assumptions, dataset notes, validation checks, screenshots, and a short hiring-manager summary of what the work proves.
Architecture portfolio: Create architecture decision records and diagrams that explain tradeoffs clearly.
What it is
Stakeholder communication turns analysis into a decision path: audience, tradeoff, recommendation, risk, next action, and what would change the conclusion.
Why it matters
The best technical answer still fails when the business cannot act on it. Analysts, FDEs, OR practitioners, architects, and product analysts need to reduce ambiguity without hiding uncertainty.
Proof to build
Write a decision memo or presentation page with the recommendation, metric impact, risks, alternatives rejected, owner, timeline, and one follow-up question for stakeholders.
Create proof that this stage is more than passive study.
What it is
A architecture portfolio portfolio artifact is a public proof piece for this stage: a small but complete deliverable that shows how a Data Architect frames the problem, chooses tools, validates the result, and explains the tradeoffs.
Why it matters
This is the work product that makes the stage credible. For Data Architect, the artifact should show inputs, assumptions, methods, validation, tradeoffs, and a decision-ready output rather than a tutorial clone.
Proof to build
Publish one architecture portfolio artifact with README, inputs, assumptions, method, validation checks, screenshots or outputs, caveats, and a short summary of what the artifact proves for Data Architect readiness.
Know how this stage appears in screening, take-homes, and role-specific interviews.
What it is
The interview signal for architecture portfolio is your ability to explain the work under pressure: assumptions, tradeoffs, failure modes, implementation choices, and how the output would help a real team decide what to do next.
Why it matters
Hiring teams need to see judgment, not just vocabulary. This topic turns architecture portfolio into interview-ready stories, diagrams, live explanations, and examples that map to real Data Architect work.
Proof to build
Prepare a two-minute explanation, one diagram or query/notebook walkthrough, and three follow-up answers for this stage: why this approach, what could fail, and how you would improve it in production.
