“Software architect” is not a single job. It is a family of related roles that specialise by scope, by depth, and by domain.

Someone tells you they are a “software architect” and you learn almost nothing about what their week actually looks like. The title covers at least half a dozen distinct roles, all senior, all technical, all shaped very differently by scope and specialisation. This guide sorts them into a mental map that keeps them straight.

The cleanest analogy is a large hospital. Everyone in the building is a “doctor”, but a cardiologist, a radiologist, and a hospital medical director all spend their days on very different work. Some go deep on one organ system. Others coordinate across every specialism to run the whole institution. Nobody would confuse them — and no patient benefits from pretending they are interchangeable.

The first way architects differ is scope. Three altitudes cover the vast majority of roles: enterprise, solution, technical.

The simplest way to organise the field is by altitude — how far the architect’s attention has to stretch. Three altitudes cover most of what you will run into.

The three are not a ladder — you do not automatically “grow up” from technical through solution to enterprise. Many careers stay firmly at one altitude for decades, and each is a full, respected specialism in its own right.

Alongside the three altitudes sit the domain specialists — architects who go deep on one cross-cutting concern that spans many systems.

Alongside the altitude-based roles, most large organisations also have domain specialists — architects who go extremely deep on one specific concern that cuts across the whole landscape rather than living inside one system.

These specialisations are usually orthogonal to altitude — you can be a solution architect who happens to specialise in security, or a technical architect who happens to specialise in data. The two dimensions multiply rather than replace each other.

The types are not isolated silos. They interlock in a fairly consistent shape across most organisations.

Drawn out, the roles form a fairly consistent shape across most organisations: the three altitudes stack on top of each other, and the domain specialists sit alongside, supporting everyone.

Read that as a scope relationship, not a management one. Enterprise architects rarely manage solution architects directly, and solution architects rarely manage technical architects. What flows down the picture is constraints: the enterprise architect sets the boundaries the solution architect designs within; the solution architect sets the boundaries the technical architect designs within; and the domain specialists supply expertise anywhere along the way.

The mental model most experienced architects match is a “T”: broad horizontal knowledge, plus one vertical bar of real depth.

Effective architects almost universally exhibit what recruiters call a T-shape — broad knowledge across many technologies and concerns (the horizontal bar), combined with one area of genuine, credible depth (the vertical bar).

The horizontal bar is what lets an architect reason across systems, negotiate between teams, and route decisions to the right specialist. The vertical bar is what keeps them credible — without it, they slide into being a “big-diagram person” whose recommendations the deep experts quietly ignore. Different types of architects have different vertical bars — cloud for a cloud architect, data for a data architect, one specific stack for many technical architects — but almost every strong architect has one.

Beyond the titles, four working personalities show up repeatedly in the field — each with its own strengths and its own failure modes.

Titles describe scope; personalities describe how someone actually shows up to the work. Four archetypes appear over and over across all the types above.

Most real architects blend two of these on their best days and hit the failure mode of a third on their worst. Recognising the mix early — in yourself or a colleague — is often the biggest lever for improving how a team of architects works together.

A quick side-by-side to make the difference feel concrete rather than abstract.

Two Tuesdays, side by side. Same title on paper — very different jobs in practice.

Both are senior. Both make the systems they touch demonstrably better. Neither could easily do the other’s day.

A rough guide to which architect a project actually needs — and when it needs more than one.

A useful reflex: before you decide to add “an architect” to a project, decide which kind. Different types are appropriate for different signals.

Large, cross-cutting programmes almost always need more than one type at the same time — a solution architect to shape the whole, a technical architect per major system, and a domain specialist or two on the parts that carry the biggest risk.

A common technical base underneath, with each type stretching in a different direction on top of it.

Every type shares a common foundation — solid engineering roots, comfort with distributed systems, and the judgement to make trade-offs. On top of that base, each type stretches in a different direction.

Most careers touch more than one type. Here are the common moves — and the common traps.

Careers rarely land on one type and stay put for forty years. Some transitions are common and natural; others are surprisingly hard.

Three misconceptions that keep resurfacing whenever architect titles get discussed — and the reality behind each.

“There is only one real kind of software architect.”

Almost every conversation that starts this way ends with someone accidentally describing whichever type they personally happen to be. There are at least six recognisable types in most large orgs, plus emerging ones like AI/ML architect. Insisting on only one flattens a whole discipline.

“A domain specialist is less senior than a solution or enterprise architect.”

Not at all — different axis of seniority. A principal security architect is not junior to a solution architect; they are equally senior on a different axis. Confusing depth for lack of scope is a common recruiting mistake.

“Small teams do not need to think about any of this.”

They do not need dedicated architects, but they still make architectural decisions all the time. Understanding which type of decision is in front of them — system-level, solution-level, cross-cutting — helps them route it to the right person, even if that person is wearing three other hats.

The five ideas from this guide worth carrying into any conversation about architect roles — whether you are hiring, being hired, or staffing a project.