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