More and more people today realize the importance of introduction workflow into their solutions. But when it comes to the actual implementation, build vs. use, the debate is still going on. In his new post "Workflow engine? Building one..." Bernd Rücker weights in on the issue by discussing several common misconceptions surrounding it.
According to Bernd, typical reasoning for building "home-grown" workflow engines includes the following:
- We only have very basic requirements, a very simple state machine. A workflow engine is overkill.
- An engine should be part of our application.
- We have evaluated the product x and it simply does not fit.
Although, at the first glance, those seem like valid concerns, they rarely justify efforts and expenses of the "home-grown" implementations.
We only have very basic requirements and consequently can’t justify time and effort of learning new technology/implementation. As a result, many implementations start with a simple database table, capturing each process instance and the state it is in. But now, what if it is necessary to support
- wait states with storing instance variables?
- timeouts?
- escalations?
- decision gateways?
Bernd notes that based on his experience, although implementation does sometimes starts simple, the set of requirements tends to grow over time and at the end companies are typically "stuck" with maintenance and support of the full-blown workflow systems.
An engine should be part of our application and as a result we do not want to introduce a lot of dependences on additional hardware/software/integration/installation procedures (typical requirements for many commercial engines).
Bernd’s suggestion for such scenarios is to consider a lightweight Java workflow engine, which can be easily included into your product. Examples of such engines include, for example, JBoss jBPM, Nova Bonita or Enhydra Shark. This class of engines typically includes a wealth of configuration options, which makes them easily adaptable to specific application requirements.
We have evaluated, it does not fit is one of the hardest arguments to deal with. According to Bernd, the issue here is that a reasonable evaluation, even for a lightweight open source workflow engine, requires time and effort. If not enough time has been spent on evaluation of the engine, then the results are often insufficient. If enough time is spent understanding the technology, it is rare that the implementation does not provide required functionality. Bernd states, for example, that none of his clients found anything, that they could not easily implement using jBPM. It just takes time to understand the technology.
Bernd summarizes his post in a following way:
Please, do not develop! [It is a very expensive undertaking]. The learning curve [for understanding an engine] is almost always worth it!... [Once you understand how to use] the advantage of using an engine [becomes] self-evident.
People today rarely implement their own database or O/R mapper or application server. Why is it often that people think that they should write their own workflow engine? Workflow engines become a commodity and it is nearly always more cost effective to use existing implementation then design and implement your own.