The interesting thing is how general they are. ATG has been through several rule based systems, starting off with Targeters, and moving to Scenarios (and later Publishing) for a greater level of workflow.

Really, all rule based systems (and thus, all workflow) is the same. You have inputs -- usually an event of some kind. You have an action that you want to perform. And you have a condition that you want to meet before you execute that action. So when you get an event, you run through the list of conditions which you can test against that event, and then you execute the actions tied to the event. Simple, right? It's your old finite state machine again.

Rule systems have some very big advantages over conventional declaritive programming. They're self contained and have no dependencies. You can hook them up in whatever order you feel like and they'll just work. Not only that, but they're immediate. A business person doesn't have to ask a programmer to send out an e-mail to all male shoppers after the age of 45 on Friday -- he can just create the scenario himself, and have it there as soon as he can think it. Finally, they can be programmatically implied at a very high level. One approach which has been gaining traction for a number of years is the notion of UML generated code, using XOM for a true Model Based Architecture. This approach is still "out there", but could be the final realization of the dream of CASE tools.

Unfortunately, workflow systems have one big drawback. They are very processor intensive. This is not all that surprising when you take into account all the possible events, conditions, and actions that could happen. That level of flexibility has a cost associated with it. Being processor intensive is not always a sin, but it tends to mix badly with presentation, and so it's best to have events that occur "on the back end" away from the systems responsible for page rendering.

But even this isn't the biggest problem. The biggest problem with rule systems is that they're complicated. Programming languages are complicated, but we've developed a small arsenal of tools and coding practices to deal with that (so much so, I think we take it for granted too much). Rule systems exist on the backend as a complex web of states and data, and therefore it's critical that these systems have a nice UI that can make sense out of all of this.

And that's the real beauty of scenarios -- it can take all the guesswork out of creating a business rule by allowing you to create custom events, actions and conditions, and creating a UI which allows you to merge those objects into the system seamlessly, with whatever graphics and behaviour you need. This integration into the front end is what really takes hard work. To present an single intuitive interface to the user may not sound hard, but just think about how much Apple spends on it.