What a Solution Architect Actually Does

A solution architect is the person accountable for turning a business problem into a technical solution that actually fits, technically sound, affordable, and buildable by the team that has to build it. It is one of the higher-paying paths in technology, and unusually, it rewards judgment more than raw coding.

The reason the role exists is a recurring failure. Business leaders describe what they want in the language of outcomes ("we need customers to self-serve returns"). Engineers work in the language of systems (databases, queues, APIs). Left unbridged, that gap produces predictable disasters: technically impressive systems that solve the wrong problem, or business plans that assume things no system can deliver on time or budget.

The solution architect stands in that gap on purpose. They understand the business well enough to know what actually matters, and technology well enough to know what is possible and what it will cost, and they own the translation between them.

This cursus builds the discipline in three parts:

• This lesson: what the role is, and what it is not.
• Lesson 2: requirements, especially the non-functional ones that quietly decide the architecture.
• Lesson 3: trade-offs, decisions, documentation, and how to break in.

Start with the role itself, because the most common misunderstanding, that a solution architect is just a senior developer, hides what the job is really about.

"Architect" is overloaded, and job listings blur it. Three distinct roles exist, and they operate at different altitudes. The clearest framing comes from enterprise-architecture practice, including the TOGAF framework from The Open Group.

• Enterprise architect. The highest altitude, and the most strategic. They design the organization's overall technology landscape and standards, aligning the whole IT estate with business strategy across many systems and years. In TOGAF terms, they own the architecture vision and identify opportunities across the enterprise.
• Solution architect. The middle, and the subject of this cursus. They operate tactically, designing the solution for a specific business problem or initiative, bridging that problem to an implementable system that is scalable, reliable, and secure. In TOGAF terms, they define the solution and plan the transition from today's state to the target.
• Technical architect. The lowest altitude, deepest in one area. They own the detailed design within a specific technology, a cloud platform, a data tier, a particular stack, making sure that piece is built correctly.

The altitudes stack: the enterprise architect sets direction across everything, the solution architect designs one coherent solution within that direction, and the technical architect drives depth in one part of it.

For a career switcher this matters practically. "Solution architect" is the role most people mean, and the most common entry point into architecture, because it is defined by a bounded problem rather than by owning the entire enterprise or mastering one stack to the exclusion of the rest.

The core of the role is one word: fit. A solution architect is not judged on whether the design is clever, modern, or elegant. They are judged on whether it fits, the problem, the business, the budget, the timeline, the team's skills, and the systems already in place.

This reframes everything. The best architecture on paper is worthless if the team cannot build it, the company cannot afford it, or it does not connect to the systems that already run the business. A dull solution that ships and works beats a beautiful one that does not.

Concretely, a solution architect holds several things in balance at once:

• The problem. What is actually being solved, beneath how it was first phrased.
• The constraints. Budget, deadline, existing systems, regulations, the team's capabilities.
• The options. Build or buy, this technology or that, this pattern or that, each with different consequences.
• The trade-offs. Because there is never a free choice. More of one quality costs another (Lesson 3).

And then they produce the load-bearing output: a design plus the reasoning for it, communicated so that executives trust it and engineers can build it.

Notice what is not on that list: writing most of the code. Architects often can code and often did, but the job is deciding what to build and why, then guiding the people who build it. That is why the role rewards experience and judgment, and why it pays what it does. You are being paid for the expensive mistakes you prevent.

Like the product and project roles it sits near, a solution architect usually has responsibility without command. They are accountable for the solution, but the engineers building it typically do not report to them, and the executives funding it outrank them. So influence, not authority, is the working currency.

That makes a specific set of skills the real core of the job:

• Translation, in both directions. Explain to executives, in business terms, why a technical constraint matters ("real-time inventory means we cannot use that cheaper batch system"), and explain to engineers, in technical terms, what the business actually needs. Much of the role is being fluently bilingual.
• Communication and documentation. An architecture that lives only in one person's head is a liability. The architect must make the design and its reasoning legible to very different audiences (the subject of Lesson 3).
• Stakeholder management. Different groups want different, conflicting things, cheaper, faster, more secure, more flexible. The architect surfaces those conflicts and drives them to a decision everyone can live with.
• Persuasion through evidence. Since they cannot command, they must convince, with analysis and clear trade-offs rather than title.

This is why strong communicators with technical depth thrive as architects, and why the role is genuinely hard to fill: it needs someone technical enough to be right and articulate enough to be believed. A brilliant design nobody adopts changes nothing.

Make it concrete. A retailer wants to "let customers track orders in real time." Watch a solution architect work the gap rather than jump to a design.

1. Interrogate the problem. What does "real time" mean, to the second, or within a few minutes? Who needs it, customers, support, or both? The answer changes the entire architecture, and the business rarely stated it. Suppose "within a couple of minutes" is genuinely enough.
2. Map the constraints. There is an existing order system that updates in batches every 15 minutes. There is a fixed budget and a holiday deadline. The team knows one cloud platform well and another not at all.
3. Generate options. Rip out and replace the batch system (accurate, expensive, slow to deliver). Add an event stream so updates flow as they happen (moderate cost, fits the timeline). Or a lightweight polling layer over the existing system (cheap, less elegant, possibly good enough).
4. Weigh trade-offs against what fits. The full replacement misses the deadline and blows the budget. The polling layer meets "within a couple of minutes" for a fraction of the cost and uses the platform the team already knows.
5. Recommend, with reasoning, and document it. Choose the fit, and record why, so that when someone later asks "why didn't we do real-time properly?", the answer, and the business constraint behind it, is on record.

Notice the shape. The architect spent most of their effort understanding and deciding, not designing, and almost none writing code. The value was choosing the option that fit, and being able to defend it.

Pull it together, and separate the myths from the reality.

A solution architect's week is discovery conversations, drawing and revising designs, weighing options, writing up decisions, aligning stakeholders, and guiding engineers, with fit as the constant question.

For a career switcher, the path is unusually clear because it is mostly vertical. Solution architects typically grow out of engineering: a senior developer or tech lead who has seen enough systems to reason about them at a higher level, and who has deliberately built the business and communication skills the role demands. So the route is:

• Build technical breadth, not just depth. Architects reason across databases, integration, cloud, and security, so a wide exposure matters more than mastery of one stack.
• Practice the translation. Get close to the business, sit in on requirements, and learn to explain technical trade-offs to non-technical people.
• Document decisions, not just code. The skill of writing why is the architect's core deliverable, and you can practice it in any engineering role today.

The rest of the cursus builds the two hardest of those skills: understanding what a solution truly needs (Lesson 2) and choosing well among options (Lesson 3).

The solution architect stands between business stakeholders who speak in outcomes and an engineering team that speaks in systems, translating a problem and its constraints into a design plus reasoning that fits, and sitting below the enterprise architect's direction and above the technical architect's depth.