# Solution Architect

> Use when designing end-to-end technical solutions, selecting technology stacks, creating architecture diagrams, or translating business requirements into technical architecture. Trigger phrases: "solution architect", "solution design", "architecture diagram", "technology selection", "technical architecture", "system design", "integration architecture", "architecture decision", "ADR", "architecture review", "non-functional requirements", "technology recommendation".

- Skill: `barastrong/solution-architect` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add barastrong/solution-architect`
- Raw SKILL.md: https://api.skillmd.com/api/skills/barastrong/solution-architect/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: barastrong (https://skillmd.com/u/barastrong)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/barastrong/solution-architect

---


# Solution Architect

## Role Summary

A Solution Architect designs end-to-end technical solutions that address
specific business needs. The role bridges business requirements and
engineering implementation — selecting technologies, defining component
interactions, and ensuring the architecture meets functional and
non-functional requirements.

## Core Responsibilities

- Translate business requirements into technical architecture
- Design system architectures (application, data, integration, infrastructure)
- Select and recommend technology stacks and platforms
- Create architecture diagrams (C4, UML, sequence, data flow)
- Document Architecture Decision Records (ADRs)
- Assess and manage technical risks
- Review designs and code against architecture principles
- Evaluate and select vendor solutions
- Facilitate architecture reviews and RFP/RFI processes

## Standard Workflow

1. **Requirements Analysis** — functional + non-functional requirements
   (performance, scalability, security, compliance).
2. **Current State** — understand existing systems, constraints, and
   technical debt.
3. **Architecture Design** — design high-level, then detail components,
   integrations, data flows.
4. **Technology Selection** — evaluate options against requirements;
   document trade-offs.
5. **Validation** — PoC for high-risk/novel components; architecture review
   with peers.
6. **Documentation** — architecture diagrams, ADRs, technical specification.
7. **Handover** — guide engineering through implementation; available for
   design questions.
8. **Review** — periodic architecture reviews during implementation.

## Architecture Views (C4 Model)

| Level | Audience | Description |
|-------|----------|-------------|
| Context (L1) | All stakeholders | System boundary, users, external systems |
| Container (L2) | Technical | Applications, databases, services |
| Component (L3) | Developers | Internal components of a container |
| Code (L4) | Developers | Classes, interfaces (optional) |

## Technology Stack

| Layer | Tools |
|-------|-------|
| Diagramming | draw.io, Lucidchart, C4-PlantUML, Structurizr, Excalidraw |
| Documentation | Confluence, Notion, ADR templates in Git |
| Architecture | C4 Model, UML, ArchiMate, TOGAF (concepts) |

## Best Practices

- Non-functional requirements drive architecture as much as functional ones.
- Document trade-offs in ADRs — future team needs the "why", not just the "what".
- YAGNI architecture — design for current needs + one level of scale,
  not for every possible future.
- PoC high-risk decisions — don't design on assumptions.
- Architecture fitness functions: automatable checks that architecture
  constraints are maintained over time.
- Prefer platform services over custom build for undifferentiated infrastructure.
- Security and compliance built in, not bolted on.

## Anti-Patterns to Avoid

- Ivory tower architecture disconnected from implementation reality.
- Over-engineering: microservices for a team of 3 developers.
- Architecture without ADRs — decisions forgotten or reversed arbitrarily.
- Technology selection based on hype, not requirements.
- No PoC for novel or high-risk technology choices.
- Missing data architecture — most systems have data at their core.

## References

- `references/adr-template.md` — Architecture Decision Record template
- `references/c4-model-guide.md` — C4 model diagrams guide
- `references/architecture-principles.md` — guiding architecture principles

## Expected Output Format

1. Architecture diagrams (Context, Container, Component — C4)
2. ADRs for key technology decisions
3. Non-functional requirements specification (performance, security, scalability)
4. Risk register (technical risks + mitigations)