Solution Architecture

Solution architecture (within or without enterprise architecture) is a combination of role, process and documentation that is intended to address specific problems and requirements, usually through the design of specific information systems or applications.

The term solution architecture can be used to mean either or both:

• Documentation describing the structure and behaviour of a solution to a problem, or
• A process for describing a solution and the work to deliver it.

The documentation is typically divided into broad views, each known as an architecture domain.

Where the solution architect starts and stops work depends on the funding model for the process of solution identification and delivery. E.g. An enterprise may employ a solution architect on a feasibility study, or to prepare a solution vision or solution outline for an Invitation to Tender. A systems integrator may employ a solution architect at “bid time”, before any implementation project is costed and resourced. Both may employ a solution architect to govern an implementation project, or play a leading role within it.

Typical outcomes of solution architecture.

Solution architects typically produce solution outlines and migration paths that show the evolution of a system from baseline state to target state.

A solution architect is often but not always responsible for design to ensure that the target applications, in a technical architecture, will meet non-functional requirements.

Solution architecture often but not always leads to software architecture work^[1] and technical architecture work, and often contains elements of those.

A solution architecture may be described in a document at the level of a solution vision or a more detailed solution outline. It typically specifies a system (itself usually a subsystem in a wider enterprise system) that is intended to solve a specific problem and/or meet a given set of requirements. It may be an IT system to support a single business role or process. For example, an end-to-end eCommerce system that allows customers to place orders for goods and services; or an end-to-end Supply Replenishment system that enables an enterprise to order new stock from its suppliers.

A solution outline typically defines the business context, business data to be created or used, the application components needed, the technology platform components needed, along with whatever is needed to meet non-functional requirements (speed, throughput, availability, reliability recoverability, integrity, security, scalability, service ability, etc.).

The term solution architecture is widely used outside of an enterprise architecture context. It is also used in some enterprise architecture (EA) frameworks, with particular meanings. In TOGAF it can mean the physical implementation of a logical architecture, or a detailed software architecture. In US government guidelines, it is pitched at the bottom level of a stack below "enterprise" and "segment" architectures, as shown in the diagram below.

Relationship of solution architecture to enterprise architecture in FEA. 

In other contexts, a wide range of stakeholders, even business owners, may be concerned to review a solution vision or solution outline and monitor progress towards implementation.

Generally speaking, an enterprise architect’s deliverables are more abstract than a solution architect’s deliverables. But that is not always the case. The main distinction between enterprise architect and solution architect lies in their different motivations.

The solutions architect is primarily employed to help and support programme and project managers in the design, planning and direction of specific implementation projects. The enterprise architect has more strategic and cross-organisational concerns, and strives to optimize solution delivery across the organization.

The work of a solutions architect may or may not be governed by an enterprise architecture function. The influence of the enterprise architect team on solution architects depends on an organisation’s policies and management structure. So, the extent to which a solution architect’s work realises an enterprise architect’s road maps will vary widely in different contexts.