Workflow is one of those classic terms that has a thousand different meanings to a thousand different people. Most people agree it's about modeling and automating business processes, but beyond are myriad interpretations.
Probably the most important single thing to understand about a workflow is that it's not an application. Workflows interact with applications, respond to, coordinate, and control applications, but workflows don't do work. They coordinate it.
Dave Green, one of the Windows Workflow Foundation architects, has a great explanation of the three workflows models for coordinating work:
· Sequential (flowcharts): This is the way most people think about workflow: the workflow is in charge. Work comes in at step A, it goes B or C, and finally D. Dave makes the point that this style is often too inflexible or quickly becomes too complicated to model business processes effectively.
· State-driven (state machine): Unlike sequential workflows, the user chooses the action for work. The workflow . This is more flexible than sequential, since it allows the user to make decisions about the best next decision. For example, when Michael suggested a good analyst has a choice of what action to take based on a rate request, he was describing a state-based workflow.
· Data-driven (rules engine): This is the most flexible. Rather than having explicit states, you simply define the rules (e.g. what can happen, who can do it, what’s affected by it, and how). Rather than worrying about the state of the system, you simply worry that all rules are followed correctly. Of course, the downside of this flexibility is that rules-driven systems can be much harder to test, since the states aren't explicitly identified.
How workflows implement these models is dependent on the individual system.