Service Oriented Confusion (SOC)

In a previous article I presented a service taxonomy. As I explained over there, deciding upon a proper service taxonomy supports a proper service layering. I should have said this is only one of as set of taxonomies (plural) that you could use, even at the same time.

Moreover, I could also have explained how different service taxonomies can help the process of service discovery. For example, a taxonomy along business domains (like Customer Relationship Management) can help to get an overview of all services provided by a specific business domain.

But I would also like to state a word of caution here. I have seen organizations using an IT related taxonomy including classes like data services and application or utility services in the communication with business analysts. The problem is, that to a business analysts such a taxonomy is difficult to understand, and may look pretty arbitrary. Where does a data service differ from a business service? Do they not both deal with "data"? Yeah, but eh ...

Apart from that, what value does it add to them? Why should they care? I can't tell you that to be honest. What I can tell you is that I've seen situations where business analysts only thought they understood and started to do analysis. The damage done ...

It is my experience that the only two classes of the taxonomy that I presented in my previous article, and that make sense to the average business analyst, are process service (a service implementation of a business process) and business service. From an IT point of view, a business service may translate into one data service, utility service, or some composite service that orchestrates two or more data/utility services, etc.



I've been with an organization that does not strive for business services to be reusable, because in their definition, a business service is a service that supports a specific business purpose, that may be unique across the organization (as shown in the picture above). However, from an IT point of view the services used to construct the business service definitely should be reusable.

Now this may or may not work for you, so you may want to use a different taxonomy for layering. As long as you make sure that it clear what kind of taxonomy is used for what kind of stakeholder, and you only use a taxonomy that makes sense in the universe of interest of the stakeholder.