For a while now, attempts of improving SOA implementations included its integration with BPM. According to James Taylor, a missing link in this undertaking is business rules management:
Don’t go to BPM or SOA and ignore rules - the future involves rules, BPM and SOA. Business rules help business grow by giving you agility with compliance, consistency. They help you differentiate and expose the knobs and levers you need to drive your business.
Commenting on Jim Sinur’s presentation on why rules are important, Taylor outlined the following value of managing business rules and decisions:
- Prevent unacceptable kinds and levels of risk by monitoring warning signs and addressing root causes
- Accept the necessary consequences of doing business by monitoring thresholds and impacts, minimizing likelihood of risk
- Seize opportunities by identifying events and implementing a rapid response
In his presentation, Sinur described Gartner’s view of the rules. They will be at the foundation of the adaptive software leveraging both explicit rules and goal seeking capabilities. They will also act as a primary driver of business control of process.
Jim showed a continuum - from a few companies that embed all their rules in systems through a semi-structured sweet spot with a mix of rules and processes to a few that are completely rules-based and dynamic. Today the market is moving up the curve but is still mostly stuck at explicit navigation rules with a little more complex navigation. Once the market matures, some will need to move past rules-guided process behavior to rules-driven composites and rules-based dynamic processes.
Commenting on Taylor’s post, Tom Graves noted:
...it’s a good article - recommended reading. And I would strongly agree with its implication that there’s a real and urgent need for discipline around business-rules... [but] reading it, pretty much every one of my enterprise-architecture alarm-bells went off... it’s promoting business-rules as "the answer" - and for the most part IT-based "business-rules engines" at that.
In Graves’ opinion, this approach is too similar to other IT-driven business failures, for example, business process reengineering:
- placing all the business-rules into an automated system will lead to a "fit and forget" attitude unless there is a very strong emphasis on rule-maintenance - one of many "human factors" that were forgotten about in BPR’s rush to "IT-ise" all business processes
- identification and codification of business-rules assumes that the rules that can be derived from the people who run the existing processes are sufficient, invariant, accurate and complete - which, as early-generation knowledge-management also discovered, they rarely are...
- the viability of using automation for decision-making is dependent on the context - a fact of which frighteningly few IT-system designers seem to be aware
Graves explains that the shortcoming Taylor’s approach is in the fact that when it comes to business rules implementation by IT, the landscape is quite uneven. IT’s main strength is in supporting simple business rules based on a binary true/false logic. When it comes to non binary logic, for example modal logic or probabilistic logic, humans often perform better. IT is getting much better with pattern recognition, for example face recognition, based on comparison with the existing pattern/pictures, but probably it will not behave so well with the real-time chaos, where patterns are not known or do not exist. As a result, an IT approach to business rules automation might turn out to:
everything... reduced to simple rules, following a cart-before-horse thinking that everything should be done by IT, and simple rules are what IT handles best. In other words, dangerously back-to-front. It’s bad enough trying to get anything useful out of IT for decision-support; but using IT for all decision-making - which is the "nirvana" that the article would evidently prefer - is likely to be lethal. And I don’t quite know what we as enterprise-architects can do to prevent this headlong rush into repeating the exact same mistakes as in BPR and the rest - all that’s different this time is that it’s more explicitly coming from the ‘rules’ part of the process, rather than process-implementation overall.
Richard Veryard agrees with Graves, stating that:
- We should not assume that the business rules are sufficient, invariant, accurate and complete, especially if they are derived from the people who run the existing processes. Therefore the identification and codification of business-rules generally leaves something to be desired. (One way of putting this is that the Real resists symbolization.)
- There needs to be a very strong emphasis on rule-maintenance, otherwise placing all the business-rules into an automated system will lead to a ‘fit and forget’ attitude. (One way of putting this is a demand for double-loop or deutero-learning.)
- The viability of using automation for decision-making is dependent on the context
It is very hard to disagree with Veryard’s assessment. It’s definitely important to include business rules automation in our implementation. It is also necessary to decide which ones should be automated and which ones should be performed by humans.
