1. "Changing code is difficult. Our organization has all these 'change management' processes in place. If we can just make the change in the workflow engine, we can deploy it straight to production."
Perhaps a workflow engine keeps you from shooting yourself in the foot by constraining kinds of things you can modify in your system. However, change control processes also protect your organization from all sorts of things: fraud, business rule errors, etc. I once worked for an organization where project managers wanted to put business logic in the database because they were allowed to change it at will! Just because changes don't fall within the scope of your change control processes doesn't mean that those changes are safe to do at will. This is the same fallacy that led people to believe that SOAP was great because it could get through firewalls. The only reason admins would punch large HTTP holes in their firewalls was because they believed the risk of serving up web pages was relatively low, monitored, and contained.
2. "Coding is done by expensive software developers. Business uses can make these changes if we implement a workflow engine."
It's not syntax that keeps non-coders from becoming decent developers. It's the ability to think in a structured, logical way. And, for anything but the most trivial uses of a workflow engine, one must be able to think through business processes in a way that only software development trains you for. What are the holes in this process? What happens if an employee quits who has active workflow items? How are they re-assigned? For years, business rule vendors (iLog, Blaze, etc.) have been making similar claims. In practice, I have seen that business rule system users are only allowed to make configuration changes (15% discount on Tuesdays instead of 20%) rather than more dynamic changes to rules (which are just declarative code).
With all this said, I still like the concept of jBPM and other workflow engines. State machines are a powerful way of ensuring correctness, and I would hate to throw the baby out with the bathwater.
1. "Changing code is difficult. Our organization has all these 'change management' processes in place. If we can just make the change in the workflow engine, we can deploy it straight to production."
Perhaps a workflow engine keeps you from shooting yourself in the foot by constraining kinds of things you can modify in your system. However, change control processes also protect your organization from all sorts of things: fraud, business rule errors, etc. I once worked for an organization where project managers wanted to put business logic in the database because they were allowed to change it at will! Just because changes don't fall within the scope of your change control processes doesn't mean that those changes are safe to do at will. This is the same fallacy that led people to believe that SOAP was great because it could get through firewalls. The only reason admins would punch large HTTP holes in their firewalls was because they believed the risk of serving up web pages was relatively low, monitored, and contained.
2. "Coding is done by expensive software developers. Business uses can make these changes if we implement a workflow engine."
It's not syntax that keeps non-coders from becoming decent developers. It's the ability to think in a structured, logical way. And, for anything but the most trivial uses of a workflow engine, one must be able to think through business processes in a way that only software development trains you for. What are the holes in this process? What happens if an employee quits who has active workflow items? How are they re-assigned? For years, business rule vendors (iLog, Blaze, etc.) have been making similar claims. In practice, I have seen that business rule system users are only allowed to make configuration changes (15% discount on Tuesdays instead of 20%) rather than more dynamic changes to rules (which are just declarative code).
With all this said, I still like the concept of jBPM and other workflow engines. State machines are a powerful way of ensuring correctness, and I would hate to throw the baby out with the bathwater.