I'll be at JavaOne to talk about jPDL, the workflow and BPM language for the Java platform. The talk will be on Tuesday from at 3:20 PM in Esplanade 304/306. You don't want to miss it so put it in your agenda.
I'm always interested to meet new people. Ping me at tom dot baeyens at jboss dot com in case you want have a chat while I'm in SFO.
Thursday, 26 April 2007
Thursday, 12 April 2007
The Schizophrenic Nature Of BPM
Business Process Management (BPM) has always had this disturbing identity crisis. Here's an interesting discussion between industry titans in which several symptoms can be seen:
Keith Swenson: The tipping point for XPDL (see also the comments)
Keith Swenson: Are apples more useful than oranges
Bruce Silver: The real issues with XPDL, BPEL and BPMN
Keith Swenson: The diagram is the meaning
Bruce Silver: Diagrams, models, and Metamodels... Oh My!
I want to put this discussion into a perspective so that you can see why I think they don't speak the same language. This post will try to establish a realistic view on how process modelling and executability can be combined.
On the one hand, BPM is all about letting non-technical business analysts create diagram models in all freedom describing how people and systems work together. On the other hand, the promise of BPM is that you can drop these models into a BPM System and a piece of working software is the magical result. This duality is already indicated by Phil Ayres in the comments: "...and very simply put, both standards live up to their names: XPDL - Process definition language; BPEL - process execution language." According to me, that is just an indication of the fundamental schizofrenic state BPM is in currently.
If you think about it, these two goals are in fact very distinct; Business Process Analysis (BPA) means creating a description of how people and systems work together. It's describing what is observed. On the other hand, creating an executable process means specifying how the BPM engine should behave to support this process. This comes down to specifying what a computer system should do and in that respect, it is no different from traditional programming. It needs the same kind of deterministic accuracy and completeness. The language is different, but the exact behaviour of a software system is defined in an executable business process.
There is only 1 kind of product in the BPM industry that can give complete modelling freedom to the business analyst. Those are the drawing tools that only have a graphical notation, but no runtime engine part. Think products like IDS Scheer's ARIS suite and Visio. But the bulk of the products in the BPM space have a runtime engine part.
Most of these products with a runtime engine component have suffered badly from the schizofrenic nature of BPM. They try to hide the technical part as much as possible, while the remainder of this post will argue that a technical aspect is an intrinsic part of executable process languages and their process engines.
We have been telling it for quite a while now: The graphical model of a process should be separated conceptually from the technical details. An executable process is most often a combination of the two. The following picture shows how we envision the process as a combination of the graphical information and the technical details that make it executable.
Non technical business analysts can look at the graphical part only. Developers will manage the technical details so that the whole business process becomes executable on a BPM engine. In practice, the line between analyst and developer is a bit more blurry. Depending on their technical skills, analysts might already provide some technical details they know. But for the sake of this post, I want to highlight the dual nature of BPM and that's why I put analysts and developers in very distinct roles.
So this results in a situation where the business people can understand a view upon the software artifact that could represent a business process. At the same time, that process actually runs on the BPM engine in production. We also think it's very likely that business analysts come up with the initial diagram for the process to be developed. But we don't believe that in general, non technical people will be able to write both parts of the process. That would imply that non technical people would specify the mission critical parts of your enterprise's IT infrastructure. This thought is as ridiculous as it is scary. Regrettably, it is still preached by many of the BPM vendors today.
This point of view clearly shows that there is a technical aspect to making business processes executable. A good BPM engine should *not* try to make the technical people redundant (which is an agreeable but unreachable goal) , but instead it should facilitate and ease the collaboration between business analysts and technical people.
In software development, Domain Specific Languages (DSL) are described as limited computer languages for a specific purpose. Todays software is full of such languages that have to be combined with a framework. Think any XML language in a typical Java development project: ORM mapping, IoC configuration information, deployment descriptors, IoC bean wiring XML files. Looking at the technical aspect of BPM, an executable process language is just another DSL. Therefor, BPM engines should fit right into todays architectures of software development. And this should not be interpreted as "oh,... it's just a library for developers without any focus on the 'Business' in BPM". On the contrary.
Also in the engines, a technical aspect is often overlooked. A process engine as a monolithic black box is already useful in some scenarios. But a process engine becomes usable in a much broader set use cases when it can be easily embedded into an application. How easy can the workflow engine tables be integrated in my application database ? How easy can test scenarios for processes be written and executed ? How much library dependencies does the engine have ? How easy can the transactions of the workflow engine be embedded in my own application transactions ? All these questions become very relevant when you want to deploy a process engine other then in the black box mode.
The conclusion is that technical aspects of workflow and BPM engines do matter. It's not because business people are involved somewhere in the creation of processes that process languages or process engines cannot have a technical side. When product vendors try to hide those technical aspects, they end up with schizofrenic Frankenstein monsters. So beware. Cause you don't want such a creature to end up in the core of your IT infrastructure, now do you ?
Keith Swenson: The tipping point for XPDL (see also the comments)
Keith Swenson: Are apples more useful than oranges
Bruce Silver: The real issues with XPDL, BPEL and BPMN
Keith Swenson: The diagram is the meaning
Bruce Silver: Diagrams, models, and Metamodels... Oh My!
I want to put this discussion into a perspective so that you can see why I think they don't speak the same language. This post will try to establish a realistic view on how process modelling and executability can be combined.
On the one hand, BPM is all about letting non-technical business analysts create diagram models in all freedom describing how people and systems work together. On the other hand, the promise of BPM is that you can drop these models into a BPM System and a piece of working software is the magical result. This duality is already indicated by Phil Ayres in the comments: "...and very simply put, both standards live up to their names: XPDL - Process definition language; BPEL - process execution language." According to me, that is just an indication of the fundamental schizofrenic state BPM is in currently.
If you think about it, these two goals are in fact very distinct; Business Process Analysis (BPA) means creating a description of how people and systems work together. It's describing what is observed. On the other hand, creating an executable process means specifying how the BPM engine should behave to support this process. This comes down to specifying what a computer system should do and in that respect, it is no different from traditional programming. It needs the same kind of deterministic accuracy and completeness. The language is different, but the exact behaviour of a software system is defined in an executable business process.
There is only 1 kind of product in the BPM industry that can give complete modelling freedom to the business analyst. Those are the drawing tools that only have a graphical notation, but no runtime engine part. Think products like IDS Scheer's ARIS suite and Visio. But the bulk of the products in the BPM space have a runtime engine part.
Most of these products with a runtime engine component have suffered badly from the schizofrenic nature of BPM. They try to hide the technical part as much as possible, while the remainder of this post will argue that a technical aspect is an intrinsic part of executable process languages and their process engines.
We have been telling it for quite a while now: The graphical model of a process should be separated conceptually from the technical details. An executable process is most often a combination of the two. The following picture shows how we envision the process as a combination of the graphical information and the technical details that make it executable.
Non technical business analysts can look at the graphical part only. Developers will manage the technical details so that the whole business process becomes executable on a BPM engine. In practice, the line between analyst and developer is a bit more blurry. Depending on their technical skills, analysts might already provide some technical details they know. But for the sake of this post, I want to highlight the dual nature of BPM and that's why I put analysts and developers in very distinct roles.
So this results in a situation where the business people can understand a view upon the software artifact that could represent a business process. At the same time, that process actually runs on the BPM engine in production. We also think it's very likely that business analysts come up with the initial diagram for the process to be developed. But we don't believe that in general, non technical people will be able to write both parts of the process. That would imply that non technical people would specify the mission critical parts of your enterprise's IT infrastructure. This thought is as ridiculous as it is scary. Regrettably, it is still preached by many of the BPM vendors today.
This point of view clearly shows that there is a technical aspect to making business processes executable. A good BPM engine should *not* try to make the technical people redundant (which is an agreeable but unreachable goal) , but instead it should facilitate and ease the collaboration between business analysts and technical people.
In software development, Domain Specific Languages (DSL) are described as limited computer languages for a specific purpose. Todays software is full of such languages that have to be combined with a framework. Think any XML language in a typical Java development project: ORM mapping, IoC configuration information, deployment descriptors, IoC bean wiring XML files. Looking at the technical aspect of BPM, an executable process language is just another DSL. Therefor, BPM engines should fit right into todays architectures of software development. And this should not be interpreted as "oh,... it's just a library for developers without any focus on the 'Business' in BPM". On the contrary.
Also in the engines, a technical aspect is often overlooked. A process engine as a monolithic black box is already useful in some scenarios. But a process engine becomes usable in a much broader set use cases when it can be easily embedded into an application. How easy can the workflow engine tables be integrated in my application database ? How easy can test scenarios for processes be written and executed ? How much library dependencies does the engine have ? How easy can the transactions of the workflow engine be embedded in my own application transactions ? All these questions become very relevant when you want to deploy a process engine other then in the black box mode.
The conclusion is that technical aspects of workflow and BPM engines do matter. It's not because business people are involved somewhere in the creation of processes that process languages or process engines cannot have a technical side. When product vendors try to hide those technical aspects, they end up with schizofrenic Frankenstein monsters. So beware. Cause you don't want such a creature to end up in the core of your IT infrastructure, now do you ?
Thursday, 5 April 2007
BPEL Compared To jPDL
Michael Neale of the drools team is giving a Talk on JBoss jBPM for the Canberra User Group. He mentioned my <sarcasm>*looooove*</sarcasm> for BPEL and asked me the pitch. In my reply, I explained that I don't think BPEL is bad, but that you have to know when to use it and when other alternatives are more appropriate. I think my reply would be interesting for more people, so I share it here.
BPEL is a process language designed to work on in a web services environment because it is based on WSDL. WSDL could potentially map to java beans as well, but it naturally maps to web services, while WSDL doesn't map naturally to java beans.
Deploying a BPEL process leads to publishing of a web service (a WSDL service to be exact), that is your interface to the process. Internally in a bpel process, the process variables are XML snippets (or xsd basic types). BPEL has some control flow constructs and a construct to invoke a WSDL service. So in essense, BPEL is in fact a language to script a new web service as a function of other web services.
BPEL has a receive construct, which means wait here until this message is received over the published service. This implies that the overall execution behaves as a wait state. Consequently, long running (spanning multiple server side transactions with long periods inbetween) processes can be expressed in BPEL.
Expressing long running processes (== support for wait states) is a requirement to model typical business processes in a language. Business processes like handling an insurance claim take a long time and involve several requests to/transactions on the server. So to support business processes, the runtime engine needs to behave as a kind of state machine. While BPEL has the wait state feature, which is one of the requirements for executing business processes, the assumption of an all-web-services-world makes it hard to integrate BPEL based business processes with every day software development in e.g. Java.
The thing that nobody seems to understand is that you can build state machines in Java as well. And typically much more simple then in web services technologies. That is where jPDL fits in. In jPDL the interface is a Java API and the process variables are POJO's. So this language embeds far better in a Java project.
Conclusion is not that BPEL is bad. The conclusion is that you need to select the process language that fits with the environment in which you are working and with the requirements you have. Use BPEL if you want to script new web services as a function of other web services in a mostly webservices environment. Use jPDL if you need statemachine capabilities in a Java environment. In both technologies it is possible to make the bridge to the other side, but that is of course requires some mappings and translations. So it is all a matter of selecting your process language based on the main development environment.
BPEL is a process language designed to work on in a web services environment because it is based on WSDL. WSDL could potentially map to java beans as well, but it naturally maps to web services, while WSDL doesn't map naturally to java beans.
Deploying a BPEL process leads to publishing of a web service (a WSDL service to be exact), that is your interface to the process. Internally in a bpel process, the process variables are XML snippets (or xsd basic types). BPEL has some control flow constructs and a construct to invoke a WSDL service. So in essense, BPEL is in fact a language to script a new web service as a function of other web services.
BPEL has a receive construct, which means wait here until this message is received over the published service. This implies that the overall execution behaves as a wait state. Consequently, long running (spanning multiple server side transactions with long periods inbetween) processes can be expressed in BPEL.
Expressing long running processes (== support for wait states) is a requirement to model typical business processes in a language. Business processes like handling an insurance claim take a long time and involve several requests to/transactions on the server. So to support business processes, the runtime engine needs to behave as a kind of state machine. While BPEL has the wait state feature, which is one of the requirements for executing business processes, the assumption of an all-web-services-world makes it hard to integrate BPEL based business processes with every day software development in e.g. Java.
The thing that nobody seems to understand is that you can build state machines in Java as well. And typically much more simple then in web services technologies. That is where jPDL fits in. In jPDL the interface is a Java API and the process variables are POJO's. So this language embeds far better in a Java project.
Conclusion is not that BPEL is bad. The conclusion is that you need to select the process language that fits with the environment in which you are working and with the requirements you have. Use BPEL if you want to script new web services as a function of other web services in a mostly webservices environment. Use jPDL if you need statemachine capabilities in a Java environment. In both technologies it is possible to make the bridge to the other side, but that is of course requires some mappings and translations. So it is all a matter of selecting your process language based on the main development environment.
Tuesday, 3 April 2007
Subscribe to:
Posts (Atom)