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, visualizing 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.
This article, "Fire up a workflow engine to improve software development," was originally published at InfoWorld.com. Follow the latest developments in business technology news and get a digest of the key stories each day in the InfoWorld Daily newsletter. For the latest business technology news, follow InfoWorld on Twitter.