I've now been at two clients in three years where developers have created what must certainly be considered candidates for the "mother of all workflows" award.
You know what I'm talking about here - the kind of workflow whose flowchart looks like some giant spider in some Indians Jones movie.
Anyway, it occurred to me that SAP actually uses workflow far differently in a lot of its own processing.
In particular, a certain type of data row in a transparent table has a whole bunch of status flags, and as things happen to the data row, the status flags get updated, and thru change histiory, the updating of these flafs often trigger worflows letting folks know that something must be done "next".
To me, this granular and atomic way of using workflows is a whole lot better than designing candidates for "mothers of all workflows" - particularly in an (E)SOA type universe where you want the process modelled and executed granularly.
The only exception I can think of is where the workflow is basically executing a set of paper-pushing steps, not all of which may be reflected by changes to SAP data tables.
Any thoughts on this matter?
I'm interested because I may be assuming a new position where I have to propose an overall approach to how the client should use workflow, and my instincts tell me to tell the client NOT to go for "the mother of all workflows" appraoch.
