BRITISH COMPUTER SOCIETY

SPA Specialist Group

Wednesday 11th January 2006 at 6.30pm at BCS, London

1 Introductory Lecture – SPA 2006 Spring Lecture Series

Paul Vincent, Rules Specialist and Product Manager, Fair Isaac

2 Introduction

Fair Isaac is a household name in the USA – the FICO score is a rating of creditworthiness. Paul’s specialism is Business Rules – how to manage them, how they relate to other topics in this series.

The small number of vendors in this space are all agreed that they would rather have happy customers than foist unsuitable products on them!

3 Drivers for BRM, BPM and SOA

A straw poll found that the subsets of the audience involved in each of these topics did not overlap!

Historically, software development has gradually moved to higher and higher levels of abstraction, culminating in model driven approaches in the 1990s and component-oriented SOA appraches in the 2000s.

Solutions are getting increasingly complex and having to be delivered faster with fewer specialists on the ground. It’s no wonder that the public perceives IT projects as frequently costly, late and/or failures.

3.1 Software development today

Customised solutions (e.g. ERP solutions such as SAP): all-in-one, single-vendor responsibility, but customisation can be time- and resource-consuming or even impossible; may end up having to bend the business to fit the tool

o One customer uses Fair Isaac’s rules engine to validate input from SAP forms!

Tool- and Component-Based (e.g. RDBMS such as Oracle): more reuse (few developers would decide to roll their own database management system as part of a solution these days), but at the cost of specialised training and high system integration effort

Custom application (typically in defence): fit for need, singular purpose, but development time & cost can be prohibitive and so can the system integation

In many large developments there will be a mixture of these approaches.

SOA (Service Oriented Architecture) fits into the tools/components approach. Services are made available and can be reused across an organisation – so developers have less excuse to ignore them.

Business rules supply a component that formalises the representation of decisions made in application development, which can be maintained independently and using a business-level language.

What remains when all the business logic has been extracted from a system? All the “system code”, if you like. There is in fact an industry built around tools to perform this type of re-engineering of legacy applications: the OMG calls it “Architecture-Driven Modernisation”. It tends to be fairly labour-intensive.

Business Process Management (BPM) is all about defining business applications in terms of business processes – usually in a graphical process studio of some kind – and then running them in that form.

So SOA/BPM/BRM combines to cover the advantages of custom and componentised approaches without their major disadvantages. Each of the technologies has a “sweet spot” where it is most applicable.

3.2 A business IT stack

Layers include:

Service

Process

Rules (business logic)

Database

Operating system / platform

Another view is to treat services as components knit together with processes. An optimal service-oriented IT architecture exposes each of the middle three layers as services.

Paul says that a service-oriented approach does not always imply a formal SOA. Judging the granularity correctly to trade off efficiency vs. reusability is a fine art. Static linking can work effectively in the right context instead of HTTP/XML.

Process / Flow layer

o Service

o Process Logic

o OS / Platform

Rules / Declarative layer

o Service

o Rules

o OS / Platform

Data layer

o Service

o Database / Persistence

o OS / Platform

Processes and rules can invoke services at any level in this three-tier approach.

Fair Isaac’s toolset allows definitions of components to be shared between applications / components, which increases reuse even more.

3.3 Disclaimer

SOA = Service Oriented Architecture – a specific technology

o SOAP, WSDL, UDDI, BPEL etc.

o Just one implementation of the service oriented approach

Service Oriented Approach is not necessarily SOA

o Services can be any software component mechanism

o Web services are considered immature technology by many

As a software-tool vendor, Fair Isaac is of course obliged to provide a Web Services implementation.

4 The Business Rules Approach

Business rules should be defined, stored, reported etc. in isolation from other entities –

In business documentation

In process definitions

In use-cases and system requirements

In the code

IBM WebSphere’s rule beans allow you to do this precisely.

Business rules should be defined declaratively

Changes to rule definitions should not require changes in other rules (except where there is a direct dependency)

Rules should be independent of order

Typically they are defined in a linear list – hierarchical variants are known (decision trees are an example).

4.1 Comparison with other approaches

It is common practice to define and manage data separately from code, so why not business rules?

Object orientation:

Objects should encapsulate data and behaviour

This doesn’t prevent us from managing the data and rules separately from the code

4.2 Main Drivers for using Business Rules

The real business experts in many businesses are the IT staff – they have had to deal with all the real boundary cases! Business managers typically have a clear notion of policy, but not the details of practical rules.

By bringing the rules together, they can be verified for compliance with regulations, company policy / strategy etc.

Centralise: always know where the rules are

Standardise: always use the same rules from the same source

o California Highways Department found that branch offices applied the rules differently to calculate cost of vehicle licences

Control execution: return control over business decisions to the business

o Give business users an interface to modify rules and test the results – in many cases it is just the parameter values that have to be changed, so why involve expensive IT staff?

Control update: allow for timely changes to IT systems

o Provide a configuration management / release management environment to migrate changes into production systems

Allow more complex processes to be automated: allow planning, scheduling, best-choice decisions to be made

Rules languages include “natural language” recognition. These do not obviate the IT disciplines of verification, validation, testing, configuration management etc.

One customer actually used a rules system to generate the test cases for each release of a system. Another customer complained that the rules engine was giving incorrect results – but on closer investigation, it turned out that their test suite had 10% errors in it.

Ontologies are beginning to gain significance in business as a way of controlling the quality of rules. Rules are expressed in some vocabulary and it is therefore clearly important to start from a stable underlying model of data (or the world).

The AI aspects of rules, which are the domain from which rules engines sprang, are a very small proportion of the application of rules today, but nevertheless quite important, as these tend to be high-value. This is referred to by the “complex processes” bullet. A cable operator had formalised the constraints around contracts with advertisers (e.g. spots in three league games per week) to optimise the broadcast schedules. Some heavyweight rules experts were needed to boil these down into about 100 production rules that save weeks of work every time they are run.

5 Rules Engines vs. Rules Management

5.1 Rule-based programming tools

Rule engines are specialised components for executing declarative rules.

1970s: expert system shells – typically goal-driven

AI languages: LISP, PROLOG

1980s: AI/KBS development tools – e.g. ART, KEE

1990s: OO rule engines – e.g. Nexpert Object

2000s: Semantic Web and Ontologies

Component-based rule engines, e.g. Blaze Advisor, JESS, ILOG JRules, Aion…

In the research arena, large projects like RuleML are still going on.

5.2 How are Rule Engines evolving?

Types:

Declarative (more expressive) vs. Sequential (higher performance)

Forward and backward chaining; event-driven reasoning

Multiple rule-types used together

Platforms:

Java vs. .NET vs C/C++/COBOL…

Embedded device PC Web Services Mainframe

Rule and policy Abstractions:

Decision tables

Decision trees

Score cards / score models

Examples include the generic decision component that Cisco has started to add to its routers and switches – these can be used to enforce service level agreements, firewall functionality etc.

One customer has implemented a rules engine on a combine harvester. The Stealth Bomber has a sextant to help navigate even in the absence of GPS signals – there’s a rules engine to optimise its maintenance.

Forward chaining, which is simply cause-and-effect, typically has higher performance than backward chaining, which is looking to satisfy a goal. In the real world, even for open-source rules engines, performance is no longer a big issue (unlike five years ago). The Blaze rules engine (available for .NET and Java – it can even generate COBOL) is embedded in Fair Isaac’s financial services applications – e.g. 75% of European credit institutions use it to detect possible fraud. The data orchestration is the main bottleneck to performance, particularly in these days when it tends to get expressed in XML.

There is a “Miss Manners” benchmark and a WALTS (sp?) benchmark if you’re really interested. The general advice is to benchmark your rules engine on your rules, ignoring standard benchmarks.

Further trends:

High scalability and performance

Rule expressiveness for business users

Multiple data interface capability

o 3GL (Java bean) support

o Database / SQL support

o XML support

o Messaging / middleware support (CORBA, J2EE)

Standards support

o OMG Business Rules Working Group since 2002 (now Business Enterprise Integration Task Force)

Semantics for Busines Vocabulary and Rules for formal business statement expression

Production Rule Representation (mid 2006) for real-time interchange across software models (if… then…) – this allows rules to be stored as part of SLAs, contracts etc.

o W3C Rule Interchange Format working group since late 2005

o RuleML standards body often associated with W3C

Unfortunately based on PROLOG ideas, which express both data and rules in clauses

o JSR-194 Rule Engine Invocation standard

Likely to be extended with PRR to represent rules in Java applications

6 Rules Management and IT

Rule engines only provide an alternative mechanism for implementation of behavioral rules in software.

The main benefit of using a rules engine is the associated rule management process.

Represent rules in natural language

Rule reporting, verification, validation

Rule metadata, versioning, organisation by business function

This is where most of the vendors are expending their research dollars.

6.1 How does it all fit into applications?

Rule management software provides:

Rule authoring

Rule repository

Rule execution service

It has a Business interface for rule engineering and management, and a Service interface for applications to use. The Rule Store incorporates persistence, versioning and security.

This is more of an opportunity for IT staff than a threat. At egg, for example, the business analysts have a rule engineering environment that allows them to create and test rules and then deploy them when the tests have passed. The rule engine has not been touched or upgraded in three years, even though the business logic changes on a cycle of just weeks. The customer-facing web servers have fallen over a few times, so has the application server, but the rule server has just kept going.

6.2 Software Best Practices vs. Rule Management

Software best practices are defined by RUP as:

Develop iteratively

Continuously verify quality

Control change

Manage requirements

Use component-based architectures

Visually model software

How does rule management fit in? Each of the technologies discussed in this lecture series ties into that list.

Iterative: declarative

Continuous verification: independence

Control changes: declarative

Manage requirements: the business rules virtually are the requirements

Component-based: rule engine

Visually model: rule engines don’t really help, but visualisation tools are usually provided by vendors.

7 Rules Management vs. Process Management

From a vendor perspective, this is one of these perennial questions. What are the differences?

Processes are higher level than rules.

Rules can be used to implement processes

Rules are exposed as services, while processes consume services

See also the Business Motivation Model at http://www.businessrulesgroup.org/brgactv.htm#wp2

There’s probably a whole management science behind this model: in how many organisations are strategic goals actually written down and communicated in a way that lets policy makers and rule builders implement them effectively?

The Zachman framework also helps (as a reference) to understand the answer to these questions.

BPM is very poorly defined – can be used to stand for different acronyms and even then different vendors / practitioners define them differently!

Business process modelling (and simulation)

Business process orchestration and flows

Business process automation and workflow (manual)

Business performance monitoring

Focus on process definition and execution aspects

Much the same can be said about BRM. It’s much less common to find BRM solutions that don’t execute the rules (though they can be found). The BPM solutions all have to cope with both automated and manual processes, so non-execution solutions are more common.

Process flows can be simplified by abstracting out the decision logic into rule sets.

Conversely, business rules can invoke business processes as services, either to return a result needed to take a decision or because the rules say that some process has to be run if certain conditions exist.

7.1 Summary

Business rules, rule engines and rules management:

Provide a good fit with SOA and BPM

Good fit with IT

Plenty of tool support – open source to full house

Increasing interest from the Big 3 – IBM, Microsoft, Oracle

7.2 References

See the presentation slides on the BCS SPA web site – www.bcs-spa.org

brcommunity.com deals mainly with text-rules, non-automated

Ron Ross and Barbara van Harle (sp?) are the leading authors

Eurobizrules conference in London in June 2006

A BCS specialist group may be established specifically for business rules. Please drop Paul a line if this interests you.

[Ends]