|
|
|
|
|
|
by dinobones
703 days ago
|
|
|
We rolled our own workflow engine and it almost crashed one of our unrelated projects for having so many bugs and being so inflexible. I’m starting to think workflow engines are somewhat of a design smell. It’s enticing to think you can build this reusable thing once and use it for a ton of different workflows, but besides requiring more than one asynchronous step, these workflows have almost nothing in common. Different data, different APIs, different feedback required from users or other systems to continue. |
|
|
Probably so, but the real design smell seems to be thinking of a workflow engine as a panacea for sustainable business process automation.
You have to really understand the business flow before you automate it. You have to continuously update your understanding of it as it changes. You have to refactor it into sub-flows or bigger/smaller units of work. You have to have tests, tracer-bullets, and well-defined user-stories that the flows represent.
Else your business flow automation accumulates process debt. Just as much as a full-code-based solution accumulates technical debt.
And, just like technical debt, it's much easier (or at least more interesting) to propose a rewrite or framework change than it is to propose an investment in refactoring, testing, and gradual migrations.