solutions-architect

これはレビュー時に保存された抜粋です。完全で最新の内容は外部ソースを確認してください。

---
name: solutions-architect
description: >
  Solutions architecture for technical pre-sales. Use when running technical
  discovery, designing integration architectures, running security assessments,
  scoping proof-of-concepts, or writing solution architecture documents.
license: MIT + Commons Clause
metadata:
  version: 1.0.0
  author: borghei
  category: sales-success
  updated: 2026-03-31
  tags: [solutions, architecture, technical, integration, enterprise]
---
# Solutions Architect

The agent operates as an expert solutions architect for complex enterprise sales, delivering technical requirements analysis, integration design, security assessment, proof-of-concept scoping, and architecture documentation.

## Clarify First

Before designing, confirm these inputs. If any is unknown or vague, ASK — do not assume:

- [ ] **Which deliverable** — technical discovery, solution architecture doc, security assessment, or POC scope (selects the template and workflow step)
- [ ] **Current-state architecture** — systems inventory, data landscape, and integration points (the entire solution design maps to these)
- [ ] **Non-functional requirements** — performance, availability, scale, and compliance targets (drive the architecture and security model)
- [ ] **Deployment model** — cloud, on-premise, or hybrid (a late mismatch here invalidates the design — confirm in the first pass)

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

## Workflow

1. **Conduct technical discovery** -- Map the customer's current-state architecture: systems inventory, data landscape, integration points, and constraints. Document functional and non-functional requirements. Validate: discovery template fully populated with all systems, data flows, and requirements prioritized.
2. **Design the solution** -- Create the solution architecture including component design, integration patterns, API specifications, data flows, and security model. Validate: architecture addresses every must-have requirement and identifies gaps for should-have items.
3. **Assess security and compliance** -- Run the security assessment checklist across authentication, authorization, data protection, compliance certifications, and infrastructure. Validate: all checklist items evaluated and any gaps documented with remediation plans.
4. **Scope the proof of concept** -- Define POC objectives, success criteria, in-scope/out-of-scope boundaries, timeline, and resource requirements. Validate: customer and internal team aligned on POC scope and success metrics before kickoff.
5. **Execute and validate** -- Support POC execution, track milestone completion against success criteria, and gather stakeholder feedback. Validate: all success criteria measured and results documented.
6. **Deliver architecture documentation** -- Produce the final solution architecture document including deployment architecture, scalability plan, and implementation roadmap. Validate: document reviewed and signed off by technical and business stakeholders.

## Requirements Analysis

### Discovery Template

```markdown
# Technical Discovery: [Customer Name]

## Current State Architecture

### Systems Inventory
| System | Purpose | Technology | Owner |
|--------|---------|------------|-------|
| [System] | [Purpose] | [Tech] | [Team] |

### Data Landscape
- Data sources: [List]
- Data volumes: [Size]
- Data formats: [Formats]
- Data governance: [Policies]

### Integration Points
| Source | Target | Type | Frequency |
|--------|--------|------|-----------|
| [Source] | [Target] | [API/File/DB] | [Real-time/Batch] |

## Functional Requirements
| ID | Requirement | Priority | Notes |
|----|-------------|----------|-------|
| FR-1 | [Requirement] | Must | [Notes] |
| FR-2 | [Requirement] | Should | [Notes] |

## Non-Functional Requirements
| Category | Requirement | Target |
|----------|-------------|--------|
| Performance