Roadmaps · L5
Solution Architect
A solution architect designs a technical solution for a specific business problem and guides teams as it is delivered. They combine requirements, constraints and risks into a well-argued architecture.
How it differs from the previous level
A tech lead is responsible for one team's direction and delivery. A solution architect ensures the coherence of a solution that spans several teams, systems and external parties. The work is more about analysing requirements, comparing options, agreeing integrations and documenting decisions.
Expected knowledge
- Requirements analysis: functional requirements, quality attributes and constraints
- Quality attributes: performance, availability, security, changeability and how they conflict
- Trade-off analysis: options, criteria, risks and the justification of a decision
- Integration styles: synchronous API, events, batch; contracts and versioning
- Domain modelling: bounded context, aggregate, data ownership
- Cloud architecture basics: managed services, regions and zones, cost drivers
- Security architecture: identity, the authorization model, protection of data
- Documentation: the C4 model, ADRs, architecture views
Practical skills
- Talk to stakeholders and extract requirements and quality scenarios
- Prepare several architecture options for one problem and compare them
- Draw C4 context and container diagrams for a solution
- Document decisions with ADRs and explain their consequences
- Agree an integration contract and failure behaviour with the teams involved
- Work with delivery teams and follow how the solution is implemented
Common mistakes
- Starting with a favourite technology before the requirements are clear
- Writing quality attributes as unmeasured phrases such as 'fast, secure'
- Drawing a diagram without recording the reasoning and the alternatives
- Proposing an ideal architecture that ignores the team's skills and time
- Forgetting failure and version-change cases in integrations
- Drawing the architecture once and never updating it as things change
Learning priorities
- 1Make requirements and quality scenarios preciseInstead of 'the system should be fast', write a measurable scenario and be clear about which attribute takes priority.
- 2Run trade-off analysisFor each decision show options, criteria and cost, and keep the decision as an ADR.
- 3Design integration and data ownershipWhich system owns which data, how the contract is versioned and what happens on failure.
- 4Documentation and communicationUse C4 to produce views suited to different audiences and keep the documents updated together with the code.
- 5Stay connected to deliveryFollow how teams implement the architecture, learn from practice and correct course.
Architecture maturity
At solution architect level, architecture becomes a traceable chain of decisions derived from requirements. Each significant choice is tied to a quality attribute, a constraint and a risk, and the alternatives are shown openly. The solution must be realistic not only technically but also in terms of team skills, budget and the later cost of change.
Example questions
- On a project with vague requirements, what are your first three questions?
- Explain the conflict between availability and consistency with a concrete example.
- When would you choose event-based integration instead of a synchronous API?
- What criteria would you use to define microservice boundaries?
- How do you justify an architecture decision in an ADR?
- Which level of the C4 model would you show to which audience?
- How should your solution behave when a third-party system changes its API?
Exercises you can do on your own
- For a small business scenario, write the quality attributes as measurable scenarios.
- Prepare two architecture options for the same problem (for example a modular monolith and microservices) and compare them against criteria.
- Draw C4 context and container diagrams for your solution and note the audience of each.
- Write three key decisions as ADRs: context, options, decision, consequences.
- Define an integration contract (API or event) between two systems, including versioning and failure behaviour.
Articles for this level
- Solution architectureThe solution architect role: from requirements to a working solution
- C4 modelThe C4 model: architecture diagrams that people actually read
- ADRsWriting Architecture Decision Records that survive the team
- Event-driven architectureEvent-driven architecture trade-offs
- MicroservicesDrawing microservice boundaries
- DDDDDD aggregates, bounded contexts and invariants
- Cloud architectureCloud architecture basics for backend engineers
- API securityAPI security for backend engineers with the OWASP API Security Top 10
Programs that fit
How close are you to this level?
The skills assessment builds a personal gap report from your answers. It is a recommendation, not a certificate.