Valid use case?

[bridge]

I work for an organization which is geographically spread. Some locations are large, others are much smaller, but they do the same kind of work. Historically the locations had a high level of autonomy. IT is one of those areas where differences occur.
Recently a reorganization of IT has taken place. The technical side was centralized and local IT departments (where I work) had to handle the 'functional' side. As one of the larger locations, my colleages and I tried to standardise and automate our internal processes. We hope that other locations will follow our initiative and (re)use the automated tasks, which are or will be written as Java classes.
Although a majority of the individual tasks tend to be 'universal', the details, aggregation and sequence of these tasks in processes will differ in the locations. For instance, some locations will use task a and b, but not c, or maybe c is started before b.
Looking at jBPM, I see an opportunity for realizing this scenario. A business analyst can describe a local process, and then a designer/programmer can decorate that process with automated functionality. Eventually a repository of processes will be created and gradually differences can be eliminated and improvements can be added. A positive side effect is that business requirements are not locked up in a monolitic application and that change is relatively ease to implement.
What worries me somewhat is that I haven't read about such a use of a BPM product, where application flow is substituted by processes. Is this a valid use case in jBPM, or am I to ambitious? As I have to defend this solution to my management, could you give me your experiences or reasons, why this is not the way to use jBPM. Thanks in advance!

[sforema]

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.

Sean

[brittm]

where application flow is substituted by processes

This 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.

-Britt

[tom.baeyens]

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'.

regards, tom.

[koen.aers]

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 ;-))

Regards,
Koen

[kukeltje]

Talking about a ski resort..... no answers from me between the 23rd and 31st of december. Flachau will be my ski resort then.