Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
11  
When you want to use a shiny but clunky wizard UI to and replace simple code with something hard-to-debug, hard-to-test, and full of opaque error-codes... That's when I recommend to use a workflow engine. –  JasonTrue Aug 26 '11 at 17:36
    
What's a "DI enabled application"? –  jnewman Jul 17 '12 at 18:31
    
I settled on dependency injection, but it took some heavy thinking... –  jnewman Jul 17 '12 at 18:37
    
@JasonTrue Oh so you too have used Windows Workflow Foundation ! –  Gilles Mar 26 '13 at 19:19
    
@Gilles how could you tell? :P –  JasonTrue Mar 26 '13 at 22:07
add comment

6 Answers

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").

share|improve this answer
3  
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 '12 at 4:23
    
+1 for Lisp reference - code is data, and vice-versa. –  khedron Aug 28 '12 at 21:43
    
@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 '13 at 21:17
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 '12 at 15:52
add comment

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.

share|improve this answer
add comment

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 !!!

share|improve this answer
add comment

protected by gnat Jul 10 at 6:13

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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