Service Reusability

One of the most vital principles of Service Oriented Architecture is that of service reusability. And in today’s day and age, it can be said that we have been making a lot of progress towards improving both this central tenet and Service Oriented Architecture in general.

One sign that a significant degree of progress in the field has been made is the fact that more and more questions regarding Service Oriented Architecture these days are aimed at the architecture itself, rather than infrastructure and implementation. One question that has come up in recent years is: Should all services be reusable?

This question has a deceptively simple answer. Since it is one of the tenets of Service Oriented Architecture to build services that are reusable, then indeed all of them should be, right?

Upon further examination, finding an answer to this question may require greater demands of subtlety – as well as deeper thinking in architectural terms. In this essay, we will explore the correct answer to this question, while also examining the notion of deep architectural thinking.

Top Down Service Oriented Architecture Thinking

When asking whether or not all services should be reusable, we are led to ask two more questions. Depending on which question you choose to ask, you will be able to determine whether you are thinking about architecture in a bottom up or top down manner.

The top down approach to Service Oriented Architecture thinking begins with a picture of all Business processes that exist in a Business. The thinking then turns to the decomposition of such processes with an eye towards the identification of redundant areas that may indicate good candidates for services.

As such a top down method focuses mostly on meeting the objectives of a Business while increasing efficiency through a reduction of redundancy and a subsequent increase in reusability, the main question architects should ask themselves is whether or not a maximization of reusability is the smartest practice, or whether other priorities should also be taken in to consideration.

The fact is that while reusability may indeed be one of the most important aspects for determining what services are to be built, there are other aspects that must be taken in to consideration by the architect in order to go about meeting the ever-changing requirements of the organization via Service Oriented Architecture abstraction. To be precise, services’ evolvability is something that every architect should take in to consideration.

While some services might have more than one application, they might nevertheless experience several requirement changes as time wears on. There are in fact situations in which agility instead of reusability will be the driving force behind the design of a service.

A certain service might have only one consuming application; this being the case, what should dictate the design of the service is the fact that it is subject to constantly changing requirements — not its reusability. In such instances, it will be a lot more cost effective to put the necessary overhead in place as a means of ensuring the loose coupling that is required for such services, even though they might only have one consumer.

There is yet another example whereby reusability may not be the service design’s top priority. That is in those instances where loose coupling owing to the contracted nature of the interface becomes the top priority – particularly in Business-to-Business environments.

Two Businesses that are attempting to improve their automated interactions may very well struggle with limitations that are specific to implementation, such as getting a Java based application at one organization to interact with a mainframe based application at the other organization.

In these instances, the building of services with contracted interfaces that abstract the underlying implementation can ease the process faced by such interactions, even though such services will really only be valuable for that precise, point to point interaction.

Bottom Up Service Oriented Architecture Thinking

The bottom up approach to Service Oriented Architecture thinking takes the opposite tack to the top down method. It begins by taking a look at existing Information Technology capabilities in the enterprise as a departure point for the development of services that expose the existing functionality that a Business is already largely dependent on.

One of the primary challenges that is posed to architects in such a scenario is the amount of existing functionality should be exposed in the form of services – and at what granularity level. If, for instance, reusability has emerged as the primary driver for the identification of areas within a service enablement, then it naturally follows that some existing Information Technology functionality might never end up in the form of a service.

The challenge then becomes to determine what functionality should be exposed in the form of a service, as well as prioritizing existing functionality’s service enablement.

One approach to the solving of such a challenge is the leveraging of this general rule of thumb – twenty percent of any system’s existing functionality should be utilized eighty percent of the time. The functionality’s remaining eighty percent should handle exceptions, special cases, as well as other low use scenarios.

Keep in mind that the greatest use does not necessarily employ the greatest reuse. At the same time, service enabling that twenty percent is likely to lead to the greatest level of reuse as a rule of thumb.

Obviously, if an architect is capable of identifying the twenty percent of an existing Information Technology system with the heaviest usage, service enabling those portions of the functionality is going to provide the organization with its biggest bang for the buck.

It accomplishes this by easing access to the functionality, but also through an enabling of the broader reuse of such functionality. There may indeed be reasons to service enable other Information Technology assets. But it is a lot less likely that reusability will be the primary driver behind the follow up enablement.

Architecture Building for Proper Granularity

Of course, most architects are aware of the fact that neither of the approaches to thinking up above is adequate on their own. While the top down approach is likely to identify services that are not cost effective to construct, the bottom up method risks producing ungoverned, redundant services.

A core Service Oriented Architecture best practice is thus to take an iterative approach that employs both methods of thinking, thus improving the architecture as well as the services that exist within each iteration.

In the following, we will explore an example of Service Oriented Architecture that is iterative. Let us say we have already defined Services A and Service B which are compositions of original services, as may be illustrated below:

Utilizing the top down method, one will notice that services A and B both share the composition of fine-grained services 2, 3, and 4. In the iteration that follows, the coarser grained Service C may be defined as

This enables you to re-design A and B as follows:

The familiar agile principle of refactoring out redundancy has been followed. Now an easier definition has emerged for the first two services. The question that remains, however, is whether or not the third service is more or less reusable than services 2, 3, and 4.

The fact is, the third service will generally be a lot less reusable than services 2, 3, and 4, owing to the fact that finer grained services are reusable in the broader set of situations than Service C, which is coarser grained.

This is because of the fact that 2, 3, and 4 can be consumed separate from one another, while Service C consumers will be expected 2, 3, and 4 to be used together.

Despite all this, it will make sense to leverage the third service in this fashion, as the third service is a lot more Business oriented than 2, 3, and 4 taken separately. Coarser grained services tend to be a lot more likely to be oriented towards Business than the finer grained ones.

Service C has a clearer Business value than 2, 3, and 4. This alone is sufficient motivating for wanting to build the third service. Services 2, 3, and 4 will still around, so if someone needs to build them in the future, they are also reusable.

But owing to the fact that Service C is a lot more Business oriented and coarser grained, it is a lot more composable than the servers marked 2, 3, and 4.

One should also keep in mind that the third service is reusable – just not as reusable as other services might be. One is not simply intending to architect for today’s services, however – the Business will need to recompose services in order to meet the requirements of the future as well. Thus, the main architectural principle that should be kept in mind is that coarse granularity is more vital than reusability when the granularity level is able to improve the service’s composability.