Skill: Architecture Analysis

Purpose

Evaluate technical approaches, assess system designs, and make informed architectural decisions that balance quality attributes with business constraints.

When to Use

• New feature requires architectural decisions
• Evaluating technical feasibility of requirements
• Choosing between implementation approaches
• Assessing impact of changes on existing systems
• Creating Architecture Decision Records (ADRs)

---

Analysis Framework

1. Context Assessment

Understand the current state:

## Architecture Context: {{feature}}

### System Overview
- **Domain:** {{domain}}
- **Current Architecture:** {{pattern}} (e.g., Monolith, Microservices)
- **Tech Stack:** {{stack}}

### Existing Components Affected
| Component | Type | Impact Level |
|-----------|------|--------------|
| {{component}} | Service/Module/DB | High/Medium/Low |

### Constraints
- **Technical:** {{technicalConstraints}}
- **Business:** {{businessConstraints}}
- **Team:** {{teamConstraints}}
- **Timeline:** {{timelineConstraints}}

2. Quality Attribute Analysis

Evaluate against key quality attributes:

Attribute	Question	Consideration
Performance	How fast must it respond?	Latency, throughput
Scalability	How much growth expected?	Horizontal vs vertical
Reliability	What uptime is required?	Redundancy, failover
Security	What data sensitivity?	Auth, encryption, audit
Maintainability	How often will it change?	Modularity, testability
Deployability	How often deployed?	CI/CD, rollback

---

Technical Feasibility Assessment

Feasibility Checklist

## Technical Feasibility: {{feature}}

### Can We Build It?
- [ ] Required technology is available
- [ ] Team has necessary skills
- [ ] No blocking technical constraints
- [ ] Integration points are accessible

### Should We Build It This Way?
- [ ] Aligns with existing architecture
- [ ] Doesn't create technical debt
- [ ] Scales with expected growth
- [ ] Maintainable long-term

### Effort Assessment
| Component | Complexity | Estimate | Risk |
|-----------|------------|----------|------|
| {{component}} | Low/Med/High | {{points}} | {{risk}} |

### Dependencies
| Dependency | Type | Status | Mitigation |
|------------|------|--------|------------|
| {{dep}} | Internal/External | Available/Unknown | {{mitigation}} |

---

Approach Comparison

When multiple approaches exist:

## Architecture Options: {{feature}}

### Option 1: {{approach1Name}}

**Description:** {{description}}

**Pros:**
- {{pro1}}
- {{pro2}}

**Cons:**
- {{con1}}
- {{con2}}

**Quality Attributes:**
| Attribute | Rating | Notes |
|-----------|--------|-------|
| Performance | ⭐⭐⭐ | {{notes}} |
| Scalability | ⭐⭐ | {{notes}} |
| Maintainability | ⭐⭐⭐⭐ | {{notes}} |

**Effort:** {{estimate}}
**Risk:** Low/Medium/High

---

### Option 2: {{approach2Name}}

[Same structure]

---

### Recommendation

**Selected:** Option {{n}}

**Rationale:**
{{rationale}}

**Trade-offs Accepted:**
{{tradeoffs}}

---

Integration Analysis

When integrating with existing systems:

## Integration Analysis: {{feature}}

### Integration Points

| System | Interface | Direction | Protocol |
|--------|-----------|-----------|----------|
| {{system}} | {{interface}} | Inbound/Outbound | REST/gRPC/Event |

### Data Flow

[Source] → [Transform] → [Destination] {{dataFlowDescription}}

### API Considerations
- **Authentication:** {{authMethod}}
- **Rate Limiting:** {{rateLimits}}
- **Versioning:** {{versionStrategy}}
- **Error Handling:** {{errorStrategy}}

### Failure Modes
| Failure | Impact | Mitigation |
|---------|--------|------------|
| {{failure}} | {{impact}} | {{mitigation}} |

---

Complexity Assessment

Estimate technical complexity:

Complexity Factors

Factor	Low (1)	Medium (2)	High (3)
New Technology	None	Some learning	Significant
Integration Points	0-1	2-3	4+
Data Migration	None	Simple	Complex
Security Requirements	Standard	Enhanced	Critical
Performance Requirements	Standard	Demanding	Extreme
Team Experience	Expert	Familiar	New

Total Score: Sum of factors

• Low Complexity: 6-9
• Medium Complexity: 10-13
• High Complexity: 14-18

---

Risk Identification

## Technical Risks: {{feature}}

### Identified Risks

| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| {{risk}} | High/Med/Low | High/Med/Low | {{mitigation}} |

### Risk Matrix

|            | Low Impact | Medium Impact | High Impact |
|------------|------------|---------------|-------------|
| **High Prob** | Monitor | Mitigate | Avoid |
| **Med Prob** | Accept | Mitigate | Mitigate |
| **Low Prob** | Accept | Accept | Monitor |

### Contingency Plans
{{#each highRisks}}
**{{risk}}:** {{contingencyPlan}}
{{/each}}

---

Story Annotation

Add technical notes to user stories:

### Technical Notes (for Story {{storyKey}})

**Architecture Impact:** Low/Medium/High

**Affected Components:**
- {{component1}}
- {{component2}}

**Implementation Approach:**
{{approach}}

**Technical Considerations:**
- {{consideration1}}
- {{consideration2}}

**Dependencies:**
- {{dependency}}

**Estimated Complexity:** {{complexity}} points

**Risks:**
- {{risk}}

---

Used By Agents

Agent	Analysis Use
Software Architect	Primary - all architectural analysis
Senior Developer	Technical approach decisions
DevOps Engineer	Infrastructure architecture
Product Owner	Understanding technical constraints

Best Practices

1. Document decisions - Create ADRs for significant choices
2. Consider quality attributes - Balance -ilities appropriately
3. Think long-term - Short-term hacks become long-term debt
4. Validate assumptions - Prototype when uncertain
5. Involve the team - Architecture affects everyone
6. Review constraints - Technical decisions must align with business needs