LiteBytes from Lustratus Research

Private power for BPM

Yesterday I had the pleasure of having lunch with Jan Baan, a serial achiever in the IT industry and currently Executive Chairman and CEO of Cordys, a BPM vendor. I went to the meeting wondering whether the BPM space really needs another player - my personal view is that the market is still immature in demand terms, but there are a number of well-established vendors already.

However, as a private company with a rich backer, Cordys benefits from something that public companies can often only dream about - the freedom (time and money) to do what needs to be done to deliver a 'Version 2' offering. Most public companies build a version 1 that most of us would call a version 0 (or even -1!). The pressure is on to justify the investment by delivering returns quickly. Even a VC-backed private company suffers the same problems, with anxious investors looking for assurance that their money is working for them.

But as Jan explained to me, he has been happy to bankroll Cordys with a desire to build a solution that addresses the real-world operational issues that many Version 1s ignore. As a result, Cordys tells an impressive story on subjects like performance, fault tolerance, scalability and usability. Perhaps BPM is about to benefit from a dose of Private Power.

Steve

The BPM vendor view of SOA

Oh dear. Once again I am about to be drawn into a row about vendor claims around SOA. Oh well - so be it.

I saw a link recently to a White Paper available through Information Week, by Metastorm Inc., which started off

"While an SOA can go far in addressing the important security, reliability, and re-usability of services, SOA is nonetheless a technical approach. Thus, the challenge of SOA — and the key to achieving business value — is elevating service enablement beyond just technology functions. The reality is that SOA has limited value unless it encompasses disparate applications and platforms, and most importantly, it moves beyond technology and is orchestrated and controlled in the context of business processes."

OK, I see where the BPM vendor is going with this. But there is a glaring issue here in my mind. Stating that SOA is a technical approach, and discussing the need to move beyond technology (via the use of BPM) creates the false impression that SOA services are technical pieces of functionality as opposed to business services, and that implementing an SOA is jsut a technical exercise. This is absolutely not the case. I have discussed this many times, even in this blog. SOA services lie on business rather than technical boundaries - they execute a piece of business functionality as opposed to a technical one. Indeed, as I have also stated previously, this leads users into a position where they may be 'backing into' BPM through building orchestrated SOA services, but this does not require a BPM suite. In addition, a successful SOA implementation is almost NEVER just a technical exercise - it has to involve all sorts of disciplines.

I am not against BPM suites - in fact, I think they can add a lot of value when users have the enterprise-wide maturity to realize the full range of benefits they bring. But let's make sure we keep the facts straight.

Steve 

BPM: Untangling the terminological mess

One of our missions at Lustratus is to remove the confusion that gets in the way so often in IT - in the way of understanding what technology can do for a business, in the way of understanding how to select the right product and in the way of making the right IT investment decision.  As spaces get hotter the confusion just seems to get worse!  This is certainly the case with BPM - which  usually standards for Business Process Management (although sometimes stands for Business Process Modelling which I will ignore for the moment).  As a term it can be considered from a pure business perspective or (almost) a pure technology perspective - and really fits somewhere in the middle.

Michael Dortch (a blogger at ebizq and analyst with The Robert Francis Group) had a good go at defining it from pure business perspective:

"BPM is a set of human-centric business problems that often masquerade as or are confused for decisions and issues focused on IT solutions and systems. And vice-versa."

While I think Michael is correct to drag the focus back to the business problem (particularly when addressing an IT audience), this applies equally to almost all enterprise IT issues.  I must admit that I found his argument confusing when after the statement above he gives as his first question to be answered by BPM: "What part or parts of the IT and/or business infrastructure are not working, and can they be fixed non-disruptively?".

However, attempting to define BPM from a pure technology perspective is equally flawed.  Unfortunately, Business Process orchestration standards (such as BPEL) are sometimes presented as providing BPM.  This view is flawed in two ways:

1.  BPEL does not provide process monitoring, analysis or reporting capabilities (as such it is only a part of a technology platform for BPM).

2.  It is an implementation language for technology domain processes which in turn will correspond to Business domain processes.  (Unfortunately, the colonisation of the term Business Process to mean an orchestration or sequencing of service invocations makes the previous sentence rather clumsy!) 

Therefore, BPEL and any other business process execution languages can only be part of BPM. 

Finally, I should admit that I don't really disagree with what Michael says (taking the liberty of reading between the lines a little): BPM is a balance between the business domain and the technology domain - and its purpose is the optimise the buisness domain.  As such it is really not so different to most enterprise IT concepts.

Ronan

BPEL4People: mad or not mad?

I have a lot of sympathy with Steve’s blog item on the WS-madness:  Vendors will sometimes (inevitably) cynically use standards only for differentiation, standard bodies and the professional standard writers will do what they are paid to do: write standards.  And finally end-users are too disengaged to make sure the standards solve the problems they want solved.  All of which was going through my mind when I was reading the recently published BPEL4People standard:  Is BPEL4People just another piece of WS-madness?  (BPEL4People is an extension of WS-BPEL to handle human involvement in business process modelling and execution.  BPEL is the WS specification for defining business processes.)

To answer my question, I came up with the following simple sanity test (which many WS-standards fail):

1. Does it address problems that users have today or reasonably expect to have tomorrow?

2. Is it the unique standard in addressing the problem?  Anybody following of the web services standards around reliable messaging will remember the complete mess caused by multiple competing standards( WS-reliable messaging and WS-reliability).

3. Is anybody actually going to implement it?  There are too many standards both WS and previous which are never quite implemented.

In fact, BPEL has itself struggled to pass the three tests for sanity:  While business processes sound all pervasive, BPEL addresses only a subset of all business processes:  Those which have a central controller (i.e. not peer-to-peer collaborative processes which are covered by another standard), where the central controller is in the middleware (i.e. not controlled within your SAP application).  It has also been heavily criticised by BPM specialists who prefer more formalism than BPEL attempts to provide.  Therefore, it struggles to pass points 1 and 2.  These limitations have meant that many users are slow to adopt BPEL and are sometimes happy to stick with non-standard approaches with better capabilities.  All of which led to vendors delaying implementing BPEL for a number of years - which is point 3.  (However, I believe that BPEL does now make the sanity benchmark for those who need it and on that basis would have to disagree with Steve’s exclusion of its from his sane list.)

Turning to BPEL4People, the intention of the standard is to create a “BPEL extension to address human interactions in BPEL as a first-class citizen“.  To put it another way, it attempts to tie human-workflow back into the BPEL standard which is mostly used for system to system workflow (or business process flow if you prefer).  This means that BPEL4People contains concepts such as human roles, groups and tasks.

Returning to my sanity tests:  On the first test, BPEL4People certainly addresses a problem I have seen where some human interaction is required in a system-to-system business process.  It is a subset of the set of users of BPEL itself – maybe less than 50% of all BPEL use cases. 

A bigger criticism is at point 2:  You could (and many have) solved the problem BPEL4People addresses with BPEL on its own.  Yes BPEL4People provides standards where people made it up as they went along but it is not clear that the overhead of a new standard justifies its creation.  Finally, is it going to be implemented:  On the face of it, SAP, BEA, Oracle and IBM’s backing makes it a simple answer: “Yes”.  We will have to see.

All of which means that for the moment BPEL4People scrapes a bare pass on the sanity test:  If you are sure that your problem domain needs this type of functionality I recommend watching how implementations develop and planning on transitioning to BPEL4People when they are mature.  Otherwise, you already have standards and solutions capable of muddling through with.

Ronan