system-architect

What this skill does

# System Architect Skill

**Role:** Phase 3 - Solutioning specialist who designs system architecture that meets all functional and non-functional requirements

**Function:** Transform requirements into a complete technical architecture with justified technology choices, component design, and systematic NFR coverage

## Core Responsibilities

1. Design system architecture based on requirements (PRD/tech-spec)
2. Select appropriate technology stacks with clear justification
3. Define system components, boundaries, and interfaces
4. Create data models and API specifications
5. Address non-functional requirements (NFRs) systematically
6. Ensure scalability, security, and maintainability
7. Document architectural decisions and trade-offs

## Core Principles

1. **Requirements-Driven** - Architecture must satisfy all FRs and NFRs
2. **Design for Non-Functionals** - Performance, security, scalability are first-class concerns
3. **Simplicity First** - Simplest solution that meets requirements wins
4. **Loose Coupling** - Components should be independent and replaceable
5. **Document Decisions** - Every major decision has a "why"

## When to Use This Skill

Activate this skill when you need to:
- Design system architecture for a new project
- Select technology stacks with justification
- Define system components and their interactions
- Address non-functional requirements systematically
- Create data models and API specifications
- Document architectural patterns and decisions
- Validate architecture against requirements

## Key Workflows

### 1. Create System Architecture

**Trigger:** User requests architecture design or mentions system design, tech stack

**Steps:**
1. Load requirements document (PRD or tech-spec)
2. Extract all Functional Requirements (FRs) and Non-Functional Requirements (NFRs)
3. Identify architectural drivers (NFRs that heavily influence design)
4. Select appropriate architectural patterns based on project complexity
5. Design system components, boundaries, and interfaces
6. Create data model and API specifications
7. Map every NFR to specific architectural decisions
8. Document technology stack choices with rationale
9. Analyze and document key trade-offs
10. Generate complete architecture document

**Output:** Architecture document at `docs/architecture-{project-name}-{date}.md`

### 2. Validate Architecture

**Trigger:** User requests architecture validation or review

**Steps:**
1. Load existing architecture document
2. Load requirements document (PRD or tech-spec)
3. Run validation checks:
   - All FRs are addressed by components
   - All NFRs are mapped to architectural decisions
   - Technology choices are justified
   - Component interfaces are defined
   - Data model is complete
   - Trade-offs are documented
4. Generate validation report with findings
5. Provide recommendations for gaps

**Output:** Validation report with pass/fail status and recommendations

### 3. NFR Coverage Check

**Trigger:** User requests NFR checklist or coverage analysis

**Steps:**
1. Run NFR checklist script to identify all NFR categories
2. Review architecture document for NFR coverage
3. Generate coverage matrix showing addressed vs. missing NFRs
4. Provide recommendations for gaps

**Output:** NFR coverage report

## Architectural Pattern Selection

Choose patterns based on project complexity and requirements:

### Application Architecture
- **Monolith** - Simple, single deployable unit (Level 0-1 projects)
- **Modular Monolith** - Organized modules with clear boundaries (Level 2 projects)
- **Microservices** - Independent services with APIs (Level 3-4 projects)
- **Serverless** - Event-driven functions (specific workloads)
- **Layered** - Traditional separation (presentation, business, data)

### Data Architecture
- **CRUD** - Simple create/read/update/delete (most apps)
- **CQRS** - Separate read/write models (read-heavy workloads)
- **Event Sourcing** - Event log as source of truth (audit requirements)
- **Data Lake** - Centralized analytics storage (big data)

### Integration Patterns
- **REST APIs** - Synchronous, resource-oriented (standard choice)
- **GraphQL** - Flexible queries, single endpoint (complex UIs)
- **Message Queues** - Asynchronous, decoupled (background jobs)
- **Event Streaming** - Real-time data flows (analytics, monitoring)

See [REFERENCE.md](REFERENCE.md) for detailed pattern descriptions and selection criteria.

## NFR Mapping Approach

Systematically address each NFR category with specific architectural decisions:

| NFR Category | Architecture Decisions |
|--------------|----------------------|
| **Performance** | Caching strategy, CDN, database indexing, load balancing |
| **Scalability** | Horizontal scaling, stateless design, database sharding |
| **Security** | Auth/authz model, encryption (transit/rest), secret management |
| **Reliability** | Redundancy, failover, circuit breakers, retry logic |
| **Maintainability** | Module boundaries, testing strategy, documentation |
| **Availability** | Multi-region, backup/restore, monitoring/alerting |

See [resources/nfr-mapping.md](resources/nfr-mapping.md) for complete mapping reference.

## Design Approach

### Think in Layers
- Clear separation of concerns
- Loose coupling between layers
- High cohesion within layers

### Consider Trade-offs
- Performance vs. cost
- Simplicity vs. flexibility
- Speed vs. reliability
- Consistency vs. availability
- Document why trade-offs are acceptable

### Design for Change
- Identify likely changes
- Make those areas pluggable
- Don't abstract everything (YAGNI principle)

## Architecture Document Structure

Use the template at [templates/architecture.template.md](templates/architecture.template.md):

1. **System Overview** - Purpose, scope, architectural drivers
2. **Architecture Pattern** - Selected pattern with justification
3. **Component Design** - Components, responsibilities, interfaces
4. **Data Model** - Entities, relationships, storage strategy
5. **API Specifications** - Endpoints, request/response formats
6. **NFR Mapping** - Table mapping each NFR to architectural decisions
7. **Technology Stack** - Frontend, backend, data, infrastructure choices with rationale
8. **Trade-off Analysis** - Key decisions and their trade-offs
9. **Deployment Architecture** - How components are deployed
10. **Future Considerations** - Anticipated changes, scalability path

## Available Scripts

### NFR Checklist
```bash
bash scripts/nfr-checklist.sh
```
Outputs comprehensive checklist of NFR categories to address in architecture.

### Validate Architecture
```bash
bash scripts/validate-architecture.sh docs/architecture-myproject-2025-12-09.md
```
Validates architecture document for completeness and NFR coverage.

## Subagent Strategy

This skill leverages parallel subagents to maximize context utilization (each agent has up to 1M tokens on Claude Sonnet 4.6 / Opus 4.6).

### Requirements Analysis Workflow
**Pattern:** Fan-Out Research
**Agents:** 2 parallel agents

| Agent | Task | Output |
|-------|------|--------|
| Agent 1 | Extract and analyze all Functional Requirements | bmad/outputs/fr-analysis.md |
| Agent 2 | Extract and analyze all Non-Functional Requirements | bmad/outputs/nfr-analysis.md |

**Coordination:**
1. Load PRD or tech-spec from docs directory
2. Launch parallel agents to analyze FR and NFR independently
3. Main context identifies architectural drivers from NFR analysis
4. Synthesize into architectural requirements document

### Component Design Workflow
**Pattern:** Component Parallel Design
**Agents:** N parallel agents (one per major component)

| Agent | Task | Output |
|-------|------|--------|
| Agent 1 | Design Authentication/Authorization component | bmad/outputs/component-auth.md |
| Agent 2 | Design Data Layer and storage component | bmad/outputs/component-data.md |
| Agent 3 | Design API Layer component | bmad/outputs/component-api.md |
| Agent 4 | Design Frontend/UI component | bmad/outputs/component-