What Solution Architects Actually Do

The title "Solution Architect" means different things at different companies. But the core is consistent: you're responsible for the technical strategy of a project — making decisions that are hard to change later.

Architect vs Senior Developer

| | Senior Developer | Solution Architect | |---|---|---| | Focus | Writing excellent code | Enabling others to write excellent code | | Decisions | Implementation details | System structure and trade-offs | | Horizon | Current sprint | 6–24 months | | Stakeholders | Engineering team | Engineering + Product + Business | | Output | Code | Designs, diagrams, ADRs, prototypes |

A good architect often writes code too — staying technical is what keeps recommendations realistic.

The Core Job: Trade-off Analysis

Every architecture decision is a trade-off. The architect's job is to make those trade-offs explicitly and document why.

Common trade-offs:

• Build vs Buy — custom solution gives control; SaaS gives speed
• Consistency vs Availability — CAP theorem (choose in a network partition)
• Simplicity vs Flexibility — generic solutions are often over-engineered for current needs
• Cost vs Performance — caching, CDNs, and horizontal scaling all cost money

Architecture Decision Records (ADRs)

An ADR documents an architectural decision, its context, and the alternatives considered.

# ADR 0012: Use PostgreSQL as Primary Database

## Status: Accepted

## Context
We need a relational database for transactional workloads. The team has
strong SQL experience. Our workloads are primarily OLTP with occasional
complex queries.

## Decision
Use PostgreSQL 16 as the primary database.

## Considered Alternatives
- **MySQL** — similar capability but less rich feature set (no window functions without extensions)
- **SQL Server** — enterprise licensing cost not justified at current scale
- **MongoDB** — document model doesn't fit our relational data

## Consequences
- Positive: JSONB support, powerful indexing, rich ecosystem, no licensing cost
- Negative: Requires PostgreSQL expertise; migration from existing SQL Server would be needed

What Architects Actually Produce

1. Architecture diagrams — C4 model (Context, Container, Component, Code)
2. ADRs — documented decisions with rationale
3. Proof of concepts — working code that validates a technical approach
4. Non-functional requirements — performance targets, SLAs, scalability requirements
5. Tech radar — which technologies are adopted, trial, assess, or hold
6. Runbooks — how to operate the system in production

Stakeholder Communication

Architects translate between two worlds:

Business says:        "We need to support 10x more users next quarter"
Architect hears:      "Current single DB instance will bottleneck at 2x load.
                       We need read replicas + query optimization + caching
                       — that's 3 weeks work before the deadline."
Architect says:       "We can support 5x with 2 weeks work. 10x needs 6 weeks
                       and carries risk. Here's the plan for both options."

Architecture Principles (Examples)

Good architects establish principles so teams can make consistent decisions independently:

1. API-first — design the API contract before the implementation
2. Fail fast — validate input at the boundary, not deep in the stack
3. Structured logging everywhere — every service emits correlated logs
4. No direct DB access across service boundaries
5. Infrastructure as code — nothing configured manually in production
6. Security by default — encryption at rest and in transit, least privilege

The Career Path

Junior Developer → Senior Developer → Lead Developer → Solution Architect
                                         ↑
                               (some go Staff Engineer instead)

You're ready to think about architecture when:

• You can explain why a design is good, not just that it works
• You've experienced the consequences of bad architecture decisions
• You can communicate technical complexity to non-technical stakeholders
• You find yourself thinking about the next 2 years, not just the next PR

Key Takeaways

1. Architecture is about trade-offs — document them explicitly with ADRs
2. The best architects write code — staying technical keeps recommendations grounded
3. Non-functional requirements (performance, security, scalability) are your domain — make them explicit
4. Communicate upward and outward — technical decisions have business consequences
5. Architecture patterns are tools, not goals — apply the simplest thing that meets the requirements