Service Granularity Example

A while back, Ayende posted a proposed service model based on an example business context provided by a reader. This provides a good example for discussion around service granularity. For the sake of brevity I won't repeat the complete details of the example or the solution proposed by Ayende here.

In essence, the business in question is a physician job placement organisation, which owns two separate physician job placement companies. There is about a 95% overlap in business process definitions. That is, the business processes between the two subsidiaries are 95% the same. From an enterprise architecture standpoint, this is an interesting example as it illustrates the importance of the business context in determining the IT architecture.

Firstly, we need to understand whether both of these separate subsidiary companies operate independently, or if there are functions shared between the two. If there are many shared functions, then what we are really looking at here is one company with two brands. If functions are not shared, one needs to ask why this is. Certainly one would imagine there would be plenty of synergistic opportunities for sharing functions, resulting in better efficiencies and cost savings.

If for whatever reason the business wishes to operate these subsidiaries independently (this could be because the business has different long term strategic plans for the future of each business, or simply because they wish each business to be able to operate and evolve independently without influence from the other), then we are looking at two separate SOAs - one for each subsidiary.

This doesn't mean going through the exercise of designing and building two architectures. One would presumably put together a single architecture and then tailor it for each subsidiary. One would develop systems supporting that architecture and simply deploy two instances - one for each subsidiary. Now each subsidiary can now evolve independently.

Now, onto the service model itself. In the example, there are three core functions performed by the organisation - marketing and recruiting (which are performed by the Sales department), and credentialing (performed by the Credentialing department).

In this scenario, we need to understand whether the Marketing and Recruitment business processes have sufficient loose coupling and high cohesion to be implemented as separate services. If these processes share a lot of business logic and the information models of these processes have a lot of similarities, then we should implement a single Sales service to support both business processes. We would probably consider implementing these as autonomous components within the Sales service.

Alternatively, we would implement separate Marketing and Recruitment services. Either way, it seems would should have a separate Credentialing service as this is performed by a different department, so I would assume the Credentialing business process is quite independent from the other business processes.

Ayende's proposed solution however outlined eight separate services. At closer inspection, there appears to be somewhat low cohesion between these services. That is, some of them would likely be described using the same domain models.

In fact, the defined services seem to relate more to operations that may be exposed by a service, as opposed to services in their own right. For example, there is an Available Candidates service as well as a Register New Candidate service. Both of these services deal with candidates, supporting different aspects of the overall Recruitment process.

Consequently with this service model we would likely end up with chatty, synchronous request-reply, data-centric operations exposed by each of the services. Pursuing coarser grained services centred around cohesive business processes as suggested above would deliver a more loosely coupled service model.