To start the therapy for the Business Process Management (BPM) identity crisis, we'll have to go back to its childhood. Why did we start messing with process languages in the first place ? Ah, yes! While all tools can draw process diagrams, the real reason was that we couldn't express process languages in traditional programming languages because they represent a sequence of instructions for the computer system. They don't have support for wait states.
To further expose the pathological state of BPM, I always use the DB metaphore: When I say relational DB, most of this audience thinks tables, columns, primary keys, foreign key references, SQL and so on. Every self respecting developer knows the concepts of this technology. For a technology that is a very sane state to be in. But in BPM, nobody knows the the concepts of state machines that can be used for business processes or what it means to execute those. Every engine has got its own execution model that looks like, but is not completely the same as the next engine. Yet we are creating process language proposals in abundance. It's like proposing query languages without knowing the difference between relational-, object-, hierarchical and object databases.
Can't be that difficult, right ? Afterall, it's just a state machine that we're adding to all programming language capabilities, no ?
Well, not quite so simple. State machines are used in a variety of ways. Different features and functions are added to improve support for those features. Also, there are different environments. E.g. a a service orchestration language like BPEL looks very different from a Java workflow language like jPDL. That creates a whole lot of combinations for which you can build dedicated process languages.
For therapy, the roots are state machines. All of those process languages have some form of state machine in there. That is because traditional programming doesn't have support for wait states (see many of my earlier blog posts).
Now let's reflect on this in real zen style. Close your eyes, but keep reading. Many flavours of process languages... many different features... but all represent some form of state machine.
After one of those sessions, it struck me that I should first learn how to walk before trying to run. Learning about the state machine basics is much more effective then trying to understand all the flavours of the different process languages. And once you get the state machine basics, it will be much easier to learn a new specific flavour of a process language if you need one.
Since I couldn't find good state machine concepts and terminology in the context of executable software, I just wrote it myself. I called it The Process Virtual Machine and a summary of that full article has been published at OnJava.
The Process Virtual Machine was my therapy for BPM. Every developer and BPM-er should read it and have an opinion on it. Feel free to let go and just share it as a comment on this post.
