50

I've worked in past on some of the workflow engines as programmer but never had a clarity on why we chose the work-flow engines in first place. And as programmer I know that there are at least 100 ways to do anything when you are writing code but only few of the ways are the best!

I still don't understand which use cases are best solved by workflow engines (or rather their concept) than designing a good DI enabled application. I'm looking for any general characteristics of domain-neutral use cases, where work-flow engines are one of the the best options.

So my question is: What are general characteristics of a requirement which can be taken as a signal for opting for a good workflow engine and coding around it?

Improve this question
4
  • 2
    What's a "DI enabled application"?
    – jnewman
    Jul 17, 2012 at 18:31
  • I settled on dependency injection, but it took some heavy thinking...
    – jnewman
    Jul 17, 2012 at 18:37
  • 1
    @JasonTrue Oh so you too have used Windows Workflow Foundation !
    – Gilles
    Mar 26, 2013 at 19:19
  • @Gilles how could you tell? :P
    – JasonTrue
    Mar 26, 2013 at 22:07

6 Answers 6

Reset to default
25

A workflow engine is useful when you need to go from a start to a finish but there are many different paths/logic/rules to get there.

For example, let's say I write a program that publishes content. So, in my case, the publishing goes through a review process, legal, and then final approval. I write up the program implementing my process logic and steps. Now this work great for me and my company. So, I decide others should use my program.

Unfortunately, not everyone publishes content using the same process, so instead of writing separate processes for each different case, we would implement a work flow process so the program is flexible to accomodate everyone. No matter how many steps or rules or logic are between those two points the result is the same.

So, if you have processes that are variable from start to end, use a workflow. If the same process can be used by everyone, then you don't need a workflow.

Improve this answer
2
  • But how does that connect to the real world? You would have a database with "process records" tracking state according to a statechart for example, but then you still need to code the user interfaces and alerts, message I/O over messaging systems, ETL jobs etc. And then put all of this up in the center of a communication hub and run it. Is the "workflow engine" a fancy way of setting up the statechart and "running it"?
    – David Tonhofer
    Jan 18, 2018 at 11:23
  • @David - To an extent, yes.
    – Jon Raynor
    Jan 18, 2018 at 17:25
20

I know you asked for use cases, but it's easier to list the advantages than to imagine all possible use cases. The advantages of course depend on the engine and language you are comparing, but in general:

  1. Keeping rules as data instead of code means you don't have to recompile, so you can test changes quickly, change at run time, etc. Not much of an advantage if you don't have to recompile in the first place, though.

  2. Users can more reasonably be expected to edit the rules. They can potentially tinker with them interactively in ways that aren't feasible when having a programmer write code for them.

  3. Keeping rules as data allows tools to be written to visualize and change the data.

  4. Keeping rules as data allows meta-programming more easily - you can write code to analyze the data and insert more in some complex way, which would be very difficult for code.

All of these things are possible to do directly with code (e.g. - write a C# parser to find all rules of a certain type and generate code for more rules, insert it dynamically into an assembly in a manner that permits assembly unloading, write tools for users to be able do this as well using your visualizer and editor) but may be much more difficult depending on your language (programmers using a Lisp might refer to items 1-4 as "programming").

Improve this answer
5
  • 7
    None of these is actually an advantage in any reasonably complex project of any size. You will find yourself endlessly "debugging" someone else's rules which were thrown into the productive environment without adequate testing or documentation.
    – James Anderson
    Jan 23, 2012 at 4:23
  • +1 for Lisp reference - code is data, and vice-versa.
    – Michael H.
    Aug 28, 2012 at 21:43
  • 2
    @JamesAnderson: except the customer can now pay their own non-programmers (workflow consultants) to troubleshoot their own rules, without having to file a support case with the software vendor.
    – rwong
    May 12, 2013 at 21:17
  • @JamesAnderson - what you are describing is a failure of having a sound development process, not a failure of a rules-as-data workflow system. I've work in projects using them, and I've seen what you describe ... and also successful applications without the issues herein mentioned. The difference? Quality of process and quality of development teams.
    – luis.espinal
    Apr 14, 2021 at 21:53
  • @lius.espinal -- letting users play with rules and features nearly always ends in disaster! e.g. IBM once produced a nifty tool that let you write a GUI front end based on 3270 green screen interaction. I know of a project that got cancelled after six months because the dev team were unaware of this. When the users saw the proposed functionality the user reaction was "we already have this but better and more of it."
    – James Anderson
    Apr 15, 2021 at 12:54
3

IMHO the ONLY case where you should use this sort of thing is when it can be configured by less valuable users. If you can solve your problem by giving them a tool then going back to working on something else more important then use one.

If you still need to set it up for them then I would imagine you could think of 10 different way do get the same result with a tool you are familiar with and it will be a lot easier to support and customize.

Improve this answer
3

This looks like an old question, but surfaces numerous times in the wild. I agree with Jon's answer. I have found workflow engines to be highly productive in the following scenarios:

  1. There is an underlying business process that you are trying to represent / implement through your software.
  2. There is a single (maybe composite) business entity that is worked upon in all or some of the stages in the process. In the example Jon gave, this entity or Workflow Item would be content, or an article. Consider bug tracking as another example of a workflow, a Bug transitions between various states, based on an action a user takes.
  3. Use Workflows to model your processes, only if you expect the business process to change, by change I mean the sequence or action performed as a result of a user action or transition.

Be very careful and critical to see if your problem domain / requirements has a business process, don't try to "fit" it into a workflow.

Improve this answer
1
  • the thing I like about this answer is the part about "modelling" your process, i.e., drawing on a whiteboard. I think that will greatly illustrate whether a workflow engine would apply (based on the suggestions in these answers)
    – dave thieben
    May 6, 2012 at 15:52
1

I have a couple of guidelines I use for suggesting work-flow engines.

1) When the business analysts have no coding background but can draw diagrams.

Modern work flow engines use business process modelling notation, or the less capable versions available in SharePoint and similar systems. These allow technically competent yet coding-challenged members of the team to design and develop many work flows.

2) When you need to monitor the progress of work, perform escalations, flip back and forth between computer-controlled processes and human-controlled processes.

Monitoring and self-reference are hallmarks of modern work flow engines.

Improve this answer
-2

From a HR business perspective, work flow engines are very important.

  1. They provide a structured process, even if it is the same every time.

  2. They provide transparency

    • Who requested the change,
    • When was it requested,
    • Who approved etc.

    This transparency helps to drive the process and promotes ownership.

Assuming the forms are integrated and intelligent, supporting business logic, it also has a dramatic effect on timeline, processing efficiency and data quality. Security is also be a consideration and containing sensitive information in a secure system is much preferable to having paper forms lying around waiting to be signed. It is also much more mobile. After a recent implementation, one manager told me that it saved him a lot of hassle getting things posted to him for signing as he traveled a lot.

On behalf of HR: Long live workflow !!!

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.