Frank Michael Kraft's Blog

In one of my last posts I said, that I think it is a good SOA strategy to buy SOA enabled applications and to interweave them. But I did not define, what I mean by “SOA enabled”.

1. The Web Service Operations that are the interface to the application must be described as WSDL.
2. Technical Means must be available to connect the application to an Enterprise Service Bus (ESB).
3. WSDL is not enough, because it only describes the signature of the service interface. What is also needed is a model of the service behavior. The allowed sequence to call service operations must be modeled as business process model (for example BPMN 2.0 choreography diagram). For example it must be modeled if or if not it is possible to cancel an order after it has been released or not. This is not visible in the WSDL signature, but can only be visible within a service behavior model. And it is decisive to integrate.
4. The application should not be monolithic, but decomposed into components that represent individual process participants that communicate with each other in a loosely coupled way.
5. The granularity of the service operations must represent real reuse. This means, that the service operations may only do one thing at a time and not a chain or sequence of many activities. This is necessary to compose the service operations to new composed services. For example it must be a different step to create an order and to release it.
6. Extension Points must be modeled. Extension points are those points in an application process where extenders are allowed to attach an individual process. For example it might be possible to add additional an approval to a purchasing process. This must be modeled. Also integrity conditions must be modeled. For example it is necessary to have exactly one purchase order for individual purchase order confirmations. This is an integrity condition that must be modeled.
7. It must be possible to define new business objects or extensions to existing business objects.
8. All of this model information must be available in a repository.

This is my requirement list for a SOA enabled application. Yes, I admit, these are many requirements and I do not know one single software package that does fulfill them all. I know software packages that come close. I would not buy any software that falls short of many of these points.

I think most would say, that 1 and 2 is sufficient. I wouldn’t. I think that 3 till 8 is also necessary to make a SOA integration project successful. This knowledge often is only available through the individual knowledge of consultants. But there is no reason to not model it and thus make a SOA project much more economic.

Yesterday I was invited to speak at the BPM | SOA Integration Days, a conference that I really liked very much. My talk was about Adaptive Case Management and how it can improve the work of the knowledge worker – actually we had a whole afternoon about Adaptive Case Management. I also met Max J. Pucher who delivered a keynote. Hajo Normann also talked about the repetitive nature of predesigned forms and screens and how it quenches creativity.

At the end of the day there was a very interesting speaker panel discussion about SOA and about the question if SOA is dead or not. Does it add value? Is it too risky? Does a BPM model help or does it lead into a dead end, because it becomes too complex?

I did not join the discussion because I had to digest what I heard from the panel. But two points became important to me after thinking about what was said, that I want to share.

The first point is what I wrote about in Dead or Alive! Exactly the same discussion arose in the panel only with a little more pessimistic undertone. It seemed like doing the BPM model first before starting the SOA was a bad idea, because it inevitably ends up in complex unusable models and a long project. I was surprised by so much provocation, and part of it certainly was only rhetorical. But it underlined, that what I discussed in Dead or Alive! is very relevant. Also it seems to be some kind of gambling, if you get the BPM modeling project to be successful or not. What the “Adaptive Process” strives for is a guideline that will ensure process models that serve the purpose that is defined and be flexible enough for necessary changes. Not too complex, but enough detail for the purpose defined – in this case for the purpose of specifying SOA. I am convinced that it is possible to have such a guideline and the guideline that I am using in my projects so far works very well to serve the purpose. In the future I want to contribute some of these concepts to the discussion.

The second point I had to think more about. It was obvious in the discussion that it is hard to justify a SOA project within a company, because the big risk and the investment often is not outbalanced by quantifiable returns. One return surely is the reuse of components that is then possible and defined process exit and entry points – and therefore more flexibility. Another promise of SOA is, that it is possible to exchange underlying software components without too much impact on the whole landscape. The latter one I deem to be quite unrealistic. It only works if the new software basically does the same thing as the old software – which is very improbable in my eyes – and not a good case to buy a new one. So the main benefit is the re-use aspect. Now – considering this, I cannot understand, why the duty to do SOA is not more loaded onto the software vendors. I cannot understand, why a company does SOA all on their own. I would expect the software vendor to provide a software package SOA enabled and I would only buy it if it is. I would not do SOA without buying new SOA enabled software. Following this principle, the re-use aspect is much higher, because it is multiplied by the number of customers my software vendor has – and thus much more economical – also for me – because I am only paying a fraction of the whole SOA effort. I would only concentrate on interweaving SOA enabled components for my specific purposes – I think this is enough of a challenge.

Those were my personal thoughts following the very interesting panel discussion.