The Great Rules vs Process Debate

Business rules are used 99.99% of the time to provide discrete, stateless decision services to a stateful process flow that is itself independent of the business rules engine.  As Mark Proctor says, business rules engines currently are "glorified spreadsheets".  Is this the right approach to application architecture?  This is one of the big debates in software architecture circles, and is something we think about alot at my company within the domain of the telecom sector.  The ability of software to be more lightweight, agile and reflective of the intelligence humans would like to bring to their activities is ultimately, I believe, what is at stake in the debate.

In one corner, Paul Haley and Mark Proctor...

Paul Haley (founder of Haley Rules which was sold to Oracle) and Mark Proctor (development lead for JBoss Drools at Red Hat) argue passionately for the integration of rules with process.  Haley argues in this brief abstract that "until BRMS understand rules that refer to activities and events occurring within business processes, business rules applications will remain largely confined to discrete decisions, such as encapsulation within a decision service".  Proctor argues in his provocative "Vision for Unified Rules and Process", "after 30 years of research and development is that the best we have to offer, multi-million pound license deals that effectively boil down to glorified spreadsheets called via a stateless web services from some workflow engine?"  I agree with these guys.  They say more clearly than I did what I tried to argue in the paper I delivered at the Information Science Forum in Dresden this February - rules don't constrain static facts, rules constrain change.

In the other corner, James Taylor...

James Taylor, who built Fair Isaac's business rules engine (the #2 BRMS after Ilog) and is now a prominent consultant and the author of Smart Enough Systems, argues in "Please Don't Just 'Unify' Rules and Process" that "the reason for focusing on stateless decision services is that such a model is a good fit with how companies handle decision-making" and thus "while it may, intellectually, be interesting to consider them both [rules and process] forms of declarative programming, I am not sure such a collapsed view of the world is useful".  I would disagree with Taylor, because I think the reason why companies make decisions this way is because the business intelligence industry hasn't provided effective tools for operationizing business intelligence.  Instead, we've hoarded data in data warehouses accessible by complex database reporting tools (Crystal, Cognos, etc) that impose a turnaround time to any requests from managers trying to conduct their processes with more intelligence.

Comments

[Mark Proctor]

The de-coupled SOA approach absolutely simplifies things and is a powerful approach for this reason. I don't argue against it at all, I just don't want to limit my users to this only.

The beauty of the unified approach is that it's not an all or nothing. It allows you to work in the de-coupled SOA way, as James likes. But it doesn't prevent you going the other way, where the rules and processes are tightly coupled. Or maybe somewhere in between. I want to build a tool that allows the user to chose how they want to model the behaviour of application, I don't want to straight jacket them to one solution fits all, no matter how useful it is.

[viagra online]

Interesting blog, I agree because I think that spreadsheets are carrying the control or rather the rules of business