What is a Solutions Architect (and how can you become one)?

Last Updated on 2026-06-14 by James Croft

If you search “solutions architect” you get two extremes. On one side, a glossy job description with no recognisable activity. On the other, a Reddit thread arguing that the title means nothing because every company defines it differently. Both are partly right, and that is exactly why it is so hard to plan a career around.

I spent a good chunk of my career in and around the solutions architect role, though I am no longer in it. I now work at Microsoft on platform engineering, ARM64 migration at scale, and agentic AI systems. The shift was deliberate, and the perspective I now have on the role is more useful than the one I had while I was inside it. So this article is a rewrite of one I published in 2022, when I was still mid-role. It keeps the practical guidance, and tells you what the role actually looks like from someone who is on the other side of it.

If you take one thing from this piece, take this: solutions architect is less a job and more a way of thinking.

What a solutions architect actually does

The job title sounds grander than the job. Strip away the glamour and a solutions architect does four things, repeated in a loop.

They translate. A business owner says “we need to reduce churn”. An engineering team hears “we need a feature flag system, an experimentation pipeline, and a data warehouse rebuild”. The architect is the person who turns the first sentence into a clear, fundable, buildable set of decisions, without losing the original intent.

They decide. Every non-trivial system has fifty design choices, and most of them are not technically interesting. Do we run this on Container Apps or Kubernetes? Do we build for one region or two? An architect makes the calls that the team needs in order to move, in a way the team can live with afterwards.

They design. They produce the artefacts other people use to act: a high-level system diagram, a sequence of events, a phased delivery plan, a list of risks, an opinion on what to build first. The deliverables matter less than the clarity behind them.

They oversee. They stay close enough to delivery to notice when the plan and the reality have started to diverge, and they help the team adjust without losing the thread.

That is the role. Notice what is not in that list: writing code full time, owning a team’s calendar, running the backlog, approving every PR. Architects who try to do all of that as well usually become the bottleneck their own design was supposed to remove.

How the role has changed

When I wrote the original version of this article, “cloud-native” was still a deliberate choice. Most architects spent a chunk of their week deciding which compute was best for their use case. That has flipped. In 2026 the defaults have moved.

• Cloud-native is the baseline, not the goal. Managed platforms, infrastructure as code, and observability by default are now assumed. If your design starts with “should this be a VM?”, you are already behind. The interesting decisions live further up the stack: identity, data flow, multi-region resilience, cost.
• Architects own delivery readiness, not just designs. A diagram that cannot be deployed safely on a Tuesday afternoon is not a design, it is a wish. The architect’s work now includes the deployment story, the rollback story, the on-call story, and the cost story. The Azure Well-Architected Framework is the single most useful reference I would keep open in a browser tab.
• AI is now part of the spec. Almost every system I look at now has an AI surface somewhere: a copilot in the UI or an agents in the workflow. Architects need a working mental model of how models behave under load, how to ground them in real data, and where they break.
• Platform thinking has eaten “central architecture”. The most effective architects I work with now do not produce monolithic reference architectures and hand them down. They build platforms, tools, and paths that make the right decision the easy decision. The output is leverage, not paperwork.
• Agentic systems are a new architectural standard. Designing a multi-agent system is closer to designing a distributed system with unreliable workers than it is to designing a chatbot. Boundaries, contracts, retries, observability. The architecture muscles transfer, but you have to apply them deliberately. I have written more on this in Applying Domain-Driven Design Principles to Multi-Agent AI Systems.

The role has not become easier. The work that used to fill the week, picking technologies and drawing boxes, is now table stakes. The interesting work is further out: making decisions that compound, building leverage for other teams, and keeping AI-shaped systems honest.

What I actually did, in plain language

To make this less abstract, here is roughly what a week looked like when I was in the role. Yours will be different, but the shape will be similar.

• One or two stakeholder conversations, usually with someone non-technical, trying to understand the actual problem behind the requested solution. Most “we need an app” requests are really “we have a process that nobody owns”.
• A whiteboard session with the engineering team, sketching options. The point was never to land the final design in the room. The point was to surface the assumptions that would otherwise show up six weeks later as a production incident.
• Writing up architecture decisions, often a page or less in a team wiki. What we are going to do, why, what we considered, and what we are explicitly not doing. These age better than any diagram, and today, become great context for coding agents.
• A small proof-of-concept, hands-on, to validate the assumption that worried me most. If I could not get the risky piece working in a couple of days, the design was not yet real.
• Reviews of work in flight: PRs, deployment changes, monitoring dashboards. Not to approve everything, but to keep my mental model of the system aligned with what was actually being built.
• Documentation and diagrams that other people could use without me in the room. If the design only lives in my head, the design does not really exist.

Most weeks were that, in different proportions. The bad weeks were the ones where I drifted too far from delivery and started designing things the team had no way to build

Three books that still shape my thinking

There is one small series I keep coming back to, and it earns an honest mention because it shaped how I do the translate-decide-design loop. All three are from Strategyzer, and I originally read them in order: Business Model Generation, Value Proposition Design, and Testing Business Ideas. Today, I use them mostly as reference guides if I need a refresher, but I do use them.

Business Model Generation broke the “tech first” reflex for me. It gave me a one-page canvas for understanding businesses, who it serves, and what it depends on. The first few times I sat in a stakeholder workshop with the canvas, I noticed I was asking better questions almost by accident. It is the book I would hand to any engineer who is about to step into their first architect role.

Value Proposition Design is the deeper cut of the same idea. It zooms in on the moment a solution actually meets the customer, and gives you a vocabulary for separating what people say they want from what would actually make their day better. It is the book that changed the “we need an app” conversations, because it gave me a way to redirect them without sounding obstructive.

Testing Business Ideas is the one I still use the most, even at Microsoft. It is essentially a design guide for cheap experiments that you can run to validate or kill an idea before you commit budget to building it. That sounds product-y, but it is exactly the muscle an architect needs: identify the assumption in the design that is most expensive to be wrong about, and find the smallest possible test that would tell you. I leaned heavily on this thinking when I wrote Hypothesis-Driven AI Innovation: A Framework for Building Bold Ideas, which is what happens when you point the Strategyzer mindset at the way AI projects fail.

I am not pitching these as required reading. If you are a technical person trying to grow into the architect mindset, they give you a structured way to think about the parts of the job that engineering training does not cover. None of them are about technology. All of them are about how to be useful to the people whose problem you are trying to solve.

The technical track into the role

There is no single path, but there is a recognizable shape. The shape, in the order I took:

1. Software engineer. Ship things. Break things. Fix things. Learn what production actually feels like. If I’m honest, without it, every architectural opinion you form will be theoretical. You need experience on the ground.
2. Senior engineer. Own a non-trivial slice of a system end to end. Make decisions other engineers rely on. Start noticing when the system shape, not the code, is the real problem.
3. Tech lead. This is where the mindset shift happens. Your job stops being “produce the most code” and starts being “make the team’s code possible”. I wrote about this in Lessons Learned from Being a Tech Lead, and almost every line of that article still applies. The hardest part is letting go.
4. A stretch role that is not just engineering. For me it was a stint doing business analysis and project management. For others it is a product engineering role, or owning a customer relationship, or leading a discovery phase. The point is to leave the pure-engineering bubble for long enough to feel how business decisions are actually made.
5. Solution lead, then solutions architect. By the time you get here, the title is a recognition of how you are already working, not a promotion into a new way of working.

Two things matter more than the title sequence:

• Stay hands-on. The architects I trust most still build things. Not full-time, but often enough, usually hobby or open-source projects. I know from experience going too far in one direction, if your last meaningful pull request was a year ago, your architecture will show it.
• Practice translating both directions. Engineers to executives, and executives to engineers. The architect’s value is in the translation layer. Lean into the conversations that feel uncomfortable. The discomfort is the skill being built.

A wider reflection on this kind of growth, including learning, opportunity-seeking, and sharing your work, lives in Growing Your Career Towards Technical Leadership. That piece is the companion to this one. If you are also leading a team alongside the architecture work, How to Build a Successful Development Team covers the team side of the equation.

A practical example of architectural decision-making

Here is a small example that captures the shape of the work, drawn from a real engagement.

A customer asked for “a real-time dashboard” on top of a transactional system. The instinctive engineering answer was a streaming pipeline, an analytics database, a websocket layer to the frontend, and a refresh strategy. Fundable, buildable, technically interesting.

The architectural question was different. How real-time is real-time? It turned out the business needed numbers that were no more than fifteen minutes stale, refreshed when a user opened the page. The technical answer collapsed to a scheduled query, a cached projection, and a polling endpoint. We delivered in days, and the team did not have to take on a streaming platform they did not yet have the operational maturity to run.

The point is not that simple wins. The point is that the architect’s job is to ask the question that changes the shape of the answer. If the architect had let the first technical reading stand, the team would have spent significant time solving the wrong problem beautifully.

Common mistakes that I made as a solutions architect

These are the patterns I saw most often in my younger self.

Chasing the title

The biggest trap is treating “solutions architect” as a destination. If it’s really what you want, the title can arrive faster than the capability if you optimize for it directly, and the gap shows up in the first hard project you take on. Optimize for the capability.

Going hands-off too early

Once you become an architect, it is genuinely tempting to stop building. You do not need to write production code every day, but you need to write enough to keep your judgement calibrated. PoCs, internal tooling, spikes. Otherwise your designs become subtly disconnected from the cost of building them.

Designing in diagrams (only)

A diagram is not a design. A design is a diagram, a set of decisions, a list of risks, and a credible delivery story. If you only produce the picture, you are basically handing the team the easiest 10% of the work.

Ignoring delivery and operations

The classic architect failure mode is to land an elegant design and then disappear. The system that emerges six months later barely resembles the diagram, because nobody owned the gap between design and delivery. The fix is to stay close enough to spot the drift and adjust the design while it is still cheap to change.

Summary

If you remember nothing else:

• Solutions architect is a way of thinking. The skills compound regardless of the title, and you’ll find the skills extremely useful, no matter where you take your career next.
• The job is translate, decide, design, oversee, in a loop. Anyone who tries to do all of engineering and architecture at once becomes their own bottleneck.
• The bar has moved. Cloud-native is the baseline. AI and agentic systems are becoming a necessity. Platform thinking has replaced central-architecture handovers.
• Stay hands-on and stay close to delivery. The architects who lose those two habits stop being useful.
• The path is shape, not sequence. Engineer, senior, lead, a stretch role outside pure engineering, then architect. The order matters less than the experiences.

If you are working towards the role from a technical background, do not wait for someone to give you the title. Start operating like an architect on the work you already have. Ask the question that changes the shape of the answer. Write the specification for a new feature. Build the small thing that proves a risky assumption. Translate between the people who hold the problem and the people who hold the keyboards.

Do that consistently, and the title becomes a formality.