Today I am visiting the Cluster meeting for “Emergent Software” in the Area “Rhein-Main-Neckar” in Germany, my home country. The Cluster is a network of Companies in the area of Software and from the region and is supported by the German government.
The goal of the cluster – as I understand it – is to enable software companies of the region to collaborate for the common goal of adaptive business processes. Yes – the term adaptive business processes has been on the slide describing the goals of the cluster. Maybe they are also reading my blog 
. However the term emergent business processes has been used interchangeably. I do not exactly know, what emergent processes means, but I believe it means something similar like adaptive. Probably over the course of time – if there is a difference – it may become clear. But my guess is that emergent is more like an academic term.
The talk defined an adaptive process as flexible and secure integration of ERP processes with Web Services (SOA). That is quite a different definition as the definition we use for Adaptive Case Management. Adaptive Case Management does not depend on ERP processes, nor on Web Services (SOA) – although there is no reason why they should not be integrated with ACM – as I argue in my chapter of “Mastering the Unpredictable”. In the end, ERPs and SOA is less flexible than ACM, so ACM can adapt to the form of ERP and SOA, if they are built in a way that integration is possible.
That little “if” is a big “if”. In my experience it is not just defining a WSDL interface for an ERP systems interface to make process integration a reality. If the ERP service is not built by design for integration, then integrators will have a hard time. Middleware does not solve the problem. Maybe many readers might disagree, but I am convinced of what I say: Middleware does NOT solve the problem!
Before we can solve this challenge we must look at some ugly truths in the first place.
I make a simple example. If an ERP system has a purchase order and the purchase order does not wait for purchase order confirmations (i.e. the ERP system does not support this functionality) before a purchase order update may be sent to the supplier, but the suppliers ERP system can only handle updates after the confirmation, then there is a problem, that even middleware can’t solve. Yes, some purchase order updates may be blocked by the middleware – but what does it help? The confirmations will find a different purchase order state which leads to further conflicts, error tickets, misunderstandings and all bad things.
That is the ugly truth about process integration.
So in the first place the challenge for ERP/SOA integration is to make it work at all. Then, in a second step, flexibility comes into play. Sure, flexibility is demanded. But not always. If you walk over a bridge you don’t want it to be too flexible. It’s the same with business processes. You don’t want the flexibility to bypass the posting of a cheque for example or to send the money to a different account. So flexibility means controlled flexibility.
Both problems can only reasonably be solved by modeling. The web service interaction – the choreography – must be modeled, not only the WSDL signature. This is possible now by using BPMN 2.0 Choreography modeling, which is brand new. I must add some coaching is needed to use it. So I expect the cluster needs to discover this great method of describing the web services in the first place, then find principles of designing their business processes in a way, that they are able to be integrated, and then in the end ACM can also be integrated – that’s the easy part then.