The idea is nice:
- You separate the business rules from the code.
- You use a graphical language that non-developers can understand.
- The developers then write adapters for the business process diagram to enact the business rules.
- Non-developers can both see and edit the business flow at any time in response to changing business needs.
The reality is different:
- Business rules aren't just boxes and arrows. There are conditions and data flowing along those.
- Dealing with conditionals and data flow means either putting code into the diagram (which is hidden in the UI and non-developers won't understand) or making the adapters more specific (which means they can't be connected anywhere).
- A graphical language is still a language which people have to learn.
The end result is that business people can neither understand nor change the diagram without developer assistance.
- It's an extra system to learn with its own DSL and a graphical editor which, like all graphical editors, is inconsistent and hard to use. It's easy to draw diagrams that don't do what they appear to be doing due to arrows not connecting properly.
- You now have two separate editors for your code which makes refactoring much harder.
- You can (and will) bypass the graphical editor and edit the XML files directly but since these are autogenerated they're ugly and don't make much sense.
- Debugging is very primitive. Maybe with a Java Toolchain this is less of a problem but for us it was a black box.
- It hides the true workings of the system. When we removed it and reimplemented the logic in JS we were shocked at just how little it was doing.
It took over a second to precess a single chat message. For comparison the JS state machine does it in a couple of milliseconds.