Solutions Architect

Solutions Architect

When to Use

• Run technical discovery — stakeholders, systems, constraints, success criteria
• Translate needs into requirements — functional, integration, NFRs, assumptions
• Design integration architecture — APIs, events, identity, data flows, boundaries
• Produce reference architectures — logical, deployment, and integration views for review
• Assess security and compliance fit — controls mapping, gaps, mitigations (not legal advice)
• Frame sizing and cost — order-of-magnitude capacity, licensing, cloud spend drivers
• Scope PoC/Pilot — goals, in/out of scope, success metrics, exit criteria
• Draft RFP/RFI technical responses — requirements traceability, solution narrative
• Recommend build vs buy — options, trade-offs, TCO drivers, risks
• Prepare handoff to delivery — backlog, dependencies, open decisions, acceptance criteria

When NOT to Use

• Org landing zones, CCoE, enterprise EA programs → enterprise-cloud-architect
• Single-product internal ADRs, C4, engineering standards → senior-system-architecture
• Well-Architected cloud platform design (non-deal) → cloud-architect
• Production Terraform modules, CI/CD, K8s build → infrastructure-engineer, devops
• Configure RDS, IAM errors, autoscaling tuning → cloud-engineer
• Build and demo the PoC in customer environment → sales-engineer
• Issue trees, operating model, steerCo without technical design → business-consultant
• MSA/SaaS redlines and legal risk → commercial-counsel
• SOC 2 evidence packs and control narratives → compliance-engineer
• Implement cloud guardrails and CSPM → cloud-security-engineer
• Multi-year NPV/EA economics deep dive → cloud-economist
• Program RAID, milestones, steering cadence → technical-program-manager

Related skills

Core Workflows

1. Scope and engagement framing

Role boundaries, inputs, outputs, stakeholders.

See `references/solutions_architect_scope.md`.

2. Discovery and requirements

Interviews, current state, requirements pack, assumptions.

See `references/discovery_and_requirements.md`.

3. Integration and reference architecture

Context, integration patterns, reference diagrams, interfaces.

See `references/integration_and_reference_architecture.md`.

4. Security and compliance fit

Threat framing, control mapping, gaps, customer questionnaires.

See `references/security_compliance_fit.md`.

5. Sizing, cost, and options

Capacity, cost drivers, build-vs-buy, option comparison.

See `references/sizing_cost_and_options.md`.

6. RFP, PoC, and handoff

RFP structure, PoC charter, delivery handoff package.

See `references/rfp_poc_and_handoff.md`.

Outputs

• Discovery summary — context, constraints, open questions
• Requirements pack — must/should/could, NFRs, traceability matrix
• Solution architecture — context, integration, deployment views
• Security/compliance fit memo — mappings, gaps, mitigations
• Sizing and cost estimate — assumptions, ranges, sensitivities
• Option comparison — build vs buy vs partner, recommendation
• PoC charter — scope, timeline, success criteria, risks
• RFP response sections — compliant narrative with requirement IDs
• Handoff package — backlog seed, dependencies, decisions log

Principles

• Discovery before design — validate problem, constraints, and buyers
• Explicit assumptions — every estimate and diagram states what you assumed
• Fit for purpose — right-size architecture for phase (PoC vs production)
• Traceability — requirements IDs flow through design, RFP, and backlog
• Reversible decisions — call one-way doors; defer until evidence from PoC
• Handoff-ready — delivery teams get scope, risks, and acceptance criteria

Discovery and requirements

Table of contents

1. Discovery workflow 2. Interview guide 3. Current-state capture 4. Requirements structure 5. NFR catalog 6. Assumptions and risks

Discovery workflow

1. Frame — restate the problem, users, and decision timeline in one paragraph 2. Discover — interviews, document review, workshops (see interview guide) 3. Synthesize — current state, pain points, constraints, success metrics 4. Specify — requirements pack with IDs and priority 5. Validate — review with sponsor, security, and delivery lead 6. Baseline — version the pack; log changes through the engagement

Do not start detailed architecture until must-have requirements and hard constraints are written down.

Interview guide

Capture quotes and sources (interview date, doc name) for contentious requirements.

Current-state capture

Document at a level sufficient for integration design:

• Actors — human roles, external partners, system accounts
• Systems — name, owner, hosting, lifecycle (legacy/modern)
• Flows — primary happy path and top exceptions
• Pain — reliability, latency, manual steps, compliance gaps
• Technical debt — blockers called out by customer IT

Use a simple context diagram; defer C4 depth to senior-system-architecture for internal product work.

Requirements structure

Assign stable IDs: REQ-###, NFR-###.

Each requirement:

ID: REQ-001
Priority: Must
Statement: As a [actor], I need [capability] so that [outcome].
Acceptance: Given/When/Then or measurable test.
Source: RFP §3.2 / workshop 2024-01-15
Dependencies: REQ-005, integration with System X

Maintain a traceability matrix: requirement ID → design element → test/PoC scenario → RFP section.

NFR catalog

Quantify where possible; mark TBD with owner and date to resolve.

Assumptions and risks

Assumptions log — anything the design depends on (API availability, data quality, customer provides VPN access).

Risks — probability × impact; mitigation or acceptance; owner.

Escalate assumptions that affect pricing, timeline, or compliance before solution sign-off.

Deep business case modeling → business-consultant. Cloud-specific TCO/NPV → cloud-economist.

Integration and reference architecture

Table of contents

1. Architecture views 2. Integration patterns 3. Interface design 4. Data and identity 5. Reference architecture templates 6. Review checklist

Architecture views

Produce the minimum set stakeholders need:

Label as-is vs to-be; show phase boundaries (PoC vs production).

Platform landing zones and org guardrails → cloud-architect, enterprise-cloud-architect. Internal product C4 and ADRs → senior-system-architecture.

Integration patterns

Prefer API-first contracts with explicit error models and idempotency keys for money- or state-changing operations.

Interface design

For each integration document:

• Owner system and counterpart
• Protocol — HTTPS, AMQP, SFTP, etc.
• Auth — OAuth2, mTLS, API key (prefer short-lived tokens)
• Payload — schema reference or sample; versioning rule
• SLA — latency, availability, rate limits
• Failure behavior — retries, compensation, manual fallback
• PII / secrets — what crosses the boundary

Use an interface catalog table; link to OpenAPI/AsyncAPI where they exist or will be created in delivery.

Data and identity

Data:

• System of record per entity
• Direction of sync (master → replica, bidirectional)
• Consistency model (strong, eventual)
• Retention and purge requirements

Identity:

• Human vs machine identities
• Federation (SAML/OIDC) vs local accounts
• Authorization model (RBAC, ABAC, scopes)
• Service-to-service (workload identity, client credentials)

Call out cross-border data flows early for compliance fit.

Reference architecture templates

Adapt; do not copy blindly.

SaaS + enterprise integration

• IdP federation → app → API gateway → core services
• Webhooks to customer SIEM or ticketing
• Admin APIs behind separate auth and rate limits

Hybrid (on-prem + cloud)

• Private connectivity (VPN, ExpressRoute, Direct Connect)
• Identity sync (AD → cloud IdP)
• Strangler: new capability in cloud, legacy via API/queue

Event-driven domain

• Ingress API → outbox → message bus → consumers
• Schema registry; dead-letter handling

Analytics / reporting

• Operational DB → CDC/stream → lake/warehouse → BI
• Separate network path and role for analysts

Detailed cloud service selection → cloud-architect. Implementation → infrastructure-engineer, cloud-engineer.

Review checklist

• [ ] Every external system on context diagram has an owner and integration owner
• [ ] Critical flows have sequence diagrams including failure/retry
• [ ] No single unnamed “magic” integration box
• [ ] NFRs traced to components (latency, availability, encryption)
• [ ] PoC scope uses subset of interfaces; production gaps listed
• [ ] Versioning and deprecation strategy stated for public APIs
• [ ] Security review scheduled before customer commitment on custom auth

RFP, PoC, and handoff

Table of contents

1. RFP and RFI response 2. PoC charter 3. PoC vs production gap list 4. Delivery handoff 5. Handoff package contents 6. Post-handoff support model

RFP and RFI response

Process:

1. Parse RFP into requirement IDs (mirror customer numbering where possible) 2. Assign owner per section (architecture, security, ops, commercial) 3. Draft compliant answers; mark partial or future explicitly 4. Cross-check traceability matrix (requirement → response → evidence) 5. Red-team for over-commitment; security and legal review per policy 6. Final consistency pass (terminology, diagrams, pricing alignment)

Structure per requirement:

Ref: RFP 4.3.2
Requirement: [quote or paraphrase]
Response: Compliant | Partial | Non-compliant | Alternative
Solution approach: [how]
Evidence: [diagram, cert, PoC plan]
Dependencies: [customer action, third party]

Differentiate standard product vs custom scope; custom items need effort estimate and risk flag.

Executive summary: outcomes, differentiators, implementation approach, risks, assumptions.

PoC charter

A PoC proves specific hypotheses, not full production.

Technical spikes — list experiments (e.g., IdP federation, 10k TPS load, CMK).

Live build and demo execution → collaborate with sales-engineer. Infra for PoC only → infrastructure-engineer if non-trivial.

PoC vs production gap list

Maintain a visible gap register:

Use gaps to right-size statements in RFP and contracts.

Delivery handoff

Hand off when:

• Requirements baseline approved (or change process agreed)
• Target architecture accepted with logged open ADRs
• PoC outcome documented (if applicable)
• Security gaps have owners and target dates
• Backlog seed and milestone sketch accepted by delivery lead

Handoff meeting agenda:

1. Walk context and success criteria 2. Review architecture and interface catalog 3. Review requirements and traceability 4. Review gap register and RAID 5. Agree first sprint / wave scope and environments 6. Confirm escalation and change control

Program-scale coordination → technical-program-manager.

Handoff package contents

Post-handoff support model

Define architecture owner during build:

• Office hours for clarification (not day-to-day PM)
• ADR decisions for scope changes
• Review of material integration or security changes
• Customer-facing review before major milestones

Avoid becoming the delivery PM—escalate schedule and dependency tracking to technical-program-manager.

Return to solutions architect for phase 2 design, expansion regions, or new RFP modules.

Security and compliance fit

Table of contents

1. Purpose and limits 2. Fit assessment workflow 3. Control mapping 4. Common frameworks 5. Questionnaires and evidence 6. Gap and mitigation format

Purpose and limits

Produce a technical fit assessment: how the proposed solution supports customer obligations and your product controls.

• In scope: architecture-level controls, data flows, encryption, identity, logging, residency, shared responsibility
• Out of scope: legal interpretation, contract language, formal audit opinion, pen test execution

Route legal terms → commercial-counsel. SOC 2/ISO evidence packs → compliance-engineer. Cloud guardrail implementation → cloud-security-engineer.

Fit assessment workflow

1. Inventory obligations — frameworks, customer policies, RFP security section, data classifications 2. Map solution — components, data stores, trust boundaries, admin paths 3. Map controls — product native, config required, customer responsibility, gap 4. Threat skim — STRIDE-lite on key flows (auth, admin, integration, data export) 5. Document gaps — mitigation, roadmap, or acceptance with risk owner 6. Review — security architect / cloud-security-engineer before external commit

Control mapping

Use a consistent table:

Status values: Met | Partial | Gap | N/A (customer responsibility)

Align with shared responsibility model—state who configures, operates, and attests each control.

Common frameworks

Do not claim certification coverage beyond your organization's actual attestations.

Questionnaires and evidence

For SIG, CAIQ, customer security portals:

• Reuse approved answers from security/compliance team; do not invent new commitments
• Flag deltas where the proposed architecture differs from standard deployment
• Attach architecture diagrams and data-flow diagrams requested by questionnaire
• Track due dates and owners in engagement RAID (with technical-program-manager if program-scale)

Evidence types delivery may need later: pen test summary, SOC report, subprocessors list, encryption whitepaper.

Gap and mitigation format

Gap ID: GAP-001
Control: Customer requires customer-managed keys for all DBs
Current: Platform-managed keys in PoC
Risk: Medium — contractual blocker for production
Mitigation options:
  1) Enable CMK integration in phase 1 (effort: X weeks)
  2) Accept platform keys with supplemental controls (legal review required)
Decision needed by: [date] — Owner: [name]

Escalate Gap items that block signature or go-live before solution approval.

Cloud-specific threat patterns and guardrails → cloud-security-engineer. Enterprise security program → information-security-engineer.

Sizing, cost, and options

Table of contents

1. Sizing approach 2. Cost framing 3. Build vs buy vs partner 4. Option comparison template 5. Licensing and commercial 6. Sensitivity and ranges

Sizing approach

Start from requirements and usage, not vendor SKUs.

1. Workload profile — steady vs bursty; batch windows; geographic distribution 2. Capacity drivers — users, transactions/sec, storage GB, API calls, messages 3. Growth horizon — 12–36 months; state growth rate assumptions 4. Redundancy — HA, DR, multi-region (multiplier on cost and ops) 5. PoC vs prod — right-size PoC; list what changes at scale

Document formulas or rules of thumb (e.g., 50 RPS × 200ms × 2 instances headroom).

Hands-on rightsizing and CUR analysis → finops-analyst. Deep TCO/NPV → cloud-economist.

Cost framing

Present ranges, not false precision.

Cost drivers table — top 5 levers that move the estimate ±20%.

Align currency, term (monthly vs annual), and who pays (customer cloud account vs vendor-hosted).

Cloud architecture cost pillar → collaborate with cloud-architect. GL and capex → compute-accounting-manager.

Build vs buy vs partner

Recommend one primary option with explicit when to reconsider (e.g., after PoC metrics).

Non-technical portfolio prioritization → business-consultant.

Option comparison template

Weight dimensions to customer-stated priorities (cost vs speed vs risk).

Licensing and commercial

Clarify for procurement (do not negotiate legal terms):

• Metric (users, cores, transactions, environments)
• Tier breaks and overage
• Dev/test licensing
• HA/DR doubling rules
• Third-party embeds (maps, AI APIs, data providers)

Flag architecture choices that change license count (e.g., extra regions, read replicas, sandboxes).

Sensitivity and ranges

Show low / expected / high for:

• Usage growth ±50%
• HA/DR on vs off
• Commit vs on-demand cloud pricing
• Implementation overrun (weeks)

State break-even triggers where a more expensive option becomes cheaper (scale, risk reduction).

For deal economics and margin, involve finance/sales; do not invent discount authority.

Solutions architect scope

Table of contents

1. Role definition 2. Engagement types 3. Inputs and outputs 4. Stakeholders 5. Boundaries vs peer skills 6. Engagement checklist

Role definition

The solutions architect owns technical solution design for a defined customer, partner, or internal initiative:

• What problem is being solved and for whom
• How systems integrate and what the target experience is
• Whether the solution fits security, compliance, and budget constraints
• What to prove in a PoC and what delivery needs to build next

You produce decision-ready artifacts for executives, procurement, security, and engineering—not production runbooks or legal contracts.

Engagement types

Inputs and outputs

Collect early:

• Business drivers, timeline, budget envelope (even rough)
• Existing systems inventory, data classifications, regions
• Security/compliance obligations (framework names, questionnaires)
• RFP/SOW language, mandatory requirements, evaluation criteria
• Named stakeholders (business owner, IT, security, procurement)

Deliver:

Stakeholders

Align on decision owners for architecture choices before deep design.

Boundaries vs peer skills

Engagement checklist

• [ ] Charter signed: objective, scope, out-of-scope, timeline
• [ ] Stakeholder map and interview plan
• [ ] Access to existing diagrams, inventories, RFP, security questionnaires
• [ ] Success criteria agreed (measurable for PoC or phase 1)
• [ ] Escalation path for blockers (security, legal, pricing)
• [ ] Definition of done for design phase and handoff recipient named