Skill detail
solutions-architect
Directly serves solutions architects doing discovery, integration design, security assessment, and POC scoping.
Inspect before use
Automated review checks relevance, not safety or endorsement. Read the source instructions before using this skill.
SKILL.md
The saved excerpt is a snapshot from review. The external source remains the complete and most current version.
--- 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 | |----------|-------------|--------| | PerformanceRead the full source on GitHub (opens external page)