Is BPEL4People really for The People by The People?

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.

:: :: :: :: :: :: :: :: :: ::

SaaS, Appliances and Industrialisation

Picked up a couple of posts over the last few days with respect to on-premise SaaS offerings.  First up was Gianpaolo Carraro over at Microsoft talking about intra-preneurial SaaS.  This is a topic that I’ve discussed a number of times and whilst I’m in complete agreement that taking the benefits of SaaS into the enterprise is a good thing I also feel that it’s in enabling business capabilities to be delivered as services that the real value lies; i.e. conceiving of the organisation as a set of collaborating service providers rather than just encouraging the IT department to make applications available in a new way.  Such a model enables greater focus on the capabilities that actually add value to the organisation and prepare the ground for future unbundling by raising management purview to business capabilities in place of applications and technology.  In this context I was also delighted to see Gianpaolo describe the supporting infrastucture as a ’service delivery platform’, since to me the need to deliver such future business capabilities as viable services with proper management, reporting and monetisation is a critical requirement and one often overlooked by SOA implementors.  Taking this argument a bit further – especially given that the question originated from Sinclair Schuller over at SaaS blogs (who is connected with Apprenda) – the question for me is whether the service delivery platforms to enable intra-preneurial SaaS are better built in house or leveraged from external platform provders?  For me the answer is that enterprises should absolutely use external utility computing platforms to support the service enablement of their business capabilities and stop wasting time, money and brain power grubbing about in the weeds of technology.  A big issue with this currently, however, is one of trust; many large companies have not yet achieved a level of comfort with externally provided, multi-tenancy service platforms that would enable them to make this giant leap forward.

As a result of this I was delighted (again) to read a post by Phil Wainright over at ZDNet talking about SaaS appliances.  In this context I’m thinking more of the service delivery platform being delivered as a ‘SaaS appliance’ but the argument still holds.  As I stated in this post, I believe that there will be a place for both multi-tenancy and onsite utility computing provision and so again, I am in complete agreement that the provision of SaaS offerings need not always be across the network.  In fact I believe that ‘utility computing’ platforms will be available both in a centralised, multi-tenancy form but also as an on-premise option linked into the wider management processes of the service provider.  Either way the service provider can take advantage of standardisation and economies of scale across customers, even where some parts of the platform that they support are physically located outside of their data centre.  This ability to provide standard service delivery platforms across customers is, however, a key element of IT industrialisation, a topic discussed by Nick Carr in another recent post.  Nick’s post basically summarises an article that he’s written for the Guardian newpaper in the UK where he points out the increasingly onerus tasks of managing the infrastructure needed to deliver services in the new on-demand world; as an end enterprise who wants to concentrate on differentiating myself in my chosen market why wouldn’t I take advantage of the investments of infrastructure providers in the creation of bullet-proof service delivery platforms rather than continue to invest and suffer the pain of creating smaller scale, less reliable infrastructures for myself?  The beauty of all of this, however, is that I will increasingly be able to start small by delivering some initial services on utility platforms deployed within the bounds of my own organisation – since even there my costs will be lower than extending my current environment due to the infrastructural providers’ economies of scale – and transition away from my bespoke, costly environment over time.

:: :: :: :: :: :: :: :: :: :: ::

Getting IT "Just Right"

The more I read on Steve Jones blog the more I find to like about what he has to say.  One of his recent posts discusses the futility of trying to cover every eventuality by producing a paper trail long enough to circle the earth and the moon one million times.  I’m really interested in this whole area of ‘just enough’ consideration as I think that one of the keys to business agility is to make more appropriate decisions about solutions that match the reality of the business capability that requires them.

In one of my previous posts I’ve discussed the phenomenon (you’ll have to dig for it as the post wasn’t specifically about that) of ‘enterprise IT’ as often delivered by IT departments – and in particular enterprise architecture efforts -as basically being inappropriate for everyone rather than right for anyone; the basic premise was that:

• Small, nimble parts of an organisation have to contend with huge lumbering infrastructures enforced upon them at more cost than they can afford and more importantly that make everything move much more slowly than they can live with.  In particular – as Steve points out – IT departments generally want to consider every possible usage that could ever be made of a solution by every other part of the business and therefore deliver a solution that is way beyond appropriate “just in case” or alternatively force the new functionality into an existing ‘box’ even if its cost or capability isn’t wholly appropriate.  This includes the sorts of inappropriate questioning and high beaureacracy that Steve talks about, which is a result of trying to make everyone fit the same profile; and
• Larger business capabilities get an environment that may approximate to their needs but they also end up subsidising other areas of the business because they pay for infrastructure and software that then gets used by everyone.  This leads to all kinds of bun fights and ill feeling about who funds upgrades or extensions forced by capacity etc, particularly as IT departments are generally not able to deliver true shared services due to a lack of service enablement capability (i.e. service management, usage billing etc.).  At the same time whilst larger units may get appropriate IT from the context of scale or function they still chafe against the beaureacracy and tardiness of change that their supporting IT delivers.

In general the issue is threefold; basically IT people are a) looking to cover themselves against failure because they take such a beating from their business colleagues about value for money and so they try to imagine every potential future use case to protect themselves against accusations of ill-preparedness, b) they can only afford to manage a limited solution portfolio cost effectively and so try to squeeze every business need into this limited space – essentially the focus is on making life easier for the IT department by standardising rather than on delivering the right ’size’ of solution with the right characteristics at the right time and c) there has traditionally been a lack of abstractions that allow IT to understand what a ‘right sized’ solution looks like for each business capability that they deal with.  All of these things have traditionally resulted in the ’shadow IT’ so bemoaned by enterprise architects as end users take the issue into their own hands and bypass the IT department completely.

Now the reason that this area interests me is because service-orientation deals with the third issue and thereby enables us to think differently about the first two – i.e. it provides a set of abstractions that allow us to reason about the business capabilities that we need within the organisation, the levels of service we need from them and the costs we can afford to bear in their provision.  Essentially SOA breaks the organisation down into a set of collaborating service providers (i.e. capabilities) and thereby delivers an optimal problem solving layer not previously available.  Whereas in the past the problem solving layer has been the technology in the form of application portfolios – linked, if we’re lucky to some loose notion of business processes – the focus can now move to the ‘what’ in place of these ‘hows’.  This is a significant change as it allows us to see the wood for the trees by moving away from standardisation on applications and technology and into standardisation of capabilities.  This delivers a much clearer statement of the context in which IT needs to be delivered if it is to realise capabilities in a way most appropriate to the environment in which they operate – i.e. a capability that needs to be operated at low cost and which changes a lot is unlikely to be a good candidate for squeezing into the ERP implementation that we have; as a result we will need to find a way of providing service to this capability that much more closely matches their needs. 

So what does all this have to do with Steve’s post about people covering their arses?  Essentially I believe that this helps us in three main ways:

1. We can much more rapidly agree what needs to be delivered because we can have conversations with our business partners centred around what needs to be done rather than suffer the traditional impedance mismatch between business and IT.  This makes agreements – in the form of contracts, service levels and costs – much easier to formally document and removes a whole layer of arse covering from the process aimed at caveating everything to cope with the essential lack of understanding between the partners involved;
2. As IT people we can much more easily understand the needs of the business areas with whom we deal and rapidly see what level of provision is appropriate based on the characteristics of the capability i.e. does it differentiate? what scale does it operate at? how often does it change?  how much can we afford to pay for it? is it highly regulated? etc.  These characteristics give us a clear field of operation when considering the degree to which we need to cater for Albanian watch sellers (lol) and to therefore source IT that aligns more realistically with the needs of the consuming business capability.  This again removes the need for endless speculation about what might happen in 5 years time as the commitment of the IT organisation is either to deliver a service within the constraints identified or to decide that they can’t do it and help outsource the IT (or even the entire business capability) to an external provider; and
3. Separating the delivery of the IT required by different capabilities (at least logically) enables much more rapid change since we can reduce the dependencies between different business capabilities.  We do this by concentrating on service dependencies and shared capability rather than by forcing shared use of technology.  Where we do share technology - infrastructure, applications and platforms – we maximise the virtualisation of this provision so that we’re really offering shared technical capability on a multi-tenancy basis rather than trying to squeeze everyone together and thereby coupling them and reducing their ability to change independently.  This will require IT departments to either deliver real service delivery platforms – which include the capabilities needed to enable both themselves and their business partners to deliver what they do as a managed, billable service – or partner with external utility computing providers who can offer them this capability as a service.  Enabling much more rapid change by implementing a more flexible IT model would further reduce the need for arse covering as a) we would have a better relationship with our business partners due to improved service provision and b) changes can be accommodated much more rapidly and therefore the need to plan for all eventualities to save time ‘in the future, maybe’ would be much reduced.

All of these things drive towards putting much more pressure on the business to describe what they do and equally importantly on IT to make what they do far more transparent and to be more pragmatic in the way in which they do things.  Essentially as focus falls increasingly on getting the right IT at the right time and at the right cost IT departments can’t afford not to become far more flexible and less dogmatic, since the rise of SaaS and external service provision will increasingly give people easy alternatives to the monopoly we’ve enjoyed over the last 30 years.

:: :: :: :: :: :: :: :: :: :: ::