I suspect that the first person to associate BPEL (Business Process Execution Language) with BPM (Business Process Management) was a great mind in marketing from some PR agency and never read the actual BPEL specification. The specification is not that easy to read. So i guess that is why this marketing buzz spreads itself much faster and further then then the knowledge of the specification.
How's BPEL different from BPM
BPEL is a web services programming language. You can write new web services as a function of other web services. Interface to a BPEL process is XML based (WSDL to be pore precise) and the variables inside of a BPEL process are XML snippets.
Oracle is currently the only force pushing BPEL in the marketplace. I got a Google alert on 'BPEL' and rougly 7 out of 10 items are from them. Recently launched Oracle Fusion. That is their new ERP platform that combines all their purchased products. In their Fusion vision, they put BPEL as the integration glue between all those applications. I think that makes sense. That is using BPEL as an integration technology. But they still associate all this integration with BPM. I consider this a legacy misunderstanding.
The goal of BPM is to make an organisation run more efficiently by carefully managing the core procedures and operations. Information technology can be a big factor in making it happen. But most often the inertia of software can't keep track with the changes in the business processes. That is what all the BPM software products are aiming for. Creating an information technology that supports easy automation and easy maintenance of software for supporting the core business processes of an organisation. Little concensus about the foundations of such a technology have been established and hence this still is a highly fragmented market.
Agility is key... also in BPM
Achieving this goal requires software agility. Also Phil Gilbert, the CTO of Lombardi has got it right on in his blog 'BPElephant". Congrats to Phil for standing out in the crowd. It made me realize that i got tired of fighting the BPEL-BPM misconception. Thanks Phil, for sparking my fire again :-)
Agility in software development means removing all overhead from the software development process. The effort spent on software updates because of changing requirements should be minimized. Test Driven Development has been proven a crucial factor in this. So in our vision, a business processes should be developed exactly the same way. For each process, there should be a number of test scenarios with assertions that verify if the process does what it is supposed to do. Only with an extensive test suite (also for your business processes) you can implement changing requirements efficiently. Integration technologies like BPEL are *very* hard to unit test. And concequently it will never lead to an agile organisation when all of your business processes are modelled in BPEL.
Actually, this shouldn't be interpreted as if we (JBoss jBPM) are against BPEL in any way. On the contrary, we think it is a great *integration* technology. We just want to fight the perception that it is also a good BPM technology. We have not always said that clear enough. So to make that really clear: BPEL is one of the process languages in the jBPM suite and it's got half of our resources dedicated to it.
So what's the alternative
Now that you know that BPEL is not a BPM technology, what's the alternative. I wish that we could claim something like: "Look at tech X, it's stable, mature and it's backed by a broadly supported standard" We're not there yet, but there are already some very interesting products that can get you a long way.
IMHO, two products take a different perspective and are leading the way to consensus in how BPM software should look like: JBoss jBPM and Microsoft's Windows Workflow Foundation. The goal of traditional BPM products is to create the ultimate process language The best process language ever ! JBoss jBPM and Microsoft's Windows Workflow Foundation support multiple process languages. Different environments require different process langauges.
For the first time in the BPM market place, two individual (at least to my knowledge:-) developed products look very similar. For Microsoft, this may have been a pragmatic approach, because they have multiple workflow and other graph based execution languages. So it makes sense for them to create a reusable base framework for all of these languages.
We started with Graph Oriented Programming 4 years ago. That is the simple and solid foundation for building graph based execution languages. In my future view, a limited number of process languages will be built on top of this technology. BPEL is one, but also a process language that cleanly integrates with the Java language is necessary. I can forsee a few other languages as well, but not a big number.
Knowing Graph Oriented Programming helps to understand BPM concepts in general. It's similar like the knowledge about tables, tuples, foreign keys and transactions in the world of database systems. In the broad BPM market, such a common foundation is completely lacking and has resulted in fragmented BPM marketspace we have.
Conclusion
BPEL is a good integration technology, but it is a clumsy way of supporting your business processes. We need an alternative. The most interesting alternative is the approach taken by JBoss jBPM, called Graph Oriented Programming and Microsoft's Windows Workflow Foundation. These are base frameworks on top of which graph based execution languages can be built. That approach is in my opinion a very good candidate for improving agility in automating Business Process Mangagement (BPM). IMHO, 2 things should happen with the highest priority:
- All technical architects should be prepared ! Have a look at what BPEL *really* is. So that they can tackle the misunderstandings their business managers make when reading marketing materials about BPEL.
- BPM vendors should challenge Graph Oriented Programming and the (similar) concepts of Microsoft's Windows Workflow Foundation. We should take the community of AOP (Aspect Oriente Programming) as an example. In the past year and a half, a public debate has lead to concensus and a great leap forward. My biggest wish is that we can duplicate such a story in the BPM community.
regards, tom.