We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

Time to review "SOA Best Practices"

Vote 0 Votes

Recently, I conducted a search on SOA modelling and found Wikipedia's article that talked about SOA modelling and referred to SOA Best Practice in some of the provided examples. I was intrigued and looked it up. I have found that the Wikipedia materials are nothing more than the article 'Service Oriented Modeling' published without the author names (!) - probably we are supposed to recognise the 'hand' from the content. Well, let me try.

My guess is that the article closely relates to IBM SOMA and its SO Modeling Framework. I am not going to repeat my review of SOMA here; instead I would like to comment on two examples provided. One example demonstrates the proposed notation of aggregation and another one demonstrates the notation of decomposition of the service.

Here is the most amazing part: the first example says: "Use Case 1 depicts a simple aggregation case, in which atomic service A-1 is aggregated in composite service C-1 because of SOA best practice reasons". The second example says similar thing "Use Case 2 describes service decomposition. Once again, this is because of an SOA best practice rule"; the diagram note adds: "SOA Best Practice: C-1 is too coarse-grained - A-2 is the candidate for decomposition".

In this 'SOA Best Practice' (probably from the same authors) service granularity comes 'from the blue' and the brave developers have to aggregate or decompose the service based on, most likely, interface granularity. No granularity reasons are considered, no purposes; if you are an atomic service, you must be aggregated. Period.

I would like to inform the authors of this 'SOA Best Practice' and all who consider to use it that OASIS has released the second public review of the SOA Reference Architecture Foundation where SOA is positioned in equally the business and in the technology. This simply means that service granularity, aggregation and decomposition should be based on the business granularity and business reasoning.

In technology, the service structure granularity is driven by the well-known notion of 'reusable library'. Term 'reusable' in this case means that the same library is used 'as is' in more than one place or application. This is purely historical understanding of the reuse because the libraries were extracted from the code that was not initially designed or mean to be used is many different places. The later libraries already considered the multiple uses and this, in fact, led to a question: what is the difference between multiple use of the library and reuse of the library? For technical libraries as well as for technical services the answers is(almost certainly) there is no difference. Another story appears with business services (by 'business service' I mean a combination of business human activities and specialised technical automation resources).

Services in the SO environment are considered and designed with the assumption they might be used many times in different contexts by unknown users/clients/consumers; this applies to both business and technical services. The specific of the business services (some people consider this specific even for the technical services) is in that the business performing the same business function in different execution contexts (EC) can produce different results depending on the business policies used in the EC, i.e. business service is not entirely the same in different EC. This allows us to distinguish between multiple uses of the business service in the same EC for different consumers and combinations with other business services and business service reuse, i.e. use in changed EC. After we have explained the role EC, we can approach the topic of business service granularity.

The major difference between my approach and SOMA is in that I consider the business model decomposition into the business services top-down (which usually is not available to the external consultants in IT because the knowledge required for such decomposition procedure is a relatively sensible for the corporate business). So, I am following the process of decomposition of fundamental business functions and services defined in the enterprise business model into sub-functions and sub-features each of which is represented as a business service, i.e. it answers to the question WHAT and WHO, not HOW. The process of decomposition stops at the level where the further split of business functionality into smaller services does not make sense from the business perspective in given EC. The lowest level of services comprises autonomous self-containing stand-alone business services that realise particular business task/function/feature and do not utilise a help from other business services to fulfill its declared functionality and reaching promised results (Real World Effect - RWE). How granular those services are, and whether they may be used or reused totally depends on the business rational.

Thus, the SOA Best Practice now says that the service granularity is driven by the business functionality and service aggregation should be done not for the sake of granularity but for addressing particular business needs. It is not difficult to notice that there are no business functions and features shared or repeated in different business streams. Here I do not mean a business administrative division but rather business functional division. That is, business service multiple uses and reuses are not that massive as some IT people think or try to convince Business in.

The business-centric view on SOA services allows us to recognise just three categories of business services that might require the special recommendation in the SOA Best Practice, particularly:

- common/shared business services repeatedly used in different internal and external business products and services (or in relatively stable combinations of business functionality)
- external/internal product specific business services that are unique to concrete business functionality
- external/internal business services that are specific to particular geography/locale, which I call 'branch' business services

As a result, each external/internal business product/service comprises some combination or aggregation of the business services of all three categories. Understanding the specifics of each service category helps us in the service decomposition procedure and in the defining the granularity of each business service. Another value of this categorisation is the additional input to our consideration of 'use' vs. 'reuse', i.e. if a service changes the category, this is the first signal to review the EC impact on the service in all cases; if the service stays in the same category such reviews are required only when the service is newly deployed.

I hope you find this new SOA Best Practice useful; please, let me know your opinions.


1 Comment

| Leave a comment

Michael, In the introduction you say I have found that the Wikipedia materials are nothing more than the article 'Service Oriented Modeling' published without the author names.

If I'm correct the "article" (http://pediaview.com/openpedia/Service-Oriented_Modeling) you refer to is simply extracted from the Wikipedia page (see the footer of the webpage on pediaview.com). The contributors of the Wiki-page can be deduced from http://en.wikipedia.org/w/index.php?title=Service-oriented_modeling&action=history

Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more


 Subscribe in a reader

Recently Commented On


Monthly Archives