About this article
This article is the first article in the “Solution Architecture” category of the Architecture Crash Course for the Generative-AI Era series, covering solution architecture at the survey level.
If EA is “the map,” solution architecture is the driving route for an individual project. It’s the design domain that takes business requirements, existing systems, and EA direction into account, and derives the optimal answer within the constraints of budget, schedule, and organization. This article surveys the difference from EA, the practical flow from requirements to PoC, and the responsibilities and toolkit of a solution architect.
What is solution architecture in the first place
Imagine an architectural firm. The architect listens to the client’s “I want to live in a house like this,” considers the budget, land constraints, and building codes, and draws the best feasible blueprint. That’s the architect’s job.
Solution architecture is architectural design for IT. It’s the domain of deriving optimal technical design within the constraints of budget, schedule, and organization, informed by business requirements, existing systems, and EA direction. If EA is “urban planning (the big map),” solution architecture is “the blueprint of an individual building.”
Without solution architecture, engineers start implementing without correctly understanding requirements, and after completion comes the rework of “this isn’t what we asked for.”
Why treat it as a separate architecture
Translating business requirements into tech is a specialty
What the business wants is “a mechanism that grows revenue,” not technology. Translating requirements into technical design is its own specialty.
Integration with existing systems is non-negotiable
Even individual projects must connect to existing auth, DB, and network. Greenfield projects are rare. Most of the design is about how to plug into existing things.
Constraints (budget, schedule) shift the optimal answer
The “ideal design” is a fantasy that assumes infinite budget and time. The solution architect picks the most rational design within constraints.
What a solution architect does
Lined up over time:
| Phase | Main work |
|---|---|
| Requirements interviews | Capture business problems, user persona, scale |
| Current-state analysis | Existing systems, constraints, organization |
| High-level design | Multiple options proposed, compared, selected |
| Detailed design | Component split, data flow, API design |
| Estimation | Effort, cost, schedule |
| Implementation support | Tech-issue consultation, design review |
| Post-launch review | Were the original judgments correct? |
The defining trait is involvement across all phases — not just “requirements” or just “design.”
Typical design process
Solution architecture standardly proposes multiple options and picks one. With a single option, you cannot judge whether it’s the optimum. At least 3 options for comparison is the rule.
flowchart LR
REQ([Business requirements])
A[Option A: SaaS<br/>ServiceNow / kintone<br/>$10k init / 1 month]
B[Option B: Low-code<br/>Power Platform / Glide<br/>$30k init / 3 months]
C[Option C: Full custom build<br/>$200k init / 1 year]
EVAL{Evaluation<br/>Cost / time /<br/>customizability / risk}
PICK([Pick the best option])
REQ --> A --> EVAL
REQ --> B --> EVAL
REQ --> C --> EVAL
EVAL --> PICK
classDef req fill:#fef3c7,stroke:#d97706;
classDef opt fill:#dbeafe,stroke:#2563eb;
classDef eval fill:#fae8ff,stroke:#a21caf;
classDef pick fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
class REQ req;
class A,B,C opt;
class EVAL eval;
class PICK pick;For a request like “build an internal approval workflow,” three plausible options:
- Option A: Adopt SaaS (ServiceNow, kintone).
- Option B: Cloud low-code (Power Platform, Glide).
- Option C: Full custom build internally.
Lay out initial cost, run cost, customizability, time, and risk for each, and pick with the customer in the room. If A is $10k / 1 month and C is $200k / 1 year, revisiting the requirements to fit A is the wise call.
Functional vs Non-Functional Requirements
The most important thing in solution architecture is defining the non-functional requirements. Functional requirements are something the business can write; non-functional requirements (performance, availability, security, operations) require a specialist. This is where solution architects shine.
| Type | Substance | Examples |
|---|---|---|
| Functional | What the system does | Submit, approve, notify |
| Performance | How fast | Response < 3s, 100 concurrent users |
| Availability | How rarely it goes down | 99.9% / max 43 min/month |
| Security | How protected | MFA (Multi-Factor Authentication) required, audit logs retained 7 years |
| Operations | How operated | 24/7 / business hours only |
| Scalability | How far it can grow | 10x traffic |
Pushing forward without NFRs leads to the post-launch “slow!” “down!” firestorm.
What you must decide 1: requirements side
| Item | Examples |
|---|---|
| Problem to solve | Operational efficiency / new business / cost reduction |
| Scope | Minimum / full feature set |
| Target users | Internal / customers / external partners |
| Scale | 10 / 1k / 1M users |
| Budget | Initial / operational / period |
| NFR targets | Performance, availability, security |
What you must decide 2: design side
| Item | Examples |
|---|---|
| Buy / Build / Subscribe | Off-the-shelf / in-house / SaaS |
| Cloud / on-prem | AWS / Azure / GCP / private DC |
| Existing-system integration | API / file / event |
| Auth platform | Use existing SSO (Single Sign-On — one auth across multiple services) / build new |
| Data management | New DB / shared with existing |
| Operating model | In-house / outsourced |
ROI and estimation
The solution architect is also responsible for ROI (Return on Investment). Without showing how much money this investment will produce, the project doesn’t get approved.
For “digitizing the approval workflow,” for example:
- Investment: $50k initial + $10k annual operating.
- Effect: 500 person-hours/month saved × $30/hr × 12 months = $180k saved annually.
Show 3-year payback / multiple-x return at 5 years. Vague effects don’t pass approval, so numerically demonstrating ROI is one of the solution architect’s important jobs.
Designing the technology isn’t enough. Speaking in numbers is what makes you fully qualified.
When to use a PoC
Where solution architecture has uncertainty, do a PoC (Proof of Concept) — try it small. The PoC is a tool to validate only the central question before building everything; the goal is to fail fast and course-correct.
What the PoC validates is not “is this technically possible?” but “does this have business value?” Technically possible without business utility is meaningless.
| Validate in PoC | Don’t validate in PoC |
|---|---|
| Performance and quality of unknown tech | Fine specs of known tech |
| User reaction, business effect | Detailed UI design |
| Data quality and volume | Already-validated configurations |
Design depth by project size
Solution architecture’s depth and effort vary with project size. Up front: at least 20% of total project effort goes to requirements at mid+ scale. Cutting corners here costs 10x downstream. The industry-standard ladder:
| Size | Budget | Requirements effort | Output | Buffer |
|---|---|---|---|---|
| Small (< 3 months) | < $100k | 1-2 weeks (~10%) | User stories + Figma | +10-20% |
| Mid (6-12 months) | $100k-$1M | 1-3 months (15-25%) | Requirements doc + BPMN | +20-30% |
| Large (1-3 years) | $1M-$10M | 3-6 months (25-30%) | AS-IS / TO-BE detailed + multiple PoCs | +30-50% |
| Very large (3 years+) | $10M+ | 6-12 months (>30%) | Multi-stage requirements + industry certifications | +50-100% |
The ROI numeric gate: payback within 3 years, 3-year ROI of 100%+. Estimate as a range, not a point — “$300k-$450k, +50% buffer” is the format that builds trust.
Match design depth to scale. Large-scale methods on a small project are over-investment; the reverse burns the project.
Architecture-level traps
| Forbidden move | Why |
|---|---|
| Requirements without on-site observation, interviews only | The Target Canada 2015 pattern ($2B exit loss) |
| Putting only one option in the proposal | Cannot compare; minimum 3 is the rule |
| Deciding functional only, deferring NFRs | Post-launch “slow! down!” firestorm |
| Estimating with a point figure | Government-system rebuild $300M -> $1.2B; estimate as a range |
| Numerizing every qualitative effect | Forced numerization erodes trust; parallel listing is honest |
| Starting without a PoC Go/No-Go criterion | The “it kind of worked” vague-color report |
| Computing ROI without counting AI-utilization gains | 30% reduction in operating time directly affects it; recompute with AI as the assumption |
| Tech-logic-only proposals | Crashes at executive board: “so how much money do we make?” |
| Waterfall without staged release | New business and AI utilization fail without flexibility |
| No upper bound on PoC duration | Goes on forever — “feels like we’re close” drags 6 months extra |
| ”Pitch the latest tech and it’ll fly” — overconfidence | Latest tech carries info/talent shortage risk; the most reasonable design within constraints is the actual job |
| ”Just pitch one option” — cutting corners | Cannot compare; at least 3 options is the rule |
Solution architecture is don’t hit with tech, hit with numbers. A reasonable answer within constraints saves the field.
AI decision axes
| AI-era favorable | AI-era unfavorable |
|---|---|
| Requirements you can define with numbers | Vague “make it nice” requirements |
| Designs that combine SaaS and mainstream tech | Custom implementation, full custom builds |
| NFRs numerized at the start | Performance / availability deferred |
| Staged release (PoC -> MVP -> production) | Big-bang waterfall release |
- Present multiple options for comparison — minimum 3; one option cannot be judged optimal
- Numerize NFRs at the start — don’t defer performance, availability, security
- Mind Buy / Build / Subscribe — leverage SaaS; in-house only for differentiating areas
- Show ROI in numbers — get approval through cost-benefit; vague effects don’t pass
Author’s note — “tech-logic-only proposals” crashing at the board
Walking into the executive board with a beautifully technical proposal and getting flattened by “so how much money do we make?” is a recurring failure on the proposal frontline.
Architecture diagram, tech-selection rationale, performance analysis, migration risk all perfect — without a single line of cost-benefit math, approvals don’t go through. The board’s decision axis is “how many dollars saved per year” and “how many dollars earned”, not technical merits.
The field saying “hitting with tech doesn’t pass approval. Hit with numbers,” captures it. Putting an “annual savings / earnings” slide first reportedly multiplies pass rates. As much as you train the quality of technical design, training to speak in numbers is what separates solution architects in skill.
Summary
This article surveyed solution architecture — multi-option comparison, NFRs, ROI, PoCs, design depth by project size, and the AI-era role shift.
Compare multiple options, numerize NFRs, mind Buy/Build/Subscribe, show ROI in numbers. The realistic answer for 2026.
The next article covers bridging requirements to design — the discipline and pitfalls of requirements definition, from on-site observation, 3-option comparison, and traceability angles.
Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book
I hope you’ll read the next article as well.
📚 Series: Architecture Crash Course for the Generative-AI Era (75/89)