Skip navigation
2006

Tom Baeyens's Blog

July 2006 Previous month Next month

 

The process modeling versus implementation debate continues:

 

Other posts in this discussion:



The clean handoff says business does modeling, IT does design, and anything that blurs that separation is inherently dangerous. (In fact, even directly creating skeleton design from the model is somewhat distasteful, but don’t worry, IT can change it later…) The collaborative vision says the line between modeling and design is a fine one and blurring rapidly. ... Ogren sums it up in one line: “The process model is the implementation.”

 

The difficulty in getting concensus in this discussion is that there are various skill levels of business people. Some just barely know how to use a word processor, while others are able to do some minimal coding.

 

As you put it nicely, we are in the "the clean-handoff vision" camp. But I don't think that the two visions are that far apart. I would like to refine our position and show where I see the touch point.

 

The clean-handoff vision doesn't imply you need IT to make it executable. Even in the clean-handoff vision you can strive for good coverage of process langauge constructs. The more constructs the better. But there is a fundamental tradeoff: A process language with a process construct for everything that a business person ever might want to express in a process diagram box will become too complex. The more coverage of the process language, the more complex it will be. The simpler the process language, the simpler the GUI will be and the lower the entry barrier for less technical business people. This implies that we are not looking for the ultimate process language. We can think of many process languages that make sense, I would even include Keith's spreadsheet as one of them.

 

So that is why it is hard to agree upon a specific process language: there is a whole range of process languages on the spectrum. A process language targetted to have non-technical business people create executable business processes will be very different from a process language that tries to have a broad coverage.

 

In my opinion, the process only 'is the implementation' in case the used process constructs are covered by the (always limited) process language. I would like to rephrase this as 'The process can always be a projection of the implementation'.

 

In this context, I see 2 features missing in most of todays BPMS solutions:

  1. Pluggability of process constructs: Most languages offer a fixed set of process constructs. The bridge to a general purpose programming language has to be natural in such a way that a developer can code the process construct if it is not available out of the box. In jBPM (based on graph oriented programming) and windows workflow foundation this is key. I see the article by Daniel Rubio on Winfows Workflow Foundation as one the first signs that this idea is being picked up.

     

    One of the nice implications is that you will have a kind of empty process engine with a default set of process constructs that come out of the box. The process constructs will be deployed in the engine in a packaged format. A process construct package includes the runtime implementation, and optionally a description of the configuration parameters, an icon, a UI form for the configuration parameters, a projection that filters the design time information from the runtime information to be used during process deployment,...

  2. Hidden actions: A developer has to be able to add technical details invisibly so that the business people can remain in control of the graphical representation of the process. This can be realized with some kind of event mechanism in which general purpose programming code can be associated with events in the process without the requirement of representing this visually.

 

OK, so here's my prediction of two movements that will be happening in the BPM arena. Please, interpret this overstatement as a challenge and motivation to write your response down :-)

 

1) The quest for the ultimate process language will be replaced with embracing a model like windows workflow foundation or graph oriented programming. These are actually models that define the interface between the process engine and the process constructs thereby making them pluggable.

 

And 2) More emphasis will be on the individual process constructs and less on complete process languages. That is much more feasible then trying to come up with a complete process language. This will result in node packages that you can drop in a kind of deployment directory in our generic engine. Once the interface between the engine and the node packages is defined clearly, this can create a similar component model as with e.g. JSF-components.

 

To conclude: I see the clean handoff vision as an extension to the collaborative vision. In the collaborative vision, business people model the process and the process is the implementation. It is certainly possible to have business people create executable processes in some scenarios. Depending on how complex your process language is (or how many simple process languages you combine), and the technical skills of your business people, the scope of this kind of process automation will vary. I subscribe to the above and see the clean-handoff as an addition. A technical developer should be able to easily integrate programming logic in case the business person cannot express an activity with the process constructs offered by the process language.

 

Comments can be posted here in the jboss forums.

 

regards, tom.

 

Finally, an interesting online discussion about BPM workflow and orchestration ! :-) This is a reply on Keith Swenson's What BPM can learn from a Spreadsheet. For a long time I was jealous at the Aspect Oriented Programming (AOP) community with their lively and high quality online debates which actually helped to get extremely fast mindshare in that field. I can only hope we can reproduce such speed of discussions in BPM, workflow and orchestration.

 

First of all, apologies if my writing style would suggest in any way that i know things better. I know that I get interpreted sometimes that way. It's unintended cause after all these years, I really still feel like a beginner. I can only assume that all of us (in BPM) are in this exploration of how to create and use BPM technology to the fullest of its potential.

 

Now for my response: Yes, I'm in the camp that think that 3GL will be necessary in certain environments. Note the nuance 'in certain environments'. I don't believe in BPM becoming a graphical 4thGL for developing software. For each recurring problem in Java and other general purpose programming languages, little computer languages are created called Domain Specific Languages (DSLs). Of course, this is not a new phenomenon. I see the future of software development as mature DSLs, optionally embeddable in a general purpose programming langauge.

 

Currently, many of the DSL's are hosted in XML because of the easy syntax, parsing and tools support. First generation of language workbenches are on their way to promote DSLs to first class citicens of software development. But there still is quite a road ahead in that direction, I believe.

 

The point I make is that a process language DSL needs to be embeddable in a 3GL general purpose programming langauge. So that you can use em stand alone but also integrated into a programming environment if you need the extra flexibility.

 

An example of a stand alone use case of BPM technology is the typical hello-world-bpm-demo-look-ma-no-code. In those demo's a new process is created from scratch. A few clicks in a graphical designer and instant deployment to a runtime environment. Voila, no code written and we have a new application. I DO think that this is a viable software development strategy in some limited number of environments. But i HATE the marketing pitch that usually comes with these demos like "You can get rid of your expensive, stubborn developers and replace them with business aware analysts".

 

The process diagram is just 1 aspect of a typical application. In some limited number of cases, you can stay within the boundaries of what the tool offers with forms around the graphical diagram. But this can never be taken to the level of flexibility to implement a comple typical project. In such a project, there are a bunch of requirements. And in most project's, only a part of the requirements will be covered by what you can do with a BPM DSL. In some projects that part will be big, in others it will be small. So We focus on a clean integration between those two worlds, rather then trying to expand the BPM DSL to cover every thing.

 

Main research is not how far can we take BPM process languages, but how can we raise the bar so that it becomes a new ubiquitous paradigm in software development. In that context, we defined 'Graph Oriented Programming' (very similar to M$ workflow foundation). In essence this is a technoque on how to bind pieces of programming code to a graph and how to execute it. On top of this technique, you can build process languages and complete BPM Suites, orchestration engines and other process languages.

 

In our experience, we have found that the easiest language to support BPM is a language that has fairly rich semantics, meaning that you have a large pallette of workflow constructs out of the box. Those constructs can then be used and configured without coding. But 'Graph Oriented Programming' is a very extensible foundation. It's very easy to include custom node- (or activity-) types and also to include pieces of code that are hidden from the process diagram. Those features are key in creating a clean bridge between the BPM Suites world and the programming world. So my main point is that I believe BPM Suites approach can be used IN COMBINATION with plain programming. They don't need to exclude each other. Note that with 'in combination' I mean a nice and clean integration. Not a bridge that shows it 'is possible' to get the two worlds to talk to each other.

 

So we currently have a limited number of functional constructs out-of-the-box (e.g. an email-node is on its way). We know that is an area we have to work on. But users appreciate the fact that a developer can just revert to the java API in case it's necessary. So the business analyst that draws the diagram doesn't have to be concerned with checking if there is a process construct available for what he/she is about to draw.

 

As an alternative to BPMN, i want to position our current graphical approach. By no means we claim that our approach is better. It's just different in the sense that it's simpler and more informal. So we present nodes as rectangles and inbetween nodes you can draw transitions as arrows. Out-of-the box node constructs can have an icon that is shown inside of the rectangle to indicate the type of behaviour. We envision some graphical decorations, but not much. All of this to lower the entry barrier for business analysts. Formal analysis languages like BPMN have the advantage that they're more expressive. But the downside is that you have take the learning curve in order to take advantage of the extra expressiveness. I still have an open mind wether the ubiquitous BPM language of the future should be like our simple approach, BPMN, something inbetween or both.

 

Hmmmm. the '2 lines of introduction to my answers' have turned into a bit more i see. Sorry for that. But the good part is that we'll have a good basis for explaining my answers :-)

Consider how Excel has allowed people to directly construct the application. They put in a few numbers, then a few formulas. Before too long, they have a spreadsheet where numbers can be entered in one place, adn answer appear in other places.

 

A spreadsheet is a very good example. It's a simple DSL.

 

Some people are able to fill in fields. Others are able to create simple formulas and the pro's are able to define nice graphics and include VB script. The more tech savvy you are the more flexibility you can get from it and the wider the coverage of use cases.

 

Another aspect that can be shown with spreadsheets is that the more you want to coverage with your language, the more complex it will be. E.G. Overall, spreadsheets do a fantastic job of putting the simple things in your face while keeping the advanced features on the background. Which is very important and a lot less obvious in text based language design. In our jPDL process language we have spend a fair amount of energy on creating and selecting the right defaults.

 

But by definition, a DSL will never be a general purpose programming language. And so the two will be used together and the DSL has to be embeddable into a general purpose programming language in a nice and clean way.

I disagree. Consider how Excel has allowed people to directly construct the application. They put in a few numbers, then a few formulas. Before too long, they have a spreadsheet where numbers can be entered in one place, adn answer appear in other places. The “searching for how things work” (which is what Tom defines analysis as) is completely integrated in the implementation of the final application.

 

Integrating the analysis environment into the implementation environment can indeed be very helpfull. This has been our focus for BPM and process flows.

Why can’t the same be true for BPM? Why can’t we simply draw a sequence of step, describe them in English, assign them to people with simple formulas, define a number of variables to hold values in, and have a working application? Will it be any possible application? No. But this type of programming could cover a wide range of applications that are needed today.

 

Integrating the analysis with the implementation is what led us to our simple graphical notation. That is how close we could take modeling to the analyst without loosing executability, which is our primary goal. Focus is on giving the analyst freedom of the diagram and the ability to document in free format text. I believe that it is impossible to integrate analysis and implementation environments with more formal languages like e.g. BPMN. Especially if the ties with the executability are kept in place. Things become different when looking at pure analysis languages like in IDS-Sheers ARIS. That's a language that is primarily targetted at writing down an analysis. Making these analysis models executable is not straight forward. While they claim a link with SAP's NetWeaver as an implementation platform, they add that this link will never be automatic and transparant because the primary focus of the ARIS language is analysis.

There is a strong business need to take BPM out of the software development lab.

 

If you replace 'take out' with 'expand to the analysts', we agree :-)

But just like those users who got tired of waiting for R&D to code up those reports turned instead to VisiCalc to do it themselves in 1980, so also will the business users turn to BPM tools that allow them to implement the application directly, without traditional programming.

 

You can make BPM languages that can be operated by business people. But in my opinion, they always must be embeddable in to plain programming for extra flexibility when you need it. 'When you need it' depends on the skills of the BA's, the complexity of the language and the requirements.

 

In conclusion I do not think that our vision is mutually exclusive with Keith's. I see exactly the same use cases for BPM technology as Keith does. The only aspect that i would like to add to the picture is that BPM process langauges can and should be made embeddable in a general purpose programming language like e.g. Java.

 

regards, tom.

 

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:

  1. BPM vendors often overpromise by hinting that BPM tools can unify analysis with implementation
  2. 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.

Filter Blog

By date: