After discussing #8: Security, let's move on to #7.

Incorrect granularity could mean that a service covers too much functionality or too little functionality. Incorrect granularity of services in your SOA can lead to bad performance, low reuse possibilities, leaky abstractions and services without added business value. . Common causes for this are bottom-up and/or top-down design and taking a too narrow perspective (project instead of company scope). In this blog we’ll first take a closer look at the previously mentioned symptoms and their causes. And then we’ll explain why the solution lies in taking a business perspective when designing services.

First the symptoms that could indicate that services in a SOA are not of the right granularity:

• You're not able to explain to business people (e.g. sales/marketing) what the service does. It simply does not fit in their understanding of the business the company is in. The services are at a level of detail that is irrelevant from a business perspective.
• Many different services are needed to achieve something of value to the business.
• Using the services in the SOA leads to an enormous amount of tiny interactions between systems and the performance of the overall process is dead slow.
• Services are variations of basic CRUD operations (Create, Read, Update, Delete) and do not add any functional value to the basic CRUD operations.
• Service definitions expose how the service is implemented. For example you can deduct from the service definition that a service uses a particular database.
• Of the available services hardly any service is used more then once. Each service seems to be bound to a particular application. This could mean services are too course grained because they encompass a set of functionality that is only used by one (or a few) application(s).
• There is no clear ownership of the service, multiple department feel they should own the service (or parts of it).
• Lot's of layers of composite services. The top level services in this case may expose interfaces of the right granularity, but the are composed of services that have an incorrect granularity. This incorrect granularity is often caused by one of the above symptoms and extra unnecessary compositions are put in place to compensate for this.

So what types of pitfalls lead to these symptoms?

• A couple of pitfalls can be grouped into bottom-up design. For example, when existing systems are hooked up to the SOA it is tempting to take the API of this system and expose operations in this API as services in the SOA. Easy to do, but these service will have no business meaning, are potentially too fine grained (with CRUD services as the most obvious example) and tend to leak implementation details. Another example of bottom-up design happens when multiple departments (or projects) are dealing with similar functionality and are not aware of each other (or worse, they simply do not want to communicate, also see Not Invented Here syndrome). Each department or project is only considering their own perspective and that will lead to similar services being developed multiple times.
• On the opposite site, top-down design is not the cure to bottom-up design. When service are designed top down and decomposed to lower level services that are decomposed further down you often end up with a myriad of services that can only be used in that part of the decomposition tree. Different branches of the tree may have similar services defined and services in a branch are coupled to other services in that branch.
• Theoretic service design is another cause. Ivory tower architects or designers are designing services without being driven by concrete projects and/or business processes. This usually leads to services that are so generic that no concrete project can use then without modifications. Each project requires changes to the service definitions to make them useable which in turn leads to many variations of similar services.

What is the right level of service decomposition?

• Service should be decomposed to the smallest reusable unit while remaining be understandable by the business owners. Another way to define the optimal size if that the service should not be a grouping of finer grained services that are not available as separate services. Thus leaving open the possibility to compose services of other services.
• Furthermore it is important that one single role in the organization is the owner of the service (multiple roles may use the service of course). Services that are too course grained will be hard to assign to one owner, leading to unclear ownership (something we will discuss in more detail later in this top 10).
• And lastly, the service should be as autonomous as possible. If someone want to use a service he should not be forced to use other services also (note that the implementation of the service may use other services).

Finding the right granularity of services is not as simple as following a recipe. It’s a balancing act that requires knowledge, expertise and trying different options. Design your service using the guidelines above, run through a number of scenarios and see if you see any of the symptoms mentioned pop-up. If so, reconsider...

Next week, Rik de Groot will continue with pitfall #6.

Filed under Architecture, SOA | 4 Comments »