The word “architect” is overloaded to the point of near-meaninglessness.

In ancient Rome, Vitruvius defined architecture through three principles: firmitas (strength), utilitas (usefulness), and venustas (beauty). A building must be structurally sound, serve its purpose, and be aesthetically pleasing. All three, not any one.

Software architects, in theory, apply the same thinking: systems must be technically sound, serve business needs, and be elegant (or at least maintainable). The role requires deep technical knowledge combined with broad contextual awareness — business, organisational, operational.

In practice, the role has been stretched into shapes that bear little resemblance to this.

Part 1: Where the Term Comes From

The “software architect” title emerged in the 1990s as software systems grew complex enough to require dedicated people thinking about structure, interfaces, and technical direction beyond what individual teams could do.

The classic architect role:

  • Sets technical direction and architectural standards
  • Makes key design decisions with long-term implications
  • Identifies and manages technical risk
  • Connects technical decisions to business outcomes
  • Enables other teams to build well

This requires a specific and rare combination: deep technical ability, systems thinking, communication skills, and enough organisational awareness to understand what tradeoffs actually matter.

The problem is that this rare combination is being applied to many roles that don’t actually fit it.

Part 2: Three Case Studies in Architect Role Misuse

Case Study 1: “Partnering with Customers”

At several large technology vendors (cloud providers, platform companies), the “Solutions Architect” role carries a quota.

The job is not to design solutions. The job is to convince potential customers to buy the platform. The architect does technical demos, answers RFPs, writes proof-of-concept code, and serves as a trusted technical voice in the sales process.

This is a sales engineering role. It requires different skills, different incentives, and a different performance model than an architecture role. The person in this role is optimised for closing deals, not for sound technical decision-making.

Calling it “Solutions Architect” serves the vendor because it sounds technical and trustworthy. But the customer should understand what incentives are driving the advice they receive.

This isn’t a criticism of the people in these roles — it’s a valuable function. But it’s not architecture. The mislabelling creates confusion.

Case Study 2: Product Owner / Business Analyst Creep

In many product organisations, the most technically literate Product Owners and Business Analysts get promoted or rebranded into “Solution Architect” roles.

The pattern goes like this: a PO who can read API docs, attend technical refinement sessions, and write semi-coherent Jira acceptance criteria gets recognised as “technical”. At some point, they’re re-titled.

The resulting role is essentially a technical PO or senior BA — someone who bridges business requirements and technical implementation. This is genuinely valuable, but it is not architecture.

Architects in this mould often lack:

  • Hands-on experience designing systems under real constraints
  • Deep understanding of failure modes and non-functional concerns
  • The authority to say “no, this design is wrong” when the product owner wants something
  • Any experience operating what they design

The resulting “architecture” is often product requirements dressed up in technical language — a Confluence diagram that says “the system will do X” without any serious engagement with how.

Case Study 3: Architect Per Feature Team

In a scaling engineering organisation, there’s pressure to embed architects everywhere. Every feature team gets an architect. Every domain gets a domain architect.

The problem: the work available to an architect embedded in a feature team is, by definition, feature-team-level work. The team’s architectural concerns are scoped to their service, their API, their database schema.

This work may be important, but it’s not architecture in the sense of setting direction, managing cross-cutting concerns, or making decisions with long-term systemic implications. It’s detailed technical design — which engineers on the team can and should do.

Architects embedded in feature teams tend to drift into:

  • Being a senior engineer who does more design and less coding
  • Being a bottleneck for technical decisions that the team should own
  • Losing visibility of the broader architectural concerns that only they can see

Meanwhile, the org has consumed its architecture capacity on feature-level concerns and has no bandwidth for real architectural work.

Part 3: Why This Happens

These patterns aren’t random. They emerge from specific pressures:

Hypergrowth scaling: When a company doubles headcount in 18 months, processes and role definitions can’t keep up. Titles get applied loosely. People get promoted faster than their scope can grow. Architecture is a function that scales poorly — you can’t just double the architect headcount and get double the architectural output.

Title inflation: “Engineer” sounds less impressive than “Architect” to clients, to candidates, to organisational charts. There’s pressure to upgrade titles even when the scope doesn’t change.

Filling gaps: When a team lacks a strong technical senior engineer, attaching an “architect” to the team feels like a fix. Often it is — but it’s treating a symptom (weak team capability) rather than the cause.

What Actually Scales

Architecture capacity doesn’t scale linearly with headcount. You probably need fewer architects than you think.

What you do need:

  • Architects with genuine scope — cross-cutting concerns, platform decisions, long-horizon thinking
  • Engineers who can do local technical design well (don’t call them architects, train them as engineers)
  • Clear interfaces between architectural decisions (set by architects) and implementation decisions (owned by teams)
  • An architecture function that’s connected to both technical reality and business strategy

The firms that do this well tend to have senior architects operating across multiple teams, setting direction, and deliberately transferring knowledge and decision-making authority to engineering teams as they mature. The architect’s job is to work themselves out of the loop on decisions that teams can handle — and to focus on the decisions that genuinely require their scope.

That’s a harder job than being embedded in a feature team. It’s less visible on a short timescale. But it’s the job.

Written from experience as an Engineering and Architecture leadership consultant. The patterns described are composites of situations I’ve observed across multiple large organisations; no single organisation is described here.