Business Services

The most important part of a service is its contract and by extension its boundary. That determines the role the service plays in the broader architecture, as well as how a service interacts with other services.

Services are the top level element in any SOA. There is only a service bus making up the fabric between services. The service bus should handle message routing and delivery but should perform no other function outside the boundaries of our services. An ESB may perform other functions such as message transformation and process orchestration, but those functions are performed behind our service boundaries (at least when engaging in a self-contained process-centric service model).

So - the primary concern in SOA is the identification and definition of the architecture's constituent services. When applying SOA in a business context we are concerned with identifying business services. A business service serves a specific business purpose, and is defined strictly in business terms.

We define the responsibilities of a business service in terms of the cohesive business area/capability the service supports, and we define the interactions with other services in terms of the business events and operations exposed by the service, as well as the service level agreements provided by the service and the policies imposed by the service on its consumers.

Because this definition involves only business terms, its function and place in the enterprise is easily understood by the business folk. Business services can be defined at least initially by business architects. The technical people can then translate this business definition into a service contract which is expressed in technical terms such as endpoints, messages, schemas, transports, encryption, authentication etc.

The technical folk can then determine the internal architecture of each service based on the service contract. This includes taking an inventory of existing IT systems and determining which systems support each service.

The business service definition is where the rubber hits the road between the business architecture and the application architecture. Business services are expressed as part of the business architecture, whereas their technical definitions form part of the application architecture. There should be a one-to-one correlation between services defined in the business architecture and those defined in the application architecture.

Business processes will of course vary from business to business. Although many businesses have a customer management function, the way in which that function is performed will be different in each business. Furthermore, the way in which that function interacts with other functions in cross-function business processes will vary from business to business.

The interaction between business services defines how cross-function business processes are performed. As this is organisation specific, we find that the contracts of our business services are expressed in the terms of our specific organisation.

This is why we don't expose COTS application endpoints directly to other services in our organisation. We require a layer of abstraction to translate a service contract specific to our organisation to the generic service contract specific to the COTS application.

As we have previously discussed, the art form that exists in identifying candidate services is in achieving high cohesion and loose coupling. To some extent, we can look to capability mapping to help guide this process, but more on that in a future post.

It is very rare that an architecture will be correct on the first pass. The architecture will evolve as there is feedback from the application architecture domain to the business architecture domain and vice versa.

If we find symptoms of incorrect service definition (such as chatty, data centric, synchronous request-reply, transactional interactions between services or domain models with confused semantics) then we refine the service model until these symptoms are alleviated.