Solution Architecture

How Solution Architecture Works

A Solution Architecture should not begin with technology, but with a defined problem.
First, there must be sufficient understanding of what is to be achieved, which requirements and constraints exist, and which existing systems or processes are affected.
Only on this basis can it be assessed whether and how a possible solution addresses the problem and its constraints.

A Solution Architecture can include, for example:

• existing and new systems
• software components and services
• data and data flows
• interfaces and integrations
• networks and technical infrastructure
• security mechanisms
• operational processes
• migration and transition solutions
• external providers and services

Which of these areas are relevant depends on the particular task.
The Solution Architecture then describes the essential relationships between these elements and the fundamental decisions necessary to implement the solution.

From Problem to Solution

A problem does not automatically determine its technical solution.
If, for example, data from an old system is needed in a new application, there can be different options: The old system can be extended, an interface can be created, an export can be used, a data migration can be performed, or the system can be replaced completely.
Before one of these alternatives becomes the architecture of the solution, its effects and constraints must be examined.

These include, for example:

• Which existing systems are affected?
• Which dependencies exist?
• Which data must be preserved?
• Which interfaces already exist?
• Which security and operational requirements apply?
• Must the transition take place during ongoing operation?
• Which parts of the existing environment can remain unchanged?
• Which risks arise from the respective alternative?

A Solution Architecture is therefore not merely a drawing of the desired target structure. A description of the Solution Architecture documents fundamental decisions about how a concrete problem is to be solved technically.

Why Solution Architecture Has Practical Effects

• Problem and technology are connected: Requirements and constraints are translated into an implementable technical structure.
• Existing systems are taken into account: A solution does not necessarily have to replace everything that already exists.
• Dependencies become visible: Systems and interfaces involved can be considered together.
• Alternatives can be compared: Different solution approaches can be examined before implementation.
• Migrations can be part of the solution: Not only the desired end state, but also the path to it can be taken into account.
• Implementation details remain separable: Fundamental architectural decisions can be made without anticipating every technical detail.

A Solution Can Also Be Small

The term Solution Architecture is often associated with large enterprise systems and extensive architecture diagrams.
The underlying task, however, does not depend on the size of a project.
Even a small technical change can affect multiple systems or constraints.
For example, if an existing program is to transmit data to a new service, the relevant Solution Architecture may consist only of the existing program, an interface, a data format, and the new service.
What matters is not the number of components, but whether their relationships and the fundamental decisions for the concrete problem are understood and traceable.
Likewise, the most sensible solution can be to introduce no new component if the problem can be adequately solved with the existing system.

Typical Example

A company wants to replace an old inventory management system.
Several other applications access its data, however. Some use documented interfaces, others regular exports. In addition, manual workflows have developed over the years around the existing system.
Systems Analysis can first help examine these relationships and dependencies.

On this basis, a Solution Architecture can, for example, provide for:

• introducing the new inventory management system,
• initially continuing to operate existing applications,
• providing the required interfaces again,
• migrating data incrementally,
• operating old and new components in parallel for a limited period
• and changing individual manual workflows only in a later step.

The Solution Architecture therefore describes not only the new product, but the interaction of all elements relevant to the concrete transition.

Distinction

• Solution Architecture is not the same as System Architecture. System Architecture describes the fundamental structure of a system with its elements and relationships. Solution Architecture, by contrast, begins with a concrete problem or set of requirements. The resulting solution can involve multiple systems and their architectures.
• Systems Analysis also has a different task. It examines an existing or possible system, its properties, relationships, and alternatives. Its results can provide a basis for a Solution Architecture.
• System Integration, in turn, concerns connecting different components or systems so that they work together as the desired overall system. Integration can therefore be an essential part of a Solution Architecture.

The boundaries between these terms are not always sharp in practice. Depending on the organization, project, and methodology used, tasks and responsibilities can overlap.

Further Reading

Related Concepts

→ Systems Analysis
→ System Architecture
→ System Integration
→ Interface
→ Verification and Validation
→ Legacy System
→ Legacy Modernization