Saturday, June 10, 2006

Difference between OO and BPM Part II - Inheritance

I tried to show in a previous post that the difference between the brave new world of BPM and the old traditional world of object orientation is really not so different. I left off wondering about inheritance and how that manifests itself in the BPM world.

Now every OO programmer knows what inheritance is. Or do they? It seems that inheritance is a slippery concept. Way back in 1996, Bertrand Meyer (the inventor of Eiffel) published an article in IEEE Computer in which he listed 12 different types of inheritance. It's no wonder that the usual advice given to an OO developer is to keep the inheritance hierarchy shallow – if you don’t, you’ll get swallowed up in the complexity.

Judging by the amount of academic papers written on this theme, it seems that process inheritance is also a complex topic. One which caught my eye, was a paper by Guangxin Yang as part of his Ph.D.. In it, he models process as a set of activities, each of which can trigger events which, in turn, cause messages to flow to other activities. In this way he can allow inherited processes to add new activities, add events, enable/disable triggers and also to change the semantics of the activities so they fit more closely to the business requirements. Although these seem to be powerful ideas, Yang’s paper doesn’t seem to have attracted much attention, only getting 2 citations according to Google Scholar.

So far, process inheritance does not seem to have reached commercial products, although this would seem to be a very useful feature to have. For instance, a typical business process could be defined and customer specific extensions could then be made to the inherited process in the same way that specific features are added to inherited classes in the OO paradigm. Some readers may recognise this. It is how most ERP systems are implemented today, only the “inheritance” mechanism is implemented by programming user exits and/or adding new customer build activities. The disadvantage here is that these changes are specific and propriety to the ERP system being implemented. If we want to implement processes over a heterogeneous environment (i.e. a lot of different applications or over the web) then inheriting from a process running in an external process engine would be an obvious solution. And with the rise of web services, composite apps a.k.a mashups, it wouldn’t surprise me if we start to see inheritance mechanisms creeping into the feature sets of process engine vendors.