10.11.26

What's the Difference Between Hiring a Data/Solutions Architect and a Data Engineer for an Azure Transformation Programme?

When a CTO or Head of Data sits down to write a job spec for an Azure transformation programme, the Fabric, Synapse, and Data Factory keywords often end up in a single list — and that's where the spec starts pointing at two different people. Getting the architect/engineer distinction right at the brief stage is the difference between interviewing five strong candidates who can't actually do the job and interviewing one who can. Below, we answer the questions we hear most often from hiring leaders trying to work out which role — or which combination — their programme actually needs.

Understanding the Core Distinction

What's the real difference between a Data/Solutions Architect and a Data Engineer in an Azure context?

A Solutions or Data Architect designs the strategic shape of a platform; a Data Engineer builds and operates it. One architect we spoke with, who has worked across Dynamics, Synapse, and Fabric, put it directly: "I come from a solutions and a data architect perspective... as an architect I don't really do much of that anymore. A lot of it's a bit of SQL querying and then I hand it over to the engineers to develop the solution that I design". That's the organising frame for the whole hiring decision — architects set direction and data model strategy, engineers build the pipelines, transformations, and infrastructure that make the design real. A data engineer we spoke with, by contrast, described day-to-day work using Azure Data Factory for orchestration and Databricks pipelines for transformation of operational data — hands-on delivery work, not design authority.

If both roles use Fabric, Synapse, and Data Factory, how do I tell them apart on a CV?

Look at what the candidate did with those tools, not whether they're listed. An architect candidate described working across "Fabric and so on... Synapse and then we tried to move to Fabric eventually. And then you had your data warehouse with your medallion structure" — but framed this as "the architects group... working together to build the solution from the application side". A data engineer candidate, working on a Fabric project, described the same category of tools in execution terms: "Fabric pipelines, you know, PySpark, Spark SQL, Power BI" used to build and hand over a completed data cube solution with three other data engineers. The tool list overlaps almost completely — the verbs don't. Architects "design" and "hand over"; engineers "build," "implement," and "deliver."

Why does this distinction matter enough to build a job spec around it?

Conflating the two roles in a single brief means you'll interview people who are strong at one skill and weak at the other, and you won't find out which until the role starts. An architect explicitly separates the two skill sets in how they talk about their own career: "the roles I'm looking for, I'm not looking for being like a senior engineer type role... even though I do do some hands-on stuff". If your job spec asks for both deep architectural ownership and daily hands-on pipeline development, you're either asking a senior architect to do junior-engineer-rate work, or asking an engineer to own decisions they've never had mandate over. Either way, the mismatch surfaces mid-contract, not at interview.

Scoping the Architect Role

Before you can write an effective architect job spec, it helps to understand what "strategic design" actually covers in a live Azure programme.

What does "strategic design" actually look like day-to-day for a Solutions/Data Architect?

Strategic design means defining how systems fit together before any pipeline gets built. One architect described their role on an industry-specific transformation programme as building "the new strategic vision" and providing "the solution and data requirements," working with an architects group to determine "how that fits together" across vendor applications and the downstream Azure reporting layer. On the data side specifically, this extends to "data design, data warehouse design, strategically from a data perspective how you want to work". If your programme needs someone to decide whether Fabric or Synapse is the right destination for a given workload, or how medallion layers should be structured before engineers start building, that's architect-level work.

Does a good architect still need hands-on technical ability?

Yes, but it's a different kind of hands-on than engineering delivery. The same architect was clear that their technical background matters even though daily execution has moved on: "I am, I come from a technical hands-on background, but as an architect I don't really do much of that anymore. A lot of it's a bit of SQL querying and then I hand it over to the engineers". Hire an architect who can't write a line of SQL or reason about a pipeline, and you'll get someone drawing boxes and arrows that engineers can't actually implement. Hire one who insists on being hands-on with every transformation, and you'll bottleneck the design work your programme actually needs from them.

What should a job spec for an architect role emphasize instead of tool lists?

Emphasize integration judgment and cross-system decision-making over tool proficiency alone. An architect's value shows up in statements like "it's really just carrying on from that... there's a lot of design work... strategically from a data perspective" — the ability to evaluate how Fabric, Synapse, and Data Factory should work together across an entire programme, not just operate each one. Industry background matters less than this judgment: one architect noted they'd worked across insurance, energy, and public sector roles and weren't "fussed" about industry, because "it's data at the end of the day, isn't it? It's the project". Write the spec around decision rights and design ownership, and let the tool list sit underneath that as context, not as the headline requirement.

Scoping the Data Engineer Role

With the architect's remit defined, the engineer brief should look noticeably different in both language and emphasis.

What does hands-on engineering delivery actually involve on an Azure programme?

Data engineering delivery means building, transforming, and operating the pipelines that move and shape data day to day. One engineer described their core responsibility as using "Azure Data Factory for the orchestration, Databricks pipelines for the transformation" of operational data, working hands-on with PySpark and ADLS Gen2 to keep records current and accurate. Another engineer, working on a Fabric data warehouse project, described building "Fabric pipelines... PySpark, Spark SQL" alongside three other engineers to deliver a completed solution that was then handed over to the business. This is execution work with a defined technical scope — not open-ended system design.

How specific should a Data Engineer job spec be about tooling?

Very specific — engineers are evaluated on what they've actually built with each tool, not general familiarity. One Databricks-focused engineer gave a concrete example of transformation logic: tracking livestock movement records by transforming data on "where it was before and where it's moving and from date, to date and where it is currently" using Azure Databricks. Another engineer described their Fabric project in equally concrete terms: delivering "a data warehouse, data cube solution" on the Fabric platform using Fabric pipelines, PySpark, Spark SQL, and Power BI, as part of a team of four. A strong engineer spec asks candidates to describe a specific pipeline or transformation they built — not just which Azure services appear on their CV.

Can one person do both the architecture and the engineering on a smaller programme?

Some professionals do move between the two, but the distinction between design authority and delivery focus still applies even when one person holds both. The architect sources we draw from consistently self-identify as design-first, explicitly stepping back from engineering execution as their career progressed. If your programme is small enough that one person will do both, write the spec to be honest about the split in time and expectation — design decisions in the early phase, hands-on delivery through build — rather than asking for "architect-level strategic thinking" and "engineer-level daily delivery" as if they're the same ask at the same seniority level.

Writing the Job Spec

Getting the distinction right on paper is what prevents mismatched hires later, so the final step is translating it into language your spec can actually use.

What's the single biggest mistake CTOs make when writing these job specs?

The biggest mistake is listing Fabric, Synapse, and Data Factory as a flat skills checklist without specifying whether the role needs design ownership or delivery execution. Both an architect and a data engineer in our source material worked across the same Fabric and Synapse environment — one framed their involvement as building "the solution from the application side" with an architects group, the other framed an almost identical toolset as delivering a completed data cube solution as part of an engineering team. A spec that doesn't separate "defines how the platform should work" from "builds and operates the platform" will attract applicants from both camps, and you'll spend interview time discovering which camp each candidate is actually in.

How should day rate or seniority expectations differ between the two roles?

Architect-level day rates reflect design accountability built over a long career, and engineering rates reflect delivery-focused technical execution — the two shouldn't be benchmarked against the same bracket. One solutions and data architect with roughly 15-20 years of insurance-sector experience quoted a rate expectation of "650 plus" outside IR35. By comparison, data engineers delivering hands-on Fabric, Databricks, and Azure Data Factory work in our source conversations quoted rates in the 350-500 range outside IR35. If your spec blends architect-level responsibilities with an engineer-level day rate, you'll filter out exactly the design-first candidates the role needs.

What should the interview process test for, once the spec is written correctly?

Test for design reasoning with architect candidates and build evidence with engineer candidates — the two require genuinely different conversations. For an architect, that means probing how they'd structure a medallion architecture across Fabric and Synapse for a specific business problem and how they'd hand that off to an engineering team. For an engineer, that means asking for a concrete example of a pipeline they built — the kind of specificity one engineer gave when describing exactly how livestock movement records were transformed using Databricks and PySpark, or how another engineer described leading "end-to-end pipeline creation" across Fabric, Databricks, and Snowflake-equivalent warehouse platforms. If a candidate can't go that specific, the CV keyword match hasn't told you what you need to know.

Getting the Brief Right From the Start

A job spec that conflates strategic design with hands-on engineering doesn't just slow down your shortlist — it produces offers to the wrong person for the programme you're actually running. We work through this distinction with every CTO and Head of Data we partner with before a single candidate conversation happens, because the brief is where role clarity either gets built in or gets lost. If you're scoping an Azure transformation programme and aren't sure whether you need an architect, an engineer, or both in sequence, talk to us before you write the spec — we'll help you work out which one actually moves your programme forward.