Solution Architecture: From Strategy to Design

Solution architecture is often asked for a cost before it has enough information, and answering badly is how credibility is spent. The useful posture is to price the unknowns rather than the whole: here is the range, here is what would narrow it, and here is the smallest spend that resolves the largest uncertainty.

Four questions separate a plausible estimate from a wish. Which integration is least understood, and what would a spike cost to resolve it? Which non-functional requirement is most likely to force a re-architecture? Which third party controls a dependency and what is their lead time? And what is the migration path for existing data, which is where most underestimated work hides.

The architectural contribution is a risk-adjusted estimate with the assumptions visible, plus a first increment that buys information. Organisations that fund discovery before commitment make better decisions than those that fund a plan and discover the truth during delivery, and the difference is usually a few weeks of a small team.

Performance gets the attention; five other requirements decide whether a solution survives its first year. Availability, expressed as an allowed downtime budget rather than a percentage nobody believes. Recovery, expressed as how long and how much data lost. Data residency and retention, expressed as what may exist where and for how long. Accessibility, expressed as a standard to meet. And operability, expressed as what support staff must be able to see and do.

Each needs a number and a test, or it is a preference. An availability target without an error budget cannot be traded against cost or complexity. A recovery objective without a rehearsed restore is an aspiration. A residency requirement without an inventory of where data flows is a claim that an auditor will test.

The architectural habit that catches them is to write the requirement, then write how it will be evidenced, before choosing a design. Solutions fail acceptance most often on requirements that were stated as adjectives, and the cheapest fix is a number, a test and an owner at the point the requirement is written.

The enterprise architect owns the structure that spans initiatives; the solution architect owns the structure inside one. That boundary is frequently blurred, and the blur costs time: solution architects escalate decisions that are theirs, and enterprise architects design things that delivery should decide.

The clearer statement of accountability is that a solution architect is responsible for the decision set that a delivery team cannot safely make alone: system boundaries, interfaces with systems they do not own, data ownership, non-functional targets, and any choice that is expensive to reverse. Everything else — internal structure, libraries, naming — belongs to the team.

The second accountability is fitness: whether the solution will still be appropriate in three years under the strategy that funded it. That requires holding two time horizons at once, which is what distinguishes the role from a lead developer, and it is why solution architects need enterprise context rather than only technical depth.

Most solution architecture begins with a proposed system and a document that justifies it. The more useful starting point is the outcome and the constraint: what must be true for this to succeed, what cannot change, and what has already been decided by someone else.

Four questions frame almost any solution. What outcome is being purchased, and how will it be measured? Which decisions are already fixed by enterprise standards, contracts or regulation? What currently does this job, and what happens to it? And what is the acceptable failure mode — refuse the transaction, queue it, or accept and reconcile later?

That last question is the one most often skipped and most often the source of redesign. A solution that assumes availability and discovers that the business will accept delay has built unnecessary complexity; one that assumes delay and discovers that a regulator requires immediate confirmation has built a liability.

Functional requirements describe what a system does; non-functional requirements determine what shape it can take. A latency target of forty milliseconds rules out a design; a target of four seconds does not. Most NFR lists are long, unmeasured, and consequently ignored.

The discipline is to specify only the quality attributes that would change a decision, with a number and a condition. Availability with a stated measurement window and a defined degradation behaviour. Throughput at peak with the growth assumption. Recovery time and recovery point objectives, since those determine data architecture. Security classification and the access model. Operability: what must be observable, and by whom.

Each should be traced to a test that will prove it. An NFR without a test is an aspiration, and it will be discovered as unmet in production. Where a target cannot be tested before go-live, the design should contain a fallback that makes failure survivable, which is a design decision the NFR should state explicitly.

The structural core of a solution architecture is small: what the solution owns, what it calls, what calls it, and where the data of record lives. Get these four right and most other decisions follow; get them wrong and no amount of internal elegance compensates.

Data ownership is the decision with the longest consequence. If the solution creates a second copy of a customer record, it has created a reconciliation obligation that will outlive the project. Where a copy is unavoidable — for performance, availability or vendor constraints — the architecture should state the direction of truth, the reconciliation mechanism and its frequency.

Interfaces deserve explicit contracts even inside one organisation: what is exchanged, in which direction, with what guarantees. A file drop with an agreed schema and reconciliation is a legitimate interface; an unagreed file that “has always been produced that way” is a latent incident. The architecture should name each interface and its owner.

Integration decisions inside a solution are usually simpler than enterprise integration and more consequential than teams expect. The first choice is synchronous or asynchronous, determined by whether the caller needs an answer to proceed, and the second is whether the solution should call a peer or consume a published event.

Three questions resolve most cases. Must the user wait? If yes, synchronous, with a timeout and a defined failure path. Is more than one consumer interested? If yes, publish an event rather than calling each. Does the producer need to remain available when the consumer is not? If yes, asynchronous by necessity rather than preference.

Whatever the choice, the solution must state its behaviour under failure: what happens when the peer is unavailable, how retries are bounded, whether operations are idempotent, and where the resulting state is visible to support staff. Solutions that omit this are the ones whose first incident is diagnosed by guesswork.

Most solution architecture involves a product rather than a blank page, and the architect’s leverage sits in the requirements pack and the evaluation rather than in the design. A requirement that no product satisfies and one that every product satisfies are both wasted; the useful requirements are the ones that discriminate.

The questions that matter in evaluation are rarely on the feature checklist. What is the upgrade path, and how many versions are supported? Which extension mechanisms are supported, and which will be broken by upgrades? Where does the product store data, and can it be exported completely? What does the vendor’s own roadmap assume about our integration approach? And what happens commercially if we need to leave?

The post-selection discipline is to keep customisation inside supported extension points and to hold the integration layer yourself. A product that is heavily customised is a build with a licence fee; it cannot be upgraded, and the vendor’s roadmap becomes irrelevant because you can never take it.

Almost every solution must coexist with a system nobody can modify. The architectural response is translation rather than negotiation: build an anti-corruption layer that presents the legacy system as the interface the solution needs, and keep all knowledge of the legacy’s peculiarities inside it.

This layer has three benefits beyond tidiness. It gives the solution a stable interface that can survive a future replacement of the legacy. It concentrates the awkward logic where it can be tested. And it creates the seam through which the legacy can eventually be retired, one capability at a time.

The cost is real: another component to operate and own. That is why the layer should be justified by expected change rather than by principle. Where the legacy will be replaced within the planning horizon, the layer is an investment in that replacement; where it will not, the layer is the only way to keep the integration comprehensible.

Solution architecture documentation fails in two directions: too much, so nobody reads it, or too little, so decisions are re-made in code review. The workable set is small and specific, and it is mostly about decisions and constraints rather than about design description.

Five artefacts cover most engagements: a context and boundary diagram with the interfaces named; a decision log with the irreversible choices and their rationale; the non-functional requirements with their tests; the data ownership statement; and the delivery constraints — standards, environments, approvals, and what the team must not do. Together these fit in a few pages.

The second half of the job is availability. A document without a person is an archive. The architect should be reachable for questions with a stated response commitment, attend the few ceremonies where decisions surface, and review the design once at the point where it becomes expensive to change. Presence, not documentation volume, is what makes architecture influential inside a delivery team.

A design review that inspects a document and issues findings produces compliance and resentment. A review that examines a decision under uncertainty produces better decisions, and it needs three conditions: the right people, a specific question, and a timing that still allows change.

The right people are those who will operate or inherit the solution. Operations engineers find failure modes that architects miss; support staff find usability and diagnosability problems; the data owner finds ownership ambiguities. Inviting them to one session early is worth more than three later reviews.

The specific question is what turns a review into a contribution. “Will this survive a doubling of volume without redesign?” and “If this interface fails at peak, what does the customer see?” are answerable. “Any comments?” is not, and it produces the two kinds of feedback nobody can act on: style preferences and general unease.

Performance requirements are the most frequently hand-waved and the most expensive to discover late. The discipline is to demand four numbers before designing: peak throughput, acceptable response time at the user-visible boundary, data volume and growth over the planning horizon, and the concurrency at peak.

With those, capacity design becomes tractable: identify the component that will saturate first, size it with headroom, and decide what happens when the headroom is consumed. That last decision is architectural — shed load, queue, or degrade a feature — and it is rarely stated, which is why systems fail by falling over rather than by slowing down gracefully.

The second requirement is a test that proves it. A load test at expected peak with the production data distribution, run before go-live, converts an assertion into evidence. Solutions without one are relying on the vendor’s benchmark, which was measured on different data in a different configuration.

A solution that works and cannot be operated has not been architected. Operability is a design property: whether a failure is visible, whether it is diagnosable, whether it can be safely restarted, and whether a support analyst can answer the question a customer is asking.

The design questions are concrete. What must be logged for a support analyst to reconstruct a customer’s journey, and is the correlation identifier present on every entry? What does the operations team see when the queue backs up, and can they act without calling an engineer? Can a failed process be replayed without duplicating effects? And what happens to in-flight transactions during a deployment?

Involving support staff in design review is the cheapest way to find these. They know which questions arrive at 9am on a Monday, and those questions define the observability the solution needs. Architectures that omit this produce systems where every incident begins with an engineer being paged to read a log.

An insurer needs a new claims intake capability: customers submit claims through a mobile app and a web portal, photographs included, with an initial triage decision within minutes and an adjuster assignment the same day. Two vendors can supply most of it; the existing policy administration system must remain the system of record for claims.

The first design proposes building intake in the new vendor product and integrating directly to policy administration for every claim, with the vendor holding a copy of policy data for validation. The review asks one question: what happens at month-end when the policy system runs its batch and is unavailable for two hours? The design would refuse claims, which is unacceptable for a channel that markets twenty-four-hour service.

The revised architecture accepts the claim, queues validation, and issues a provisional triage decision based on a cached policy summary that is refreshed hourly, with the definitive validation completing asynchronously and a stated reconciliation path for the small number of cases where the cache was stale. The vendor holds no policy data; validation runs through an interface the insurer owns. Cost is marginally higher and the failure mode is now designed rather than discovered. The design review question, not the framework, produced the difference.

The enterprise architecture courses include solution design exercises, options papers and design review simulations with model answers.