Columns

Business rules: Tips, traps and other pratfalls

• By Stephen Swoyer
• July 1, 2005

As you might expect with any emerging technology, business rules—even when implemented in tandem with a high-performance business rules management system—are anything but turnkey. In fact, most adopters report encountering a pratfall or two along the way to business rules bliss. Take Michael Koscielny, director of regional underwriting operations with automotive insurer and BRMS adopter AAMichigan. “The first thing I would tell anyone is to really understand what your rules are going in [to the project] and structure the project so that you understand what your rules are and how to make changes that adapt them,” he says. And even though proponents like to position the technology as more-or-less turnkey, that is, the business side defines its rules, programmers create the appropriate templates, and then Jane C. Business Analyst can provision rules as need be, Koscielny says this isn’t exactly the case.

“The thing we didn’t do was really understand what the testing requirements would be, particularly for regression testing,” he acknowledges. “We tended to focus on just testing the change, and not really regression testing the whole process. We’ve stepped back from that now and created a team of people to fully regression test that, so you miss some of the independence.”

Ron Ross, co-principal of consultancy Business Rules Solutions and executive editor of BRCommunity.com, says there’s another mistake that many codejockeys, particularly those of an object-oriented bent, typically make.

“Frankly, one of the limitations is that people are trying to use use cases to harvest business rules, and frankly that is a huge mistake,” he says, explaining that “in object-oriented programming, you have the case of a use case, that’s a modeling technique that attempts to analyze a user’s interaction with a system and identify the chunks of functionality that you need in the system so you can design the GUI and have a productive means of interaction.”

The problem, Ross continues, is that business rules do not easily lend themselves to this kind of an approach. “The point is that use cases were not developed for rule capture. That’s not their purpose, that’s not their function, and it’s really the wrong perspective,” he says. “Rules require more of a knowledge-oriented approach, they require more of a shared perspective, as opposed to one person’s interaction with the system. You have to think about what people know more broadly than just how they’re interacting with the GUI.”

Another issue, says Ross, is fully capturing or identifying rules, largely because so many “rules” exist only as undocumented knowledge in the heads of business users. “There’s this phenomenon I call the ‘gray-haired phenomenon.’ There’s always one or several people who seem to have in their heads the knowledge to sort of effect change. That’s one of the driving factors, which is knowledge retention. So a lot of time, you think, ‘Where the heck are [the rules]?’