How do you know when you need a BPM solution?

Question

My customer is looking for a Business Process Management (BPM) solution. What they need is simple document routing and an approval system. What are the drivers for implementing a BPM system? What is the threshold where a developer should suggest implementing a BPM solution vs. a workflow tool or custom development?

When does jBPM fit? When does a state machine built into an app fit? What problems should exist that determine that you need to go with a solution similar to jBPM?

I am looking for some real world examples of "we tried to build the solution ourselves, but ended up going with AquaLogic/jBPM/Lombardi because of _". Please fill in the blank.

Answer 1

BPM Acid Test (from Essential Business Process Modeling by Michael Havey, published by O'Reilly).

... BPM is suited only for applications with an essential sense of state or process - that is, applications that are process-oriented. An application passes the BPM acid test if it is legitimately process-oriented. The travel agency application, for example, passes the test because it is best understood in terms of state of the itinerary and is defined at all times by how far the itinerary has gotten. Other typical characteristics of a process-oriented application include the following:

• Long-running -

From start to finish, the process spans hours, days, weeks, months, or more.

• Persisted state -

Because the process is long-lived, its state is persisted to a database so that it outlasts the server hosting it

• Bursty, sleeps most of the time -

The process spends most of its time asleep, waiting for the next triggering event to occur, at which point it wakes up and performs a flurry of activities.

• Orchestration of system or human communications -

The process is responsible for managing and coordinating the communications of various system or human actors.

... For example, in an automated teller machine, which lets users query their account balance, withdraw cash, deposit checks and cash, and pay bills - any sense of process is fleeting and inessential; an ATM is an online transaction processor, not a process-oriented application.

Answer 2

I wrote a workflow engine, because my employer wanted to own the IP, modeled after jBPM. Now the reason you use such a tool, instead of creating your own finite state machine, is accommodating changes without altering persistence and supporting edge cases of workflow processes as I'll explain.

Accommodating Changes Without Altering Persistence

Your typical, or perhaps better to call it "naive", finite state machine implementation features a set of database tables tightly coupled to the data managed and the process it flows through. There might be a way to keep past versions and track who took what action during the process as well. Where this runs into problems changes to data and process structure. Then those tightly coupled tables need to be altered to reflect the new structure and may not be backwardly compatible with the old.

A workflow engine overcomes this challenge in two ways, by using serialization to represent the data and process, and abstracting integration points, in particular security. The serialization aspect means data and process can move together through the system. This allows data instances of the same type to follow completely different processes to the point the process can altered at runtime, by adding a new state for instance. And none of this requires changing the underlying storage.

Integration points are means of injecting algorithms into the process and ties to authentication stores (i.e. users who must take action). Injected algorithms might include determinations of whether or not a state is completed, whereas authentication stores example is LDAP.

Now the tradeoff is difficult search. For instance, because data is serialized, it's usually not possible to query historical information - other than retrieve the records, deserialize and analyze using code.

Edge Cases

The other aspect of a workflow tool is the experience embedded into its design and functionality that you will likely not consider rolling your own and may live to regret when you do need it. The two cases the come to my mind are timed tasks and parallel execution paths.

Timed tasks are assigning an actor responsibility for data after a certain duration has passed. For instance, say a press release is writ and submitted for approval, and then sits for a week without review. What you probably want your system to do is identify that lingering document and draw attention of the appropriate parties.

Parallel execution paths are uncommon in my experience (Content Management Systems), but are still a situation that arises often enough. It's the idea that a given piece of data is sent down two different paths of review or processing, only to be recombined at some later point. This type of problem requires having useful merging algorithms and the ability to represent the data multiply simultaneously. Weaving that into a homespun solution after the fact is much trickier than it may seem, especially if you want to keep track of historical data.

Conclusion

If your system is not likely to change, rolling your own may be an easier solution, particularly if changes can break old information. But if you suspect you have a need for that type of durability or will experience some of these uncommon but thorny scenarios, a workflow tool provides a lot more flexibility and insurance that you won't paint yourself into a corner as the data and business processes change.