The solution architect role: from requirements to a working solution

The problem: a request without a shape

A business unit says: "We want customers to track their deliveries in our app." On the surface this is a feature. Underneath are open questions. Where does tracking data come from, and who owns it? How fresh must it be? What happens when the courier's system is down? Does it affect existing contracts, security rules or the budget? Different developers will give different answers, build different things and discover the disagreements late.

A solution architect is responsible for turning a business need into a coherent technical solution that a delivery team can build, operate and evolve. The scope is one solution or a group of related ones, not the whole organization; that wider view belongs to enterprise architecture. The role sits between business stakeholders, engineering teams and operations, and its main output is not diagrams but sound decisions that people understand.

From requirements to a solution

A workable flow has six steps. It is iterative; later steps often send you back.

1. Understand the goal. Ask why the change is needed and how success will be recognized. A stated solution ("build an API") often hides the real need.
2. Capture requirements and quality attributes. Functional requirements say what the solution does. Quality attributes (sometimes called non-functional requirements) say how well: availability, latency, security, privacy, scalability, maintainability, cost, auditability. They drive the architecture more than features do.
3. Identify constraints. Existing systems, mandated technologies, regulations, team skills, budget and deadlines. Constraints are inputs, not obstacles to argue away.
4. Generate options. Describe at least two credible approaches, including the cheap one and the "do nothing" baseline.
5. Analyze trade-offs and choose. Compare options against the quality attributes that matter most.
6. Document and communicate. Capture the design so others can implement and challenge it.

Quality attributes in practice

"The system must be fast and secure" is not testable. Turn each attribute into a scenario with a source, a stimulus and a measurable response, using numbers that come from the business or from agreed assumptions:

Attribute:   Availability
Scenario:    A courier-system outage occurs during business hours.
Expectation: Customers still see the last known status with a
             "last updated" time; no error page.
Measure:     Tracking page loads successfully while the upstream
             is down (verified by a fault-injection test).

This kind of scenario tells the team what to build (a local copy of status, a stale-data indicator) and how to test it.

Options and trade-offs

For the delivery-tracking request, a short comparison might look like this:

There is rarely a universally right answer. The architect states which attributes decide the choice. If freshness matters most and the courier offers webhooks, option three wins; if the courier offers only a rate-limited API, option two is the realistic path. Record the outcome in an ADR, including the rejected options and the conditions for revisiting.

Documenting the solution

Good solution documentation is short, layered and aimed at readers:

• Context and goals: a page that a business sponsor can read.
• Architecture views: a C4 context and container diagram, plus a sequence diagram for critical flows.
• Data: key entities, ownership and retention.
• Interfaces: API contracts and event schemas, ideally as machine-readable specifications.
• Quality attribute scenarios and how they are met.
• Risks, assumptions and open questions, each with an owner.
• Decisions: links to ADRs.

Avoid long documents that no one reads. Keep them in the repository or a shared space with an owner and a review habit.

Working with delivery teams

A solution architect who hands over a design and disappears produces designs that drift. Healthy habits include:

• joining refinement and design sessions early so the team shapes the design too
• being available for questions and reviewing risky Pull Requests or designs, without taking over code review
• coding small prototypes or spikes to test the riskiest assumption before committing
• agreeing on boundaries so teams can decide locally within them; see microservices boundaries
• checking that the solution as built still meets the quality attributes, using load tests, security reviews and operational feedback
• staying honest about uncertainty; "we will learn this in the first spike" is a legitimate plan

Communication is half the job. Explain the same design in different depths: a sponsor needs outcomes and risks, a developer needs interfaces and constraints, an operator needs failure behavior and monitoring.

Common mistakes

1. Choosing technology first. Fashionable tools are not requirements.
2. Ivory-tower design. A design that the team cannot build or does not believe in will not survive.
3. Ignoring quality attributes until a production incident points them out.
4. Over-documenting or under-documenting. Both make the design unusable.
5. No options. A single option is a decision made before analysis.
6. Forgetting operations and cost. Someone has to run and pay for the solution for years.
7. Treating the design as final. Revisit it when assumptions break.

Trade-offs of the role itself

Architects balance depth and breadth. Staying close enough to code to keep credibility, while spending enough time on stakeholders to keep alignment, is a constant tension. Too much governance slows teams; too little produces inconsistent solutions. Many organizations settle on guardrails (principles, a few standards) and team autonomy inside them.

Checklist

• Goal and success criteria stated
• Quality attributes expressed as scenarios
• Constraints and assumptions listed with owners
• At least two options compared
• Decision recorded with consequences
• Views for different audiences
• Risks and open questions tracked
• Design checked against the built result

Where to go next

Learn the notation and records used day to day in the C4 model guide and ADR writing, compare scope with enterprise architecture, or follow the Solution Architect roadmap.