Solution Architecture

Architecture is a high level view of a system in the context of its environment, dependencies and technology. Architecture describes structure, behavior, integration and aesthetics.

Architecture must be solid, useful and beautiful.

In HSD the Architecture View encompasses Enterprise, Solution and System Architecture.

Solution Architecture applies architecture principles and practices, addressing structure, behavior and aesthetics, to a related set of products (or Product Family) that collectively generate Business Value through their end-to-end use.

Solution Architecture is normally focused on the system-of-systems nature of a programme of work – the challenge being to ensure that separately developed systems (maybe including out-sourced or COTS systems) join up correctly to deliver business value. If the work in question is not a system of systems and is instead a single system (with or without some external integration) then no matter how large it is there is no Solution Architecture, just System Architecture. A Solution is a combination of Products that, on their own, deliver Business Value, but when used in combination deliver more significant Business Value.

A Solution is a combination of Products that, on their own, deliver Business Value, but when used in combination deliver more significant Business Value. Be careful not to confuse a Product with constituent components (even if they are branded differently) as a Solution. Components don’t deliver Business Value outside of the context of a Product whereas Products outside of a Solution still deliver Business Value. Sometimes Solutions will evolve out of opportunities only made available from constituent Products. In our experience, Solution Architecture is one of the most poorly understood fields.

When delivering a complex COTS Implementation, the primary “product” may be Business Change, in which case a Solution Architecture may be considered in the context of related Adoption & Business Change and other communication activities that must work together to achieve Business Value. Although a Solution Architecture is normally a technical systems of systems concern.

To derive a technical Solution Architecture, we initially shape an architecture using an Architectural Profile derived from the early scoping requirements (consisting of Features and Integration Scenarios perhaps on a Programme Backlog). Architectural Profiling is also used at system (or product) level and so constituent system architecture profiles will align broadly with the profile used at Solution Architecture level. Specific systems might be targeted at de-risking part of a Solution Architecture profile and so it is not unusual for lower level systems to have profiles that do not exactly match.

Architectural Profiling is a method of understanding the relative complexity of different areas of concern for an architecture.

Architecture addresses a number of concerns and so a useful early approach is to consider the profile of the architecture in terms of the relative complexity of each of these areas. This helps to give a feel for the shape of the requirements, architecture and overall solution. We can also identify possible areas in which we can reuse existing components, frameworks or maybe standard packages of requirements, components and tests. Architectural profiles may be useful at any level of architecture (Enterprise, Solution and System) and are useful to understand areas of complexity in the requirements space, especially for understanding the relative complexity of non-functionals.

Solution Architecture exists within the context of an Enterprise Architecture and shapes lower level System Architectures. Various modeling languages can be useful in this space such as BPMN, workflows based on SIPOC and some elements of UML or simple activity workflow diagrams. As always in Holistic Software Development we do not recommend slavishly following standards, instead we recommend using elements from appropriate toolkits to communicate as effectively as possible. In our experience a rich picture, not too focused on symbology, is more beneficial.

Solution Architecture is not simply system architecture scaled up, or Enterprise architecture scaled down. It is often concerned with higher complexity than system architectures due to more integration, more moving parts, more concurrency and more distribution. It is also more requirement driven than Enterprise Architecture, focusing on producing Business Value and so is more specific than common technology choices and standards.

Understanding, and communicating, a valid Solution Architecture is a key part of achieving the Product Family De-Risked Milestone.

Solution Mechanisms

Solution Mechanisms are:
  • Common solutions to common problems for the Product Family
  • Ways of addressing primary Solution Risks
  • Ways of reducing significant Solution complexity
  • Examples of how a system-of-systems communicates and achieves end-to-end value
Solution Mechanisms focus on how a system-of-systems will work together and so is concerned with communication, integration, cross-product User Experience and distribution. Standard non-functional dimensions, normally addressed at system level, may also need special attention at Solution level. For example, the performance characteristics of a single system may not still meet requirements when it’s operation is federated across geographical areas with output combined by a different system before presentation.
Splitting a Solution Architecture into a number of Solution Mechanisms enables iterative and incremental development of Solution Mechanisms, although they are often cross-cutting in terms of the functional requirements.
One of the biggest “common problems” in a Solution is integration. Common choice of integration technologies is useful in ensuring a common development paradigm within a product family. Products within a Product Family may employ different system architectures, and even be written in multiple languages, but will need to communicate with each other and make use of common services. As a result, they need to be able to talk the same language in terms of integration. We recommend the use of standard technologies with low (or no) dependencies such as JSON over http rather than complicated orchestration engines and proprietary binary formats.
Sometimes these integration standards will come from Enterprise Architecture, but if they do not, and would add value in a Solution they should be created. In fact, proof of usefulness in a Solution may prompt adoption at Enterprise level depending on the Enterprise diversity.
Solution Architectures will often describe architectural mechanisms and features related to concerns such as:
  • Common data models, formats or containers
  • Messaging technologies
  • Composite transactional mechanisms
  • Large scale architectural patterns (e.g. SOA, hub and spoke, etc.)
  • Distribution mechanisms and target deployment topologies
  • Common logging or audit mechanisms
  • Common authentication
  • Elastic architecture principles to enable cloud deployment
Similarly, the chosen technology stack, if not constrained by Enterprise Architecture, should be described as part of the Solution Architecture.
Solution Mechanisms, like most architectural concerns are best described in terms of structure and behavior.


Solution Architecture is best described in terms of both structure and behavior. Structural views will tend to be at a higher level than those in System Architecture as they will be less concerned with system internals and more concerned with system dependencies, interfaces and deployment. In many ways a Solution Architecture diagram is essentially a zoomed out Architectural Overview diagram.

We recommend largely dispensing with UML or other standard symbology and rules when describing solution architecture, instead focusing on communicating as clearly as possible the relationships between users, systems and interfaces. We can often use a single structural view for many mechanisms. Don’t create lots of diagrams if you don’t need to.

In the anonymized example diagram below we’re identifying different types of users that interact with different Products and primary interfaces between layers. In this case the Solution was a news aggregation platform, the lower layer was textual and the upper level was creative User Experience based on a number of platforms. There’s also some interfacing to external systems indicated at the bottom of the stack. We’ve actually used some UML symbology but we’re using more color and layering than the rules allow.

We recommend annotating structural diagrams like the above with deployment information in terms of technology stacks, elasticity requirements and other platform information. This specific example was simply https everywhere, platform information and elasticity was already well understood based on Enterprise Architecture.


We can describe the behavior of functional Solution Mechanisms in terms of the requirements it implements, in HSD, these take the form of Integration Scenarios which often provide a graphical view of behavior. Annotating Integration Scenario diagrams, or simply linking elements on them to more technical diagrams works well.

For non-functional Solution Mechanism we recommend creating a simple workflow based diagram, that represents the flow of events, data or control as appropriate.

The point of behavior diagrams at this level is to explain what each contributing Product or System is meant to do, and how they’re expected to communicate with each other. A rich picture that resonates with business process, like a graphical Integration Scenario diagram, is a good option.

In either case it can sometimes be useful to overlay the most important of these on top of a structural diagram. The most important purpose of a Solution Architecture is to explain end to end flows through the system.

Integration Scenarios describe an end-to-end workflow across a Product or Product Family resulting in Business Value for a Product Customer in flexible format.
Integration scenarios are threads across a number of other requirements such as Features and User Stories that don’t deliver Business Value on their own. They are ideally suited to describing the scope of Releases and providing the input for integration testing, necessary to achieve higher levels of acceptance.
Integration Scenarios can also be used to manage cross-cutting Non-Functional Requirements and drive the discovery of Architectural Mechanisms.
Integration Scenarios provide the context for discussions around User Stories.

Level of Detail

Many programmes will be tempted to elaborate Solution Architecture to a significant level of detail, and drawing the line where Solution Architecture ends and System Architecture begins can be difficult. Overlap between Solution and System architecture can cause conflict and confusion. It is not the jobof Solution architecture to connect every bit of system level information, or to design every part of every system.

Solution Architecture needs to describe:

  • Overall structure of the system of systems
  • The implementation of key integration scenarios
  • Architectural standards to be followed for the programme (such as technology choices, frameworks, data schemas etc. where not provided by Enterprise Architecture)

Solution Architecture should not describe any elements internal to subordinate systems and so should be as lightweight as possible. Spending more effort on describing testable Integration Scenarios, and automating integration, is worth more than architectural modeling at a Solution level.

Executable Solution Mechanisms

The best Solution Mechanism are built in terms of executable code so that contributing teams can simply pick them up and integrate to them. Solution Mechanisms need to be proven through use, and changed in line with feedback as soon as possible to mitigate risk.