Solution architecture vs software architecture is a question of focus, not hierarchy. Software architects stay close to code, quality gates and team evolution; solution architects connect many applications, third-party services and cloud platforms to deliver measurable business value. Both roles exist, and both can be done under different job titles.
Solution architecture vs software architecture: what really changes
Solution architecture vs software architecture is a difference of scope, not of rank. A software architect owns the internal structure of an application and how the team builds it; a solution architect owns how that application connects to other systems, third-party services and cloud platforms to produce a business result.
In the talk, Albert Tanure, a Cloud Solution Architect at Microsoft and a former Microsoft MVP for seven consecutive years, draws the boundary clearly. Software architecture covers layers, integration between components, branch strategy, code review, quality gates and onboarding. Solution architecture sits above it, taking that software and wiring it to external products, managed services and other software it does not control.
The distinction matters because the two roles look at different failure modes. A software architect asks whether the deploy process drains traffic during a release. A solution architect asks what happens to a sale when a third-party payment gateway is down on a peak shopping day, and whether the contract allows a multi-region standby.
Job titles do not settle the question. Mercado Livre, cited in the conversation as an example, runs Tech Lead and Tech Expert roles instead of a formal software architect title, and those people still make architectural decisions for their teams. The name changes; the work of looking beyond one service does not disappear.
The same confusion appears in the career ladder. At Microsoft, Albert moved from developer work through several architecture roles before landing in the Cloud Solution Architect seat, and the CSA abbreviation alone is a good illustration of why he asks people to spell out acronyms when they speak.
The five pillars a solution architect uses to judge a design
Five pillars structure the critique of any design: communication, functional and non-functional requirements, cost optimization, security and compliance, and resilience with disaster recovery. Each pillar generates its own metrics and its own execution strategy.
Communication comes first because the architect's output is mostly a diagram, an email or a whiteboard session. Making the design understandable to a client who does not write code is part of the deliverable, not a courtesy. Requirements then split into what the user sees, such as product search or checkout, and what the user never notices, such as global content distribution or cache invalidation.
Cost optimization turns architecture into arithmetic. A container manifest line that sets a memory or CPU request can decide whether a workload costs a small amount or an order of magnitude more, and multi-region duplication can double a monthly bill before any traffic arrives. Security separates external threats from internal ones, because both exist and compliance frameworks such as ISO 27001 and SOC 2 ask about both. In the cloud, the largest companies are the ones under constant attack, so security stops being a specialist concern.
Resilience and disaster recovery are the pillars most often postponed. A disaster is not only a data center outage; it can be a malformed deploy that stops payment processing. The useful question is what the system does when a dependency is switched off, and whether the failure produces a log that identifies the cause. The pillars work together: resilience and cost pull in opposite directions, and the architect has to show the client both numbers before a decision is made.
How a software architect works with code, testing and mentoring
A software architect stays close to code without making coding the primary job. Tanure describes continuing to code, test and touch the tooling he recommends, so that he can discuss and receive feedback instead of handing down decisions from a distance.
The transcript describes several working habits that separate an effective software architect from a diagram-only role. They include running a joint session with the team before the architecture is frozen, revisiting the design regularly with the people who actually operate it, and using code review as a teaching mechanism for every experience level.
Code review is treated as the lever that spreads standards. In the described practice, juniors through seniors all participate, and the architect reviews as one participant among many, which exposes the team to conventions instead of concentrating knowledge in one person. The stated goal is that the developer who writes a method today becomes a senior or architect working alongside the team later.
Processes around the code matter as much as the code. Branch strategy, pipeline stages, conventional commits and semantic versioning fail quietly when nobody reinforces the convention, which is how a breaking change reaches a shared API. Architecture here becomes continuous work on team flow and feedback, not a document produced once.
The architect's schedule follows the same split. Some weeks are spent writing, testing and pairing on the tooling the team depends on; other weeks are consumed by design reviews, roadmaps and dependency conversations. Both halves are the job, and dropping either one weakens the other.
The Labirynth View: roles, titles and the architect's real value
The architect's value is perspective, not superior coding skill. The metaphor used in the conversation is a labyrinth: developers walk the corridors solving the problem in front of them, while the architect stands above the walls and points to the next corridor.
That perspective depends on listening. A developer may be technically stronger than the architect and still be unable to see the political friction between two business areas, the budget constraint, or the contract Claude that blocks a design. The architect absorbs those constraints so the team can do focused work.
The transcript gives a concrete example of that friction: marketing and finance sharing one part of the same system, each describing the requirement differently, and development stalling until someone mapped the disagreement between the two areas. That was not a code problem, and no amount of refactoring would have solved it.
Titles vary widely across companies, so comparing them directly can mislead. In the transcript, an enterprise architect role ended up running code discussions with a team because the organization did not understand the strategic role, and the architect's response was to form software architects inside the teams instead of forcing the title to do work nobody had defined. That is why the title matters less than where the person actually operates in the labyrinth, as shown below.
| Role | Primary focus | Typical day |
|---|---|---|
| Developer | Deliver features inside one service | Code, tests, review, deploy |
| Software architect | Internal structure and team process | Layers, quality gates, mentoring, code review |
| Solution architect | Connections between systems and platforms | Client requirements, cost, compliance, integration |
| Enterprise architect | Company-wide technology strategy | Roadmaps, contracts, conversations with C-level |
The table is a rough map, not a ladder. On the market today the same person can hold a software architect title at one company and a Tech Expert title at another while performing nearly identical work.
Why a cloud migration is a business decision before it is technical
A cloud migration starts with the client's numbers, not with the target platform. The first question in the described process is total cost of ownership: what the data center, electricity, staff and buildings already cost, and what the client actually needs from the move.
Technical reality constrains the plan. A team used to managing virtual machines with VMware and PowerShell does not automatically become a container platform team, so a proposal to adopt Azure Kubernetes Service needs to account for image builds, registries, software bills of materials, vulnerability scanning and proven container images. Presenting the platform without that capacity work creates the failure the transcript calls a common trap.
The migration conversation is also about incentives and lock-in. Licensing programs can absorb existing licenses for a period, resilience levels can be negotiated, and the client may explicitly refuse dependency in one area while accepting it in another. None of those decisions come from the architecture diagram alone.
Progress is usually gradual, measured in years rather than sprints. A system that runs on-premises keeps running while individual workloads move, and each move needs a comparison of what the client pays now against what the new design returns. An on-premises team that has never used infrastructure as code does not gain that skill because a new platform was chosen.
Resilience, queues and the cost of dubious shortcuts
Resilience decisions show up as concrete choices about queues, retries and standby capacity. Azure Queue storage, described as a simple queue inside a storage account, works for lower-stakes work, but a lost message during a payment flow means a lost sale.
The stronger option in that scenario is a service bus with topics and dead-letter handling, so a message that fails processing returns to the queue instead of vanishing. A queue upgrade is a cost, and the conversation becomes arithmetic: what a lost transaction costs compared with the price of the more capable service.
A concrete sequence for criticising a design before it ships:
- List every dependency the application has, including third-party services nobody controls.
- Switch each dependency off, one at a time, and observe what the application returns to the end user.
- Check whether the failure produced a log, whether the log identifies the cause, and where it is stored.
- Decide, with the client, which failures are acceptable and which need a fallback such as a circuit breaker or a retry.
- Record the decision and the accepted risk, then revisit it when the requirements change.
A payment gateway outage during a peak sales event requires a circuit breaker, retries and a defined degraded experience rather than an error page. The same logic applies to cache and database outages: the design has to specify what the application returns when the dependency is unreachable. A database that is switched off should produce a specific error and a specific log entry, not a generic crash that takes the container down with it.
Multi-region duplication is the expensive end of this spectrum. Duplicating an architecture across regions for standby capacity can double a monthly bill, because standby resources are paid for while sitting idle. In the transcript's example, an architecture costing around 1,000 euros a month would cost around 2,000 euros once duplicated. The architect quantifies the scenario, presents the number, and lets the client decide what downtime costs relative to the added spend.
How to move from developer to architect
The transition starts with self-critique. In the transcript, the turning point came from rereading old code and finding it incomprehensible, which pushed the developer toward design patterns, standards and deliberate study instead of continuing to accumulate frameworks.
A concrete sequence that follows the advice in this conversation:
- Revisit code you wrote months ago and write down what you no longer understand.
- Learn design patterns and the situations where each one applies, instead of collecting frameworks.
- Study reference architectures and read the reasoning behind each component, not only the diagram.
- Practise system design by explaining why a component exists and which strategy covers each failure.
- Move into a team where you can review code, run onboarding sessions and help set conventions.
Studying existing designs shortens the path. Microsoft's Azure Architecture Center publishes reference architectures with the reasoning behind each component, and the AWS Well-Architected Framework organizes reviews around security, reliability, performance efficiency and cost. Albert also points to the AWS Cloud Adoption Framework for teams that need a structured way to roll new practices into an organization, and both cloud frameworks are starting points for adaptation rather than templates to copy without context.
System design practice also prepares for interviews at large technology companies. Interviewers are less interested in which cache a known product uses than in why a component is there and which strategy covers each failure. "Cracking the Coding Interview" and system design material are the references Albert recommends for opening that critical view, alongside the 12-factor approach he covers in his own ASP.NET Core book.
When the architect should push back on the design
Critique is the central act of the role, applied to your own design first. In the transcript, the architect describes deliberately removing a cache, switching off a database or breaking a dependency, then tracing what the application does, what it logs and what the end user experiences.
The same method exposes weak assumptions in someone else's design. Asking why a critical application uses a simple queue, or why a workload with no containers should adopt a Kubernetes platform, is a question about consequence rather than correctness. The client is entitled to accept the risk once the risk is named.
The conversation gives a real exchange of that kind: a team using Azure Queue for a critical flow was told that a failure there loses the sale, and answered that the more capable service was too expensive. The follow-up question, how much a lost transaction costs, is what moves the decision. If the application is critical, the price of the safer queue has to be compared with the cost of the sales it drops.
Azure Advisor follows a similar pattern inside the platform: it flags an exposed virtual machine with a public IP as a risk but does not delete anything. The account owner applies the change or accepts the exposure. Architecture discussions work the same way, and the decision belongs to the business carrying the outcome.
The architect also has to avoid the opposite failure, which is designing a huge architecture for a problem that does not need one. The transcript's rule is to decide from data which part of the application actually needs to scale, and to stop there.
FAQ: solution architecture and software architecture
What is the difference between solution architecture and software architecture?
Software architecture covers one application's internal structure, quality gates and team process. Solution architecture covers how that application connects to other software, third-party services and cloud platforms to deliver a business outcome. The difference is scope, not seniority.
Is a software architect a more senior role than a solution architect?
Neither role ranks above the other. They work on different problems, and a strong developer is often technically better than the software architect they work with. The architect contributes perspective, communication and process design rather than superior coding speed.
Can a company operate without a formal architect title?
Yes. Mercado Livre's Tech Lead and Tech Expert structure, mentioned in this conversation as an example of an alternative model, still produces architectural decisions. The work continues under a different name, with the risk that strategic responsibilities may be missed if nobody is assigned them.
What are the five pillars of solution architecture?
Communication, functional and non-functional requirements, cost optimization, security and compliance, and resilience with disaster recovery. Each generates its own metrics, and each should appear in the critique of any proposed design.
How do you decide between a simple queue and a service bus?
Start with the value of the message. A simple queue inside a storage account can be acceptable when losing a message is tolerable; a service bus with dead-letter handling fits critical flows such as payments. The decision compares the service cost against the cost of a lost transaction.
How much should an architect still code?
Enough to test the tools they recommend and understand the system under discussion. Full-time coding is unlikely, but zero hands-on work makes the recommendations difficult to defend and limits useful feedback from the team.
Why does duplicating architecture across regions double the cost?
Duplicating a workload for standby capacity means paying for resources in both regions, even when one sits idle. In the transcript's example, an architecture costing around 1,000 euros a month becomes roughly 2,000 euros once duplicated. The architect quantifies the added spend and compares it against the business cost of downtime before recommending the duplication.
How do you start learning architecture without a formal architect role?
Begin with system design material, reference architectures from cloud providers and architecture decision records for the systems you already work on. Practising critique on existing designs builds the habit faster than reading theory alone.
What questions should a developer ask before adopting containers?
Ask how the team builds and scans images, who maintains the registry, whether the application runs within realistic memory and CPU limits and how compliance evidence is produced. Container adoption changes team maturity, not only deployment tooling.
A closing note for anyone sitting on unused insight
The strongest material in this conversation came from one person explaining decisions they had already made and defended. System design practice, dead-letter queues and the cost of duplicating a region only became useful once they were tied to the context that produced them, which is exactly the kind of reasoning that is hard to reconstruct after the whiteboard is erased.
That context is also why a live explanation beats an article written cold. A session where an architect walks through a diagram, names the constraint that forced each choice and argues with the client about the trade-offs carries reasoning that a summary loses. If you have that kind of material sitting in a recording, it has more value written down than left in a video that only a handful of people will finish.
Readers who want the same topics covered in more depth can find architecture, engineering and platform writing on Skala Blog. Tools such as Crazystack Typescript cover the TypeScript side of that stack, and creators like Gustavo Dev Doido run a Bootcamp do Dev Doido for developers who want structured practice rather than scattered tutorials. Skala Blog follows the same editorial line: technical content generated from talks, interviews and live sessions.
If you have an interview, a live session or a technical walkthrough sitting in a video, Skala Blog turns a YouTube URL into a transcript and then into a publishable article. The reasoning you already recorded does not have to stay locked inside a two-hour recording.