Solutions Architecture as a Solution Set

Overview

A Solutions Architecture is, at its simplest, a comprehensive and well-documented answer to a problem.

Unpacked further: it is the combination of things — data & information, tools & technologies, processes & procedures, roles & responsibilities, security, and answers to Non-Functional Requirements (NFRs), among others — and the relationships between them, deliberately chosen and arranged to produce the capability or outcome that resolves a given problem or set of problems.

The relationships matter as much as the things themselves. A system’s behavior emerges from how its components interact, not merely from which components were selected — two Solution Sets built from identical parts can behave very differently depending on how those parts are connected and depended upon.

A Solution Set is domain- and industry-agnostic: the same underlying concept applies whether the problem is a retail company modernizing a checkout system or a healthcare provider integrating a new clinical system. This is distinct from a Horizontal Solution, an existing EA Value Model term for a technology platform or capability multiple portfolios consume centrally — a Solution Set may be local to a single engagement or, in some cases, become a Horizontal Solution once adopted enterprise-wide, but the two terms describe different things.

A Solution Set also scales with the problem it addresses: it can be simple and scoped to a single technology or application, or complex and span many technologies and applications, depending on the size of the problem being solved. This is a direct corollary of the Solutions Architecture Framework’s own scalability, covered later in this document — the process scales, so the output scales with it.

Best Practice: Treat Comprehensiveness as Non-Negotiable

When assembling a Solution Set, deliberately account for every relevant SA Dimension — not just the technology dimension. A Solution Set that only addresses tools and technologies while ignoring necessary changes to processes, roles & responsibilities, or security is not comprehensive, regardless of how well-engineered its technical components are. The SA Dimensions chapter later in this document details these dimensions and how they relate to the specialized architecture practices Solutions Architecture draws upon.

Benefit(s)

Treating comprehensiveness as non-negotiable avoids a common and costly failure mode: a technically sound solution that fails in practice because it neglected a non-technical dimension of the problem — an unaddressed process gap, an unassigned responsibility, or an overlooked security or regulatory requirement. Comprehensiveness is also what grounds Solutions Architecture’s reputation for delivering real, complete answers rather than partial, technology-only fixes.