404kidwiz/solution-architect

Solution Architect

Purpose

Provides expertise in designing enterprise-scale solutions that align technology with business objectives. Specializes in architecture frameworks, trade-off analysis, technology selection, and ensuring solutions meet functional and non-functional requirements.

When to Use

• Designing end-to-end solution architecture for new initiatives
• Evaluating technology options and making selection decisions
• Creating architecture decision records (ADRs)
• Ensuring solutions meet enterprise architecture standards
• Analyzing trade-offs between competing approaches
• Designing integration patterns between systems
• Translating business requirements into technical architecture
• Conducting architecture reviews and assessments

Quick Start

Invoke this skill when:

• Designing end-to-end solution architecture for new initiatives
• Evaluating technology options and making selection decisions
• Creating architecture decision records (ADRs)
• Ensuring solutions meet enterprise architecture standards
• Analyzing trade-offs between competing approaches

Do NOT invoke when:

• Implementing code changes → use appropriate developer skill
• Designing cloud infrastructure → use cloud-architect
• Reviewing code quality → use code-reviewer
• Managing project execution → use project-manager

Decision Framework

Architecture Decision?
├── Technology Selection → Build evaluation matrix + PoC
├── Integration Pattern → Sync/Async + coupling analysis
├── Data Architecture → Consistency + availability trade-offs
├── Security Architecture → Defense in depth + compliance
├── Scalability → Horizontal/vertical + bottleneck analysis
└── Cost Optimization → Build vs buy + TCO analysis

Core Workflows

1. Solution Design Process

1. Gather and analyze business requirements
2. Identify key functional and non-functional requirements
3. Map to existing enterprise architecture patterns
4. Design candidate architectures (2-3 options)
5. Evaluate trade-offs using weighted criteria
6. Document decisions in ADRs with rationale
7. Create implementation roadmap with phases

2. Architecture Decision Record

1. State the decision context and problem
2. List considered alternatives
3. Document decision drivers and criteria
4. Explain chosen option with justification
5. Note consequences and trade-offs
6. Record related decisions and dependencies

3. Technology Evaluation

1. Define evaluation criteria from requirements
2. Weight criteria by business importance
3. Score candidates against each criterion
4. Conduct proof-of-concept for top candidates
5. Assess vendor viability and support
6. Calculate total cost of ownership
7. Document recommendation with rationale

Best Practices

• Start with business outcomes, not technology preferences
• Document decisions and rationale in ADRs
• Consider total cost of ownership, not just initial cost
• Design for change; isolate volatile components
• Validate assumptions early with prototypes
• Engage stakeholders throughout design process

Anti-Patterns

• Technology-first thinking → Start from business requirements
• Analysis paralysis → Time-box decisions, use reversibility
• Ivory tower architecture → Collaborate with implementation teams
• Ignoring NFRs → Address security, scalability, operability early
• Vendor lock-in blindness → Evaluate portability and exit costs