Workflow vs. Server Script

There's a lot of advice out there that says to use declarative solutions whenever possible and turn to scripting as a last resort only.  Hell, it's the basis of Siebel's technical document "Declarative Alternatives to Siebel Scripting".  I believe in using straight Tools configuration as much as possible, but there's one thing I'm not yet sold on: Using workflow processes in lieu of scripted business services for complex actions.

I used to believe what I heard, that workflow processes were superior to scripted business services - but then I decided to evaluate it for myself.  There are advantages and disadvantages to each approach, and I'll get to those later.

What originally sold me was the argument that workflow processes performed more strongly than server script because they did not have the overhead of a script interpreter.  The argument usually goes something like this, "Workflow processes run the compiled C++ code directly, so are faster than scripted processes that must be interpreted."  Well newsflash: Workflow processes also need to be interpreted.  Siebel did not build your workflow into their product, did they?  You described it using a tool, and that description must be interpreted at runtime.  Yes, compiled C++ is used to interpret your workflow processes.  And compiled C++ is also used to interpret your scripts.

Which interpreter is faster?  Which engine loads faster?  I ran some tests to find out.  The results show that the two were very comparible when performing the exact same operations.  If there were any differences, they were negligible.  My test updated the amount of a single revenue record.  Each process (scripted and workflow) did one query and one update.  After warming up the OM, each process completed in 57 milliseconds on average (which included the time to invoke each via a driver script).

What I did notice was that because workflow processes were not as descriptive as script, and you sometimes needed to do more work to accomplish the same task.  For instance, when I extended the test to update multiple revenue records, it took the scripted version 1 query and 21 writes to update 21 records, while the workflow processes needed 22 queries and 21 writes.  How did that affect the results?  The scripted process averaged a reasonable 500 milliseconds while the workflow process chugged along at 865 milliseconds on average.

So the results seem to say that workflows are just as fast as scripts when the performing the same operations, but the inflexibility of workflow processes can lead to algorithms that are less than ideal performance-wise.

Other reasons to like business services are that the development times are faster for various reasons.  The script debugging tools are more sophisticated, and starting your script debugger is typically faster than starting the workflow simulator - particularly if you need to deploy and activate a workflow subprocess before simulating.  And I don't think anyone would disagree when I say that scripts are far more flexible and powerful than workflow processes.

So what reasons are there to like workflow processes?  For one, they can be deployed without an SRF.  I'm guessing that benefit has not nor will ever be realized by a large portion of Siebel customers.  One reason that I like is that their level of instrumentation is far superior to script.  The workflow monitor and logging events are far more useful in a production environment than any script built-in instrumentation for script (there is almost none).  That can be invaluable in getting a production issue resolved quickly, for a problem that would normally be hard to reproduce and research.

In the end, I'm somewhere in the middle - but I'd have to say a bit closer to the script (read: dark) side.  What do you all think?