Can workflow or BPM simplify the way that software is being build ? Yes and no. Yes, it can improve the way that requirements are being translated into software. No, it will not enable business analysts to write software. BPM technology walks the edge between requirements and implementation. BPM vendors suggest the miracle that drawing a graphical process in their BPM tool will unify analysis, requirements and implementation. I guess it makes sense when you put it like this. But regrettably, many BPM vendors have a poor story on the bigger picture.
This post will address the two main problems i have with current thinking around BPM and workflow:
- BPM vendors often overpromise by hinting that BPM tools can unify analysis with implementation
- Lack of integration between processes and plain general purpose programming language
Analysis and implementation cannot be unified
Wether software development though a programming language like Java or wether it is developed through processes in an executable process language doesn't change the fact that a translation has to be made from the analysis over software requirements to an executable software model. The fact that it is graphical doesn't change a whole lot in that respect. A process developer has a set of process language constructs and needs to come up with a process that is a solution for the software requirements.
For the sake of this post, I'll define analyzing, as trying to understand the problem domain and creating a description of the problem domain. And let's define creating an implemention as creating software artifacts that are executable by a computer system. My main point is this: "You can analyze or you can implement, but you can't do both at the same time." This will have far reaching consequences and it was an important factor during conception of our jPDL process language.
Analyzing means searching for the way things work. You're concerned with understanding the problem domain and describing it as good as possible. Creating an implementation means that you are creating an algorithm in terms of primitive constructs. Executable process languages provide a different set of primitive constructs than a plain programming language like Java. But if the process language is executable it implies that you're building an algorithm.
Keith Swenson and David Chappell have been arguing that BPMN is (going to be?) the analysis model and that BPEL is to be seen as the runtime model. They triggered me in formulating these ideas. Consider the following as my comments on the bigger picture of their statements.
The more formal an analysis language, the easier it is to make the result executable, but the harder it will be to use it for analysis purposes. E.g. a text processor like "Word" and a drawing sketch will always be flexible enough to describe your problem domain. But that doesn't translate automatically into executable software. On the other hand, when using e.g. BPEL to describe your problem domain, --which is an executable process language-- you will be specifying an algorithm and forced to think in terms of how the computer system will execute your process. An executable process language is already executable, but it is less flexible to be used for analysis purposes.
The relation between BPM and Business Process Management Systems (BPMS) is often misunderstood. Even by many of the BPMS vendors. They often make it look like their graphical process designer tool enables to analyse the problem domain (in terms of processes), distill the software requirements and create an implementation in one go.
To illustrate our point of view, we'll show two separate chains and we'll discuss them in both directions.
Analysis Chain People and systems working together in an organisation /\ || || \/ Informal description of people and system working together in e.g. natural language or a sketch /\ || || \/ Formal description in a strictly formal analysis language
Implementation Chain Informal description of an algorithm /\ || || \/ Formal description in e.g. general purpose programming language or an executable process language /\ || || \/ Creation of the runtime artifacts. E.g. compilation. /\ || || \/ Deployment of the executable process into a runtime environment /\ || || \/ Runtime execution of the process
First of all let me make the remark that this list is only intended to illustrate the direction concept and the difference between analysis and implementation. It's does not intend to show that all of these stages need to be done in sequence. In practice, these stages can be skipped and executed in any order analogue to the iterative software development model.
The analysis chain shows that there are various levels of formality in which you can describe your target domain: Ranging from pure english text to a formal analysis method. As an example in this domain, IDS Sheer's ARIS is a good tool to write down your analysis in a formal language.
Separating the two chains represents the fact that we believe there is no natural link between the result of analysis and creating an implementation for software requirements. The direction we're taking in our jPDL process language is that we try to enhance the process with free format annotations and decorations such that it can accomodate some parts of the analysis domain. In many cases that might just be sufficient. But that doesn't change the fact that we're showing an implementation model.
Also the way we conceived the jPDL language was to be an executable process language (an implementation model) but with features so that it can accommodate parts of the analysis model. Of course, never in the pretension that we can replace an analysis model. In essence, the jPDL language defines how a graph can be specified, executed and how java code can linked in that graph.
jPDL comes out-of-the-box with a set of preimplemented node constructs (as like any other process language). But a developer can write code and link this code as the implementation of the behaviour for a node in the graph. This means that a business analyst can draw a node visually and describe the behaviour in plain english. Then the developer can write the java code to implement the description.
Also jPDL contains a mechanism for inserting pieces of Java code in the process without changing the diagram. This is necessary to give the developer enough freedom to make the process executable without messing with the business analyst's diagram. No other process languages I know of has a similar feature. And yet, it seems crucial to me to have some sort of separation between the diagram, owned by the business analyst, and making the process executable, a responsibility of the developer.
Without this feature, process creation always boils down to visual programming. First of all because other process languages restrict the process designer to use a fixed set of process constructs. Each process construct has a runtime behaviour so an analyst needs to think in terms of runtime execution rather then the process that needs to be expressed. Also because no hidden code can be inserted, every little detail needs to be represented in the diagram, even if the business analyst is not even slightly interested. The interest of the business analyst should be the discriminator: IF the BA is interested, it should show up in the diagram, otherwise it should be hidden.
Going back to the direction from informal to executable, you can now see that a business analyst can start modelling a process with nodes (rectangular boxes) and transitions (arrows). As long as there is undefined pieces in the process, it's not executable. Sometimes the business analyst already might pick the right node types from the pallette and configure them properly depending on his/her skills level. But most often, there will have to be some custom code tied to the process either as node behaviour or as actions which are hidden from the graphical diagram. Only when that is complete, the process becomes executable.
As a side note, we believe that it is bad practice to overload the graphical representation with massive amount of decorations to try and express every little technical detail of the process. But the most important point is that you can create a common language between the technical developer, who is responsible for making the process executable and the business analyst, who is responsible for coimmunicating the requirements. Having these discussions around a graphical diagram is extremely helpfull. That is why we created the simplest possible graphical representation for our processes: boxes and arrows. Only an optional icon and the stereotype in the box can give a hint to the actual runtime behaviour.
In the other way round, developers can start extracting and centralizing state management from their application logic and create processes to speed up development of a plain java application. Then, they can use a graphical print of the process in meetings with stakeholders. Note that the graphical diagram does not have to be kept in sync with round-trip engineering. The graphical diagram is in fact a projection of your runtime artifact. It's just 2 different views upon the same process.
BPM automation requires easy integration of programming logic
If you compare all software artifacts being created in a today's software development project, typically the largest portion of that will be written in a general purpose programming language like Java. Apart from that you have e.g. ant build scripts, hibernate mappings, deployment descriptors and various configuration files. In all of the BPM world, there is a complete LACK of vision on how processes fit in there. Processes are always considered separate.
While on the one hand, we try to accommodate analysis data in our jPDL process language, on the other hand, we made sure for a very clean integration with Java. In fact, the Graph Oriented Programming principles, which form the basis for jPDL can be applied to any other object oriented programming language.
In practice, this means that programming logic (Java code in case of jPDL) must be easily integratable into a process. Also processes must be accessible and executable via a simple Java API. And last but not least the API must integrate with the transactions and other services in the overall application environment in which the process is used.
Without a simple and clean integration with a general purpose programming language, a process language is not really suited for automating business processes. Take BPEL for example. While it's an excellent integration technology with great value, it's not very well suited for automating business processes. To include a piece of programming logic, you need to write a piece of code, expose it as a WSDL service and invoke that service from your process. Even without the XML/object conversion that would be a pain.
Process languages have 2 key features which are not available in programming languages like Java: support for wait states to express long running executions and a graphical view of the execution flow. Process languages targetted at simplifying BPM automation should focus on those two key features and leverage plain programming languages for what they are good for. Looking at most process languages, the process constructs are mostly configurable versions of some API usage where the API offers more flexibility.
Conclusion
Despite the suggestion by most of the BPM tooling, analysis and implementation cannot be unified. However it is possible to add features for analysis to an executable process language. But that doesn't change the fact that it's implementing and cannot replace an analysis model.
Currently BPM is associated with BPEL and integration. We believe that BPM is much better served with a process language that integrates nicely with a general purpose programming language such as Java. That doesn't imply that BPEL is bad. On the contrary, BPEL is a great integration technology. We simply want to pinpoint that the association between BPEL and BPM is inappropriate. For making the automation of business processes easier focus should be on creating clean integrations between process language and programming language such as we did with the jPDL process language.
Comments can be posted on this topic in the JBoss jBPM user forum.
