Guys, where are your workflow engines? Use them to improve software development

Workflow engines are underused and underappreciated. Most companies configure or develop enterprise software so that it implicitly reflects their business processes and leave it at that - big mistake.

Instead, workflow engine can be used to provide state diagrams for developers. They enable you to map and store the state of the system, as well as hook into state transitions that trigger events and functionality.

Using a workflow engine forces you to rethink the way you write software. It forces you to decouple business process from business software, which can help your software become more robust and componentized. You retain the atomic components of your logic - even if the overall process changes.

Further, using a workflow engine also provides solid documentation for your business process. A new developer, for instance, can understand the whole process at a glance, rather than only after they've read through thousands of lines of code or digested what a series of remote calls mean. Sure, you could document this anyhow, but I've rarely seen hand-generated documentation kept up to date after a few releases.

Unfortunately, I've seen few large projects actually organize the development of key business processes around a workflow engine. But I know of several embedded engines: In the Java world, for example, Alfresco contains the Activiti workflow engine, while JBoss ESB includes the jBPM workflow engine, an outgrowth of the Drools project. Activiti is a reimagining of the project that was previously known as JBPM (before version 5) by the same author, Tom Baeyens. On the .Net side, you have Windows Workflow Foundation.

Certainly, workflow engines make software a little more complicated and debuggers a little less easy to use. There are more moving parts and additional elements to deploy. But for larger projects with complicated business processes, the complexity is outweighed by the benefit of having your process as a first-class citizen rather than implied and distributed throughout your code.

Part of the problem facing more meaningful adoption of this techology is that the Business Process Execution Language standard overshadowed workflow engines and added too much "Web servicey-ness" to them. BPEL then bloated into a weird hybrid Web service scripting language, and all workflow engines had to support it to be "standards compliant." Frankly, this is a bad standard that tries to be all things to all people and misses the fundementals. In fact, I think distaste for BPEL spilled over to workflow engines and muted their use.

For many complicated projects, mapping the actual flow into a state diagram, visualising it, and executing it via a workflow engine would simplify maintenance, reuse, documentation, and developer onboarding. Workflow engines elevate the process to first class, rather than hinting at it in the code. While embedded uses are common, proper use would map both higher-order business processes and lower-order message transforms as processes. I'd love to see more - and more proper - use of workflow engines in complex projects.