Services are the building blocks of SOA, and like building blocks of a house or a building, the quality will define the value of the finished product. In this case, the SOA itself. Thus, spending...

How much adaptability and agility do you need in your business? The answer to that question can drive the strategy of business process management (BPM) and service oriented architecture initiatives in your organization (SOA). The question itself is not easy to answer which is why most organizations do not achieve the flexibility they hope to achieve. Sometimes the granularity of the services cannot or are not defined at the right level. Sometimes, the architecture to configure these services dynamically so that they can be orchestrated with ease, is not put in place.  In this article, I will attempt to use real life as a metaphor to illustrate the challenges and provide a sense of how to address those.

Friday was a day for errands. I created a list of tasks that I needed to accomplish, and ordered them by the sequence in which they had to be done. My list ran like this:

1. Drop my son off for baseball practice
2. Get the oil changed for the car
3. Go to the post office to mail a package
4. Drop off the birth certificate at my son’s school
5. Buy the iPod for my friend
6. Pick up my son from baseball practice

The idea was that between the time I drop off my son and then pick him up from baseball practice, I could accomplish a number of things. There were other dependencies as well such as the opening times for the oil change place, the post office and the iPod store. In addition, I already had an 8:30am appointment for the oil change. Considering all these factors and constraints, I had essentially put together a “business process” containing a sequence of tasks.

While I intend to control and manage the business process, I personally am not going to perform all the tasks on the list. For instance, the oil change will actually be done by a technician at, say, the “10-minute Oil Change” shop.  In other words, to accomplish my tasks, I may call upon the different service providers. To them I am the service consumer. The baseball team provides coaching to my son, the auto shop provides the oil change service, the post office provides the mailing service, and so on. I simply invoke these services in some specific order to get my work done. These services are of course business services, which in turn help me to run the business of ‘my life.’

Let's talk a little more about these business services. When I have the oil changed for example, there is an implicit contract that the shop and I are operating under. First, I hand them the keys to my car. They change the oil and hand the keys back to me. Then they give me an invoice, which I pay with one of the many forms of payment – check, cash or a credit card. They provide a receipt and the interaction is completed. The question then is, is the shop providing me one service or five services – take responsibility for the key, do the oil change, hand me the invoice, process the payment, and hand me the receipt.

The difference between the two is critical because in reality that is what causes the confusion between what business wants and what IT provides. As far as my interaction with the shop is concerned, I perceive this as a single “oil change” service.  For another customer who has her car’s brake pads replaced, she may see it as a “brake pad replacement” service.  However, for the shop itself, many of the transactions such as handling the key, invoicing, and payment acceptance are common between these two services. So they would rather re-use their services.

Which brings us to the IT perspective. The shop would have to define their services at a level that is granular enough to allow them to mix and match those services in such a combination as to provide valuable business services. In this example, six different IT services (four common ones, plus the oil change and brake pad replacement) are combined in two different ways to offer two business services.

This also implies that business will have to look up, manage and monitor services that it has to consume, while IT has to manage and monitor services at a different level. My service level agreement (SLA) with the 10-minute oil change shop is an expectation that the oil change will be done within 10 minutes. If that SLA is violated, then other tasks in my business process may get delayed, and I may not be happy. I am not really concerned with individual steps in the oil change service.  End–to-end timing is what matters to me the most. On the other hand, if the shop’s payment processing service is slow, then it shows up as a problem in any business service that it provides that uses the payment processing. So from their point of view, metrics on the payment processing is critical to measure and control.

A mechanism that allows me to orchestrate different business services in a dynamic manner provides me the agility to be different on Saturday. For instance, I may spend Saturday taking the family out to a movie and dinner in which case I have orchestrated a different process. In the business context, a Business Process Management System (BPMS) helps to orchestrate and invoke different services for business adaptability.

This then means that the business has to clearly define the business services that it expects to invoke, and the SLAs corresponding to these services. IT or other service providers can then turn around and create services at potentially a lower level for reusability across different higher-level business services.  The service and business requirements definition is where Business Architecture can help, but that’s for a subsequent article.

A caveat: There is yet another higher level of service granularity that we have not attempted to discuss. That perspective is to consider the service from a ‘business value’ point of view. In the oil change example for instance, I am not really interested in changing the oil, but rather interested in having a “reliable car.” Similarly the other customer is not interested in having her car’s brake pads replaced, but she is interested in having a “reliable car.” Taken from this angle, the car shop provides the service of making our cars “reliable.” They simply have two different products, oil change and brake pad replacement, which they can use appropriately to meet the specific needs of their customers. A third customer’s car may require both an oil change and a brake pad replacement.

I want to emphasize that service identification is a critical task that has to be done at the right perspective for the right consumer. Otherwise, reusability and agility are hard to attain.

Dr. Raj Ramesh is the principal of TopSigma Consulting and specializes in the implementation of BPM/SOA initiatives, leveraging his business and technical expertise with his client’s domain expertise to add value.

Back to Articles, including SOA, BPM & BA