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.

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Show/Hide comments

Show/Hide comment form