jBPM can do what you are talking about.
You could :
1. have multiple processes definitions that map your functionality
2. have one process that has multiple transitions and pass a context variable around to indicate which path to take
3. have the nodes actually route themselves to different places (setNode).
There may be other options. Those are the ones that come to mind
I think option 1 is best, but option 2 could also do the job. I personally don't like option 3 because I think the process flow should match the process diagram, but you can make jBPM basically do whatever you want.
where application flow is substituted by processesThis is what BPM is all about; BPM is just geared toward large scale projects. To me, the real question is whether the scope of your application is large enough to warrant the overhead of injecting a BPM solution to drive it.
Even if each individual location doesn't have what they might consider to be a "large scale" application, that doesn't mean that value can't be gained by making them all together into a large scale project.
Using a BPM solution would insure that all locations are describing their processs the same way. This alone would go a long way toward solid analysis and standardization on best practices, etc.
Also, if your work can be described as one large parent process concept in which different locations perform certain parts differently, you could define one master process definition in JBPM that calls various sub processes based on location. Each location could develop their own sub processes.
as far as i understand the problem domain you are looking for some form of process inheritence, right ? where you can specify the skeleton of a process and fill in the details for the different locations.
of course, i have limited insight in your specific scenario. but most likely, the answer is that it seems hard to realize. i would stick to reusing parts of process with copy-and-paste rather then creating a centralized base process.
the problem is that it will be very hard to separate the parts of the processes that will be fixed and the parts that you want to customize for each location. processes don't have refactoring capabilities like java in your IDE and also your environment spans different deployement environments. so my first thought is towards using copy and paste reuse of process parts and only start exploring the jbpm features for reusing process-parts when you have a very clear insight in what parts you want to 'override'.
Tom may have been distracted by the snow conditions while answering this. I thind the use case is very valid. This is what jBPM is made for : structure your software around a graph. The graph is specified by the functional guys, the details are added in the graph as actionhandlers when certain events happen by the technical guys. Go ahead and defend your choice to your management!
The fact that you did not read about it until now is because we are desperately waiting for Tom's book to explain all this... But I hope he won't be in a ski resort when writing it ;-))
Talking about a ski resort..... no answers from me between the 23rd and 31st of december. Flachau will be my ski resort then.