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]?’