John Rymer, who I’ve read before on business rules topics, talked to us about why we should care about business rules software; Forrester’s position is that business rules are a key enabler of design for people, build for change.
He started with definitions of business rules and a business rules platform, then went on to state that business rules are an alternative to conventional programming: with business rules you don’t have to translate business terms into geek speak, and you don’t have to specify every possible combination of rules works. The implications are that business people are most likely to get what they need since they can actually understand the “language” in which the rules are written, and more complex problems can be more easily solved with much less time required to change systems. Software can even adapt based on the results of the rules; BPM is just one example of this, but business rules can be applied in the same way in other types of software.
Rymer showed how business rules can be applied in the areas of the “perfect storm” that Connie Moore mentioned this morning as causing the transformation that’s underway now: design evolution (rules add adaptation to context and design), process evolution (rules enable decisioning, auto processes, closed loops), workforce evolution (business people contribute to rules) and software evolution (rules enable global policies for SOA, service selection). He went on with a great list of how organizations benefit from business rules:
- Create applications that adapt; automate decision in response to business conditions
- Create applications that change quickly; one set of business rules for all applications rather than having the rules spread through a number of different applications and code sets
- Tackle the next automation frontier, decisions; capture the wisdom of the experts in rules where possible
- Put analysis to work through automation: take action using business rules and BPM
He gave some good examples from financial services, showing how business rules have been applied to core tasks such as credit scoring and underwriting, then expanded to areas such as fraud detection and call center programs.
He highlighted that business rules allow organizations to divide change management responsibilities, where business people take responsibility for maintaining the more volatile rules and processes, whereas IT remains responsible for maintaining the core rules and processes.
He ended up addressing the issues of why business rules haven’t really caught on; I see so little acceptance of this with many of my financial services customers and I’m not surprised, although it seems strange that a technology that can offer so much benefit is being ignored by so many companies. The top reason for not implementing business rules? “We don’t do things that way”, that is, they like to write their rules in Java code instead. He also cited lack of standards, high product cost (which I still don’t think is more than writing and maintaining that Java code), lack of participation from the big vendors, and a still-shifting landscape as other reasons for resistance to business rules.
Like Rymer, I believe that business rules will be a significant part of any agile organization. In some cases, organizations already have business rules software but it’s hidden away in one department, but you need to pull it out of the closet and put it to work. Forrester has a Wave (product comparison) for business rules, but he admitted that it’s a bit out of date; it sounds like a new one might be coming out shortly.