Archive | BPEL4People RSS feed for this section

Is BPEL4People really for The People by The People?

12 Jul

I was interested to read lately that the long and tortuous process of arriving at some level of human process support within BPEL continues.  Now I have to be honest and say that to me this seems like a really dumb concept.  If you look at service-orientation as a way of abstracting away from issues of implementation and concentrating on outcomes then I really don’t understand how creating an implementation specific extension makes any sense at all (implementation in terms of service realisation type rather than technology in this context).  What other specific kinds of service types are we going to implement?  BPEL4CICS?  BPEL4ESB?  all of which take account of the differences of implementation or interaction model forced by these implementation choices?  Surely any work that needs to be carried out by people is just another service with a contract, service level agreement and cost?  Yes there will need to be a suitable implementation of that service that supports its execution by people but the fact that the task is carried out by a human should surely be transparent to the consumer (which in this case is the BPEL process).  To be honest I have never been particularly keen on the idea of people support within BPEL as I have always viewed it as a standard which provides support for the creation of ‘Macro’ level processes that represent overall value-chains spanning services.  The services themselves will obviously require many specialised implementation methods but this is where service providers will compete and where technology providers will compete in supporting them most efficiently.  The value of BPEL appears to me to be that it allows us to leverage all services in a consistent way and so extensions to support a particular kind of implementation choice seem to lack elegance to me.

Equally importantly in this discussion, however, is the desirability of the kind of process support that BPEL can implement for people.  As I discussed in a previous post, increasing reliance on talent and the collaboration of talent for competitive differentiation means that the kinds of industrial age processes supported by standards like BPEL will be wholly insufficient.  Essentially BPEL implements pre-configured, task driven processes and cannot support the kinds of collaborative, human driven processes that we will increasingly need to leverage the talents that we have both within and across organisations.  As we increasingly automate the rote tasks – ably supported by BPEL – there will be diminishing returns available and certainly little or no competitive differentiation, since by definition anything that can be codified into a consistent transactional process can be copied.  As a result we need to concentrate on how we maximise the effectiveness of our people as they use their talent, discretion and imagination in responding to service requests in appropriate ways.  BPEL4People does not address these needs in any way since it simply treats people as transactional resources who will tick the pre-configured box as part of the wider machine. 

As a result I think that BPEL4People is a pointless exercise since it extends BPEL with unnatural concepts tailored towards a specific kind of service implementation whilst simultaneously failing to present us with a solution to the real problems of people centric processes.  I strongly believe that we need to accept that the issues to be addressed by transactional and tacit processes are very different and that we should therefore embrace these differences rather than try and create an inappropriate uber-model.  In both cases the concepts of service orientation can be used to offer up the resulting implementations in a consistent way – as long as we continue to adhere to interoperability standards in making the services available for consumption.  As an example Keith Harrison-Broninski talks about using services to allow interoperability between transactional processes implemented by BPEL and any supporting tacit processes implemented by Human Interaction Management products.  The key point in all of this, however, is that services will be realised in many different ways, often very specialised to the domain of implementation and I feel that we should recognise this rather than try and mix abstract process control across consistently described service interfaces with the special ways in which those services are implemented.

As a result I believe that BPEL should be left to cover the consistent orchestration of services irrespective of whether the services are implemented by machines or people and that other more promising techniques should be used to realise services appropriate to the way in which people really work.  The fact of the matter is that BPEL4People seems more like BPEL4Vendors to me; they all want to be seen as BPM vendors rather than integration vendors and in so doing appear to be missing the point completely by treating people like the machines they’re used to dealing with.  The irony of rigid process support appropriate to machine integration being touted as ‘for people’ seems as amusing as it is sad.  The shame is that many organisations will follow the lead of these technology companies as they muddy the water for their own ends and will therefore continue trying to squeeze their people into inappropriate processes that fail to deliver the support that people need in the new connected economy.  In particular, inappropriate use of BPEL4People due to the ‘people’ moniker will:

  • Fail to support collaboration and talent amplification by setting out processes as a set of rigid tasks passed out to individuals;
  • Constrain innovation in service delivery by assuming that processes can be designed and fixed in advance, making the contextual tailoring needed during human effort extremely difficult;
  • Fail to deal with the increasingly dynamic reality at the edge of organisations through rigidity of process and thereby put strain on customer interactions by making them unnatural; and
  • Destroy morale and productivity by forcing people to work in ways that are alien to them and in so doing become something to waste time working around rather than a valued support tool.

In many cases these issues will lead to the work being pushed out to people with no hope of actual process support, since there will be a recognition that they will work in some unstructured way to complete the broad task stated.  In this context the work disappears into the shadowlands of the unknown until someone helpfully comes back and updates the system (maybe) – not really a good way of tracking where we are with the mass of human effort that goes on within our organisations every day.

As a result the choice would appear to be to constrain people unacceptably or lose control over what they are doing.  Does that constitute BPEL4People?  Not for this person.