The Solution and Service Architecture Relationship

Whilst we might have a particular specialization at Everware-CBDI in all things SOA, most of the system integration/delivery projects we are engaged on are still solution focused. The delivery of services, organized into a service architecture may be central to the solutions we deliver, and the reason for our engagement, but the end result is still a solution in the conventional IT sense.

Following the recent delivery of a solution architecture class, I produced a new eLearning module for our Service Architecture Practitioner Syllabus, and part of that module is explored in this post, where I examine the relationship between the solution and service architecture.

Parallel Architectures

A solution can be understood in relatively abstract terms – a solution to a problem, or a solution to a business requirement. Hence, even the provisioning of an individual service may be seen as a solution to some problem in the right context.
However, taking that more conventional IT sense, a solution is usually seen as a packaging of application functionality, that provides support for a set of business requirements. Hence a solution can be understood as consisting of the following main elements,

• One or more Application assemblies, each providing several functions that are required of the overall solution.
• A form of user interface that provides a means for Human-Machine interaction between the user and the applications in a manner that supports a particular business workflow.
• And a set of Services, where each provides one or more of the required functions.

Figure 1: Parallel Solution and Service Architecture Views

As illustrated in figure 1, delivery of the solution architecture often parallels that of the service architecture.
The process starts by modelling the Solution Specification Architecture. A key part of this is identifying which services are required in order to support the functions that the solution automates.
Hence the Solution Specification Architecture is partly expressed by a dependency model that shows the solution elements and their service dependencies.
Next, a Solution Implementation Architecture is produced showing the software elements that will be required to implement the solution specification. Now the relationship to the required services can be expressed more precisely using an Interaction or Sequence Diagram.
Finally, the Solution Deployment Architecture shows how the software elements are deployed to the network modelled by the Technical Architecture and realized in the operational environment.

Why separate the solution and service architectures in this way?  A solution can be considered to consist of both of these views.  That is, the delivery of a solution that addresses some business need requires both the delivery of the services and their assembly along with the human machine interaction aspects into the solution.

So won’t one architecture suffice?  It could do.  And for some small, truly stand-alone, self-contained solutions it may well be sufficient. But in many cases there are some good reasons why it is best practice to deal with them separately, even if their delivery of both is within the same solution project. For example

• Enable agility. By decoupling the Services from the human machine Interaction each can evolve at a different rate
• Encapsulate change. By hiding unnecessary detail of the complete Service Architecture and focusing only on the services directly used by the Solution, this helps to encapsulate change in the service architecture.
• Support sharing. For most solutions it is desirable to leverage Services that are shared or common across the enterprise or line of business, and hence these services need to be independent of any one Solution. Moreover, it isn't uncommon for solution-specific services to evolve into shared services.

Solution and Service Architecture Iteration

As noted, the Solution Architecture is partly expressed in terms of the Services it uses. The apparent overlap between the Solution and Service Architecture shouldn’t be seen as a duplication of effort.
Rather it is just two alternative views of the same overall architecture, and common elements are only developed once.

Hence, as shown in figure 2 the Service Architecture is an input to the Solution Architecture activity.  At the same time, the Solution Architecture activity may identify the need for new Services, and these new requirements can be fed back into the Service Architecture activity.  It is then determined whether these new Services are specific to the Solution, or whether they should be delivered as Shared Services and made available to other Solutions. This should be a subject of policy.
As illustrated, both of these activities should be working off the same set of business models as input, but each put to appropriate use.

Figure 2: Solution and Service Architecture Iteration

During the Implementation and Provisioning stages, the Service Specification (or Service Implementation Architecture if completed) is now input to Solution Implementation activities. The use of operations required by the Solution can be modelled in Interaction Diagrams.  Again, this activity may identify new Service Operations and again these requirements can be fed back into the Service Provisioning activity.

The extent to which the Solution Architecture and Service Architecture are developed together as part of the same project will depend on various factors such as the need to deliver services that are used in multiple solutions.  At one extreme there may be an extensive Service Architecture that pre-exists the Solution Architecture, and a Solution is largely a new assembly of pre-existing Services.  At the other extreme, there may be a minimal existing Service Architecture and it needs to be developed in parallel with the Solution Architecture, with much of the Service identification being based on the Solution’s specific requirements.

Agile Solution Delivery

It is important to recognize that that the sequence these activities are performed in is not predicated on a waterfall approach.

Figure 3: Agile Solution Delivery

The whole service and solution architecture does not need to be fully detailed before any provisioning activities can commence.  Rather, we would expect each execution of an architecture sprint to provide just enough architecture to support a release of part of the solution.
Similarly, the specification, implementation, and assembly of services and solutions would also be performed though a series of development sprints.
Whilst the necessary business models required as input could be collected during a pre-sprint phase.

Everware-CBDI eLearning

The Solution Architecture module is available as part of our range of eLearning products, which can be purchased individually or as part of a subscription to our Knowledgebase which contains all our elearning materials and much more.