Solution Architecture Overview

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.

A full list of all articles in this category, with summaries and learning points, is available at the following page.

Solution Architecture — Article Indexen.senkohome.com/arch-intro-index-solution/

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:

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.

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.

Pushing forward without NFRs leads to the post-launch “slow!” “down!” firestorm.

What you must decide 1: requirements side

What you must decide 2: design side

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 — 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.

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:

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.

Knowledge structure of this category

This category is composed of 5 articles in total. The structure follows the lifecycle of a project.

These 5 articles directly mirror the steps a solution architect takes on a real project. Grasp the big picture in the overview, organize the problem in requirements, numerize quality in NFRs, demonstrate investment return in ROI, and validate uncertainties in PoC — this flow is the actual work process.

You can start midway, but learning NFRs or ROI without understanding requirements discipline tends to produce fragmented knowledge missing its prerequisites. If time is short, covering just the overview (this article) and the requirements article gives a base that makes the remaining three far easier to absorb.

Architecture-level traps

Solution architecture is don’t hit with tech, hit with numbers. A reasonable answer within constraints saves the field.

AI decision axes

1. Present multiple options for comparison — minimum 3; one option cannot be judged optimal
2. Numerize NFRs at the start — don’t defer performance, availability, security
3. Mind Buy / Build / Subscribe — leverage SaaS; in-house only for differentiating areas
4. Show ROI in numbers — get approval through cost-benefit; vague effects don’t pass

AI made multi-option comparison realistic

The most time-consuming step in a solution proposal is “produce 3 options and build a comparison table.” Traditionally, even one option took weeks to design, so options 2 and 3 were often copies of past examples.

What AI coding tools changed is the speed of initial prototype construction. For a SaaS-combination option, a fully managed option, and an OSS-self-build option, AI can generate the tech-architecture diagram, rough cost estimate, and migration-step skeleton in a few hours. The human job shifts to “what axes to compare on” and verifying feasibility of the generated options against on-the-ground knowledge.

That said, AI’s comparison options skew toward typical configurations from training data. Company-specific constraints (existing contracts, org structure, regulations) aren’t reflected unless humans explicitly supply them as conditions. Don’t throw “give me 3 options” wholesale — hand over the constraint list first, then generate.

SaaS + API-first is the precondition for AI utilization

In Buy / Build / Subscribe decisions, the AI era further strengthens the advantage of Subscribe (SaaS). The reason is straightforward: major SaaS products have thorough API documentation, and AI can generate integration code directly.

A custom-built system has virtually no documentation AI can reference. Every maintenance and extension cycle requires a human to read the full context, leaving the team behind on AI-era productivity gains.

Build only the differentiating areas; combine SaaS APIs for everything else — this design maximizes AI benefits. When writing proposals, be aware that the burden of explaining “why we need to build this in-house” has gotten heavier.

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 raises pass rates significantly. 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.