Carole-Ann kicked off RulesFest 2010 with a presentation highlighting the key pitfalls encountered when building large scale business rules applications. Continuing with her tradition of new presentation approaches, she used Prezi and drew a parallel between the travels of Columbus and the endeavours faced by those involved in business rules implementations.
Having worked with both BRMS leaders, Ilog (now part of IBM) and Blaze Software (now part of FICO), Carole-Ann has been exposed to numerous business rules implementation efforts, and draws on her experience.
Having a good understanding of the business object model
This seems obvious, but ensuring that the implementated business object model is semantically equivalent to the one used to specify the rules (whatever methid is used). With complex business object models, the space for mistranslations at implementation type is high – you may end up with business rules that make wrong assumptions about the business object model.
Special attention needs to be paid to identifying the section of the business object model that is used by the rules. Properly managing that coupling and understanding the performance, scalability and maintenability characteristics is fundamental to succeeding with large business rule projects.
Not trying to be smarter than the algorithms used
Another underestimated risk: attempting to manually tweak the rules processing – frequently for performance reasons – and getting on the way of the algorithms execution.
A couple of examples:
– use nested “if” statements
– micro-optimizations for performance reasons
These changes frequently prevent the algorithms for performing their task, get on the way of maintainability, are brittle to enhancements in the performance of the algorithms which may result in functionality and/or performance degradation.
Paying attention to the business rules presentation to business users
Business rules is mostly about the representation for the business users. Execution is important, but even more so is the ability for business users to understand, and even better, manipulate business rules themselves.
The key pitfall that Carole-Ann has seen over and over again is the following: extracting and expressing the rules in IT terms, and then, as an afterthought, attempting to expose them to business users. The result, most of the time, is point-and-click “if then” builders, or complicated technical user interfaces.
The reality that business users deal with is different – they deal with policies, with higher level constructs that may or not map one to one to business rules. In general, they don’t – a policy tends to be a combination of calculations, and rules. They naturally think in terms of rate tables, decision trees, etc.
The principle then is to make sure that the rules presentation used matches the way the business user thinks. One size does not fit all – different parts of the decision may require different representations.
Also, it is important to ensure that the business users are provided with the proper overall experience: the whole navigation from the point the user connects to the rules management application (whatever form that is) down to how they find the different rules, how they change them, etc…
Carole-Ann describes how in the projects she’s been involved she has focused first on the overall experience for the business users – navigation, business interfaces – and only after did she actually start writing/configuring the corresponding rules.
A number of questions on this section – Jacob Feldman, James Owen, among others, chimed in with pointed questions. A particular question was about identifying user interface patterns for rules expression – which specific techniques to use in which circumstances.
Even in this rather technical conference, the talk did get a lot of attention – does it mean the chasm between BREs and BRMSs is over?
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
