When someone asks me, "So, what kind of architect are you?", I still hesitate.
My CV says Solution Architect. My day-to-day work cuts across integration, data, cloud and a bit of enterprise architecture. On LinkedIn, I see roles that look exactly like mine titled Platform Architect, Technology Architect, Domain Architect, "Data Software Solution Architect", and a dozen other variations.
If I'm confused about which architect I really am, what chance does a recruiter or a junior engineer have?
Over the past few weeks, I started digging into this problem thinking it was just my personal frustration. The more I looked, the more I realised: this isn't just me. The architecture profession has a job-title problem.
The architect title soup
The word "architect" has become the Lego block of tech job titles. We stick it in front of or behind anything.
You'll find people doing very similar work advertised as:
- Software Architect, Application Architect, Technology Architect
- Solution Architect, Platform Architect, Integration Architect
- Data Architect, Cloud Architect, Security Architect
- Enterprise Architect, Domain Architect, Business Architect
Then there are the stacked, buzzword-heavy hybrids: "Data Software Solution Architect", "Cloud Integration Architect", "AI Platform Architect", "Customer Journey Architect".
Sometimes these labels represent genuine differences in scope and responsibility. Often, they don't. A Solution Architect in one organisation might be doing what another firm calls a Platform Architect or even a Principal Engineer with an architecture focus.
When the same work is hiding behind five different titles, everyone loses signal:
- Candidates don't know whether they're over- or under-shooting a role.
- Recruiters struggle to compare profiles because every CV uses a different vocabulary.
- Hiring managers waste cycles explaining the real job behind the title.
If architects themselves can't map these titles cleanly, we shouldn't be surprised that the market looks messy.
Why this mess exists (and it's not just LinkedIn)
It's tempting to blame LinkedIn for all of this. Yes, it amplifies the problem, but it didn't create it.
Under the surface, there are a few deeper issues at play.
1. No real job architecture
Many organisations still don't have a proper job architecture – a structured backbone of job families, levels and responsibilities. Instead, titles evolve organically:
- One manager wants to keep a strong engineer, so they create a "Lead X Architect" role.
- Another business unit uses "Platform Architect" because it sounds more modern than Solution Architect.
- A third team invents "SIAM Architect" or "Vendor Product Architect" to match a specific initiative.
Over time, you end up with twenty flavours of architect on the org chart and no clear relationship between them.
2. Title inflation and signalling
"Architect" has become a status symbol. It signals seniority, influence, and (often) a certain billing rate. That leads to:
- Engineers being re-titled as architects as a reward, without changing their scope.
- Ever more elaborate add-ons: Senior, Principal, Lead, Chief, Global, Regional.
- Once anyone can be an architect, the title stops meaning anything.
3. Keyword and SEO gaming
On job boards and LinkedIn, titles are search inputs. To make a role discoverable, companies and agencies cram them with keywords:
"Senior Cloud Data & AI Solution Architect – Financial Services – Customer Journey".
This might help search algorithms, but it destroys clarity for humans.
4. Specialisation overload
The tech landscape keeps adding new slices of architecture: cloud, data, security, AI, platform, integration, product. Each one spawns its own tribe and title flavour.
Instead of designing a coherent role framework, we keep creating micro-titles. That's how we end up with job ads that read like a word salad.
LinkedIn is the mirror and megaphone for all this, but the root cause sits in how organisations design roles and how the recruitment ecosystem is incentivised.
What a healthy architecture spine could look like
Ranting about the problem is easy. Fixing it requires a simpler, more disciplined model.
If you look at established frameworks and modern job architecture work, a pattern emerges: they don't try to name every variant; they define a small, stable backbone of roles and then attach skills and domains around it.
For architecture, a pragmatic "spine" might look like this (simplified):
- Software / Application Architect
- Solution Architect
- Domain / Platform Architect
- Enterprise Architect
- Head of Architecture / Chief Architect
Then, instead of inventing a new job title for every context, we use tags and skills:
Tags: Data, Security, Integration, Cloud, AI, Network, Customer. Skills: architecture styles, governance, stakeholder management, design techniques, strategy.
So instead of: "Senior Cloud Data Software Solution Architect – Customer Domain"
You have:
- Title: Solution Architect
- Level: Senior
- Tags: Cloud, Data, Customer
- Scope: Payments domain in Retail Banking
The external title stays readable and comparable. The internal metadata does the heavy lifting.
A structured job architecture like this gives HR and leadership a clear map of role families, levels, and relationships – and it's already proven to improve workforce planning and consistency.
Who actually benefits from cleaning this up?
This isn't just theoretical neatness. Clear architecture roles create tangible benefits for both organisations and individuals.
For organisations
Better hiring and workforce planning: Standardised titles and levels make it easier to compare candidates, avoid duplicate roles, and plan capacity in a structured way.
Stronger internal mobility and retention: When people understand where they are on the ladder and what sits above/beside them, they can plan their own moves instead of waiting for random opportunities.
Less misalignment and rework: Clear expectations around scope (solution vs domain vs enterprise) reduce the "you hired a solution architect but expect an enterprise strategist" mismatch.
For architects and job seekers
More confidence when applying: If titles map to broadly accepted meanings, you waste less time second-guessing whether you're overshooting or selling yourself short.
Cleaner career stories: It becomes easier to explain your path as a sequence of roles within a known spine, even if different companies used slightly different labels.
Better conversations with recruiters: Instead of debating titles, you can focus on scope, accountability, and the problems you're being asked to solve – which is what really matters.
From my own experience, simply aligning a job description with the real responsibilities – and removing title noise – dramatically improved the quality and hit-rate of candidates.
That's exactly what job architecture research is finding at scale.
A picture of the mess (and the alternative)
To make this real, imagine a simple visual:
Left side – "Today's Architecture Job Titles" A messy cluster of overlapping rectangles with labels like: Solution Architect, Software Architect, Platform Architect, Technology Architect, Enterprise Architect, Data Architect, Cloud Architect, AI Architect, Integration Architect, "Data Software Solution Architect", "Customer Journey Architect".
Lines connecting them in all directions, making it hard to see any structure.
Right side – "A Clear Architecture Spine" A vertical ladder of 5–6 clean boxes: Software/Application Architect → Solution Architect → Domain/Platform Architect → Enterprise Architect → Head of Architecture.
Next to it, small tag bubbles: Data, Cloud, Security, Integration, AI – that can attach to any rung.
One side represents how it feels to browse architecture roles today.
The other side represents what it could look like if we applied the same discipline to role design that we apply to system design.
So, which architect am I?
After all this, I'm still a Solution Architect on paper.
In practice, I operate across solution and domain architecture, with a strong integration and cloud flavour, and an increasing focus on AI-assisted governance.
Maybe that's the point.
Instead of endlessly multiplying titles, we should:
- Agree on a small, shared architecture spine.
- Be explicit about scope and skills.
- Use tags and competencies to capture nuance rather than turning every nuance into a new job title.
If we can draw clean architectures for complex systems, we should be able to draw a cleaner architecture for our own roles too.