How Big Should A Service Be?

We often hear the discussion about how large services should be in a SOA deployment. But the arguments about the coarse-grained versus fine-grained have raged for many years in other, more traditional architectural approaches, i.e., this is not something that is specific to SOA. It's also an example of where one size does not fit all: sometimes size really does matter! A recent report adds further fuel to the fire around this often heated debate:

A Service is not simply an object exposed with a standards-based API or just another way of doing object-oriented programming “in the large”. Indeed, just as object orientation offers a different level of abstraction and thought from procedural programming, Service orientation offers a different level of abstraction and thought from object-oriented development.

The report goes on to add:

Indeed, the Service-oriented movement is not a technology one at all! It is a business-oriented movement where the abstractions are the very abstractions that relate to how a business considers the ever-changing and continuously heterogeneous aspects of its organization and how they can be composed in a loosely-coupled manner to allow for flat and predictable cost of change. This means that we have to rethink the way in which we approach IT capabilities, not simply expose the same assets in the same way using a new interface or middleware.

As with other discussions around this topic over the past few years, the report highlights the challenges around service granularity, defining a fine grained service to be one that "addresses a relatively small unit of functionality or exchanges a small amount of data", whereas a coarse grained service is one that abstracts larger chunks of capability within a single interaction. Others have shown how deciding on the granularity of your service is a critical aspect of the service lifecycle because it impacts the composability of loosely-coupled services as well as the reusability of individual services.

The report goes on to discuss the top-down and bottom-up approach to developing services (both are required to one degree or another):

... starting from the business-process or a business model and decomposing that into sub-processes or sub-models recursively until some condition is met by which it can’t be decomposed any further. Alternatively, an architect can start from the IT systems already implemented, expose Service interfaces from the APIs and access points that already exist, create Service Contracts on top of those interfaces, and then compose them together until the business process requirements are met.

Whether you are developing composite services or atomic services also has an impact on the granularity of your services:

While at first blush it might seem that all atomic Services are fine-grained and composite Services coarse-grained, this is not necessarily the case. Since granularity is a measure of interaction and business appropriateness, and atomicity is a measure of process decomposition, it is quite possible to have coarse-grained atomic Services and fine-grained composite Services.

Finally the report produces a granularity matrix, which shows the trade-offs between service granularity and atomicity. The conclusions are probably well know to most people who have tried to develop services over the years:

... a proper Service-oriented analysis and design approach considers separately the issues of granularity and atomicity with respect to five key aspects: reusability, efficiency, transactionality, consumability, and visibility of the Service. What might at first seem to be a composite Service from the perspective of reusability might actually need to become atomic due to reasons of transactionality. Likewise, what might seem to be fine-grained for the purposes of visibility and auditing might become coarse-grained for reasons of efficiency. Indeed, the Service granularity matrix serves as just another tool in the belt of the effective enterprise architect.

So does size matter? Yes, but sometimes big isn't necessarily best. Furthermore, because one coarse grained service may work well in a particular environment does not necessarily mean it's best suited elsewhere. Services evolve with the applications that use them.