Barb starts by pointing out that rules can be developed, even though nothing has been defined by asking about baseball. She points out that a phrase like "3 strikes and your out" implies all sorts of things like what a "strike" is, who this rules applies to etc etc. She then walks through the example to show how you harvest rules e.g. all the rules for a batter being out, and that although baseball has a very complete and consistent rules most businesses will have contradictions and omissions. The end of the process should be a complete understanding of how the business operates.She goes on to talk about a recent KPI study that found 5 motivations for business rules:
- Agility (see the blog section on business agility)
- Knowledge Retention
- Compliance (see the section on compliance)
- Consistent Decisions
- (After the fact) A stronger Business-IT partnership
and four approaches to using business rules which she illustrated with some great examples.
- Business rules harvesting and then input to the SDLC. Often by mapping use cases to business rules as described here
Business rules harvesting and then input them into a Business Rules Management System
A case study for the first two of these found that some 70% of the rules were "wrong" - the code ran wrong and was worked around, the code did what was intended but there was a mistake.
Business rules harvesting from legacy systems for legacy modernization (see this section on legacy modernization)
She noted here that thousands of rules found in the code for one client mapped to just 150 "real" business rules and that legacy mining is really only a good idea when there is no alternative!
Business rules harvesting and business transformation by changing just manual processes or by telling IT to make changes
Can be done very fast to show the value of focusing on rules. The case study for this showed that this worked and helped generate interest in business rules management.
Interestingly some of these involve business and IT and some only require the business. Barb wrapped up this section talking about the Rule Maturity Model and how most companies working towards Agility (level 2) and Consistency (level 3) which require both a focus on business rules and some technology. She also emphasized that rule management can fail on the business side (not the right rules) or technical side (not working right.
Barb has a model of some 10 types of business rules tools. Personally I think this is a little extreme - I would not separate authoring, analysis, testing and execution into 4 tools as I think these are all tightly coupled parts of a real Business Rules Management System. I do think that having a way to manage strategy and map it to rules and a way to map rules back into the requirements process is useful. Rule Mining is clearly a separate tool, as are analytic tools for deriving rules. I might say then that there are four:
- Business rules management system with authoring and repository
- Strategy and process management tool
- Rule Mining tools (code and data mining)
- Rules as requirements management tool
Barb went on to talk a little about how decisions, and rules, can and should be mapped to multiple processes and use cases to emphasize the importance of traceability.