Introductory Lecture – SPA 2006 Spring Lecture Series
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
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
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
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
• Rules (business logic)
• 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 Process Logic
o OS / Platform
• Rules / Declarative layer
o OS / Platform
• Data layer
o Database / Persistence
o OS / Platform
Processes and rules can invoke services at any level in this three-tier
Fair Isaac’s toolset allows definitions of components to be shared
between applications / components, which increases reuse even more.
• 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?
• 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
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
• Control execution: return control over business decisions to the
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
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,
In the research arena, large projects like RuleML are still going on.
5.2 How are Rule Engines evolving?
• Declarative (more expressive) vs. Sequential (higher
• Forward and backward chaining; event-driven reasoning
• Multiple rule-types used together
• 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.
• 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,
o W3C Rule Interchange Format working group since late
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
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
• 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
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.
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
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
• 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
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.
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
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.