This question pops up regularly in my mailbox or on the jBPM user forum. Even when I was still a jBPM consultant, this question was the first line new customers asked me.
But there is no ‘all-in-one’ answer to this question. Like many answers in IT, the real answer is ‘it depends’. It depends on which frameworks you selected already. It depends on the expected load of the business processes. It depends on the existing systems which need to be accessed in the process. It depends if you want to centralize BPM knowledge in one application or not. And so on and so on …
jBPM is extremely flexible since our key feature is being embeddable in any Java technology out there. Pick your favorite framework, and I’m sure there is a way to fit in jBPM. But it’s the very same embeddability that often causes people architectural headaches. Mis- or underinformed people often want to take the easy path, and big BPM vendors know this.
A well-dressed sales guy will give a smooth presentation with colorful charts and he will promise you heaven and more. Of course, before acquiring the BPM system, you must first put (a lot of) cash on the table. That’s the way the world turns, right? And what are you getting: a big black-box server. You can send requests to it and it magically gives you the answer (hopefully it is the right one), hence the developer in the picture below that is painting on his screen. Paintings tend to look good from a distance, but you know that once you get close it tends to get blurry.
Big black-box servers don’t give you architectural headaches. No, on the contrary: they define how your architecture should look…
It could be me, but I like to keep things under control. I like to see what’s happening in my architecture, how it all fits together and which systems are communicating with each othe.. You know, that warm, fuzzy feeling you get once your own designed architecture keeps up with every load you throw at it. jBPM just gives you that openness en flexibility you need to build an architecture suited for your business, without having to suit your business to an architecture implied by a big black-box system.
Since jBPM is at its core just a simple Java library, there is no limitation on how you want to include it into your architecture. I’ll list a few of them here, but remember that jBPM will never be the limiting factor when designing your architecture. However, I do have my own ideas and experience. So, there is a definition I tend to use when people ask me about jBPM and architectures:
Many people don’t see a business process as part of the domain model (remember my black-box story …), but it makes a lot of sense if you think about it. What is a domain model? Well, it is a representation of your business domain, of the raison d’être of your business of company. What is a business process? Well … it is a representation of how your business does something to create value. It is a representation of domain objects communication in some fixed way (a ‘flow’) to create some business-specific value.
So what does this mean in practice? It means that concepts like a Task (eg ‘send inquiry’), a Process Instance (a ticket sale) or an actor are at the same conceptual level as the domain model. Do note it doesn’t mean to scatter around your logic (like custom activitities, service invocations, etc.). Best practices in architecture design do still apply, and even more with jBPM (since they are applicable without restriction).
So by now I hope you can understand why we at jBPM don’t like the black-box-magical-server approach. A domain model is often scattered around many architectural layers or applications. Nobody asks questions when a domain object tends to be used accross different layers, and it is the same for the business process. If it makes sense in your architecture to not centralize a business process, then do it. It will make your architecture more understandable and easier.
Like I said, this means you can use jBPM in a lot of architectural styles:
I’m sure that if you searched our user forum, you could triple this list in a few minutes.
This article is a bit of a side track in my current ‘jBPM4 real-life example: The Train Ticket Demo’ saga, but you’ll see that my ideas of this article are applied in the eventual Train Ticket Application (ie ‘jBPM on Rails’). Architecture designs tend to get a lot simpler if you look at BPM as part of the business domain. And jBPM just gives you that kind of control: flexibility and embeddability in any Java technlogy.
So, let BPM enrich your architecture, not cripple it.Use jBPM and free your architecture today!