Business Rules Engine Developing Expert Rules Systems for Service Oriented Channel Agnostic Solution

1
Business Rules EngineDeveloping Expert Rules
Systemsfor Service Oriented Channel Agnostic
Solutions

• Stephen Drover
• 26-02-2008

2
Contents

• Background on rules _at_ NAB
• Expert systems
• Implementation pattern
• Channels
• The rules engine serviceTechnical architecture
• Logical architecture

3
Rules _at_ NABA bit of background

• iLog JRules 5.4 ? JRules 6.7
• In production for 12 months
• 2 large 10 small projects
• 6 shared enterprise services
• Several thousand users
• 100 txn/sec online capability
• 5 developers
• Minimal customisation

4
Expert SystemsFrom people to programs
5
Expert SystemsA brief overview

• Why are they important?
• Consistent
• Scalable
• Encourages clarification
• Where are they most useful?
• High complexity, narrow focus, decision making
• E.g. Financial decisions

6
Rules Engines and Expert SystemsInference!

• Knowledge systems can be referred to as
  inference engines.
• Programs that derive answers from a knowledge
  base.

• Business rules engine products ARE inference
  engines!
• The very nature of how they process if/then
  statements is optimised for inference decision
  making.

7
The PatternRules engines in an SOA knowledge
system

• Not that different from a standard J2EE pattern.
• Stupid front end application server.
• Application DB for storing user session data.
• Service DB for storing application reference
  data.
• Business rules engine for storing inference logic.

8
The Channel Agnostic BitValue add!

• Every facet of the application is part of the
  service.
• The application server is purely presentation.
• Different application servers can generate
  different presentation layers.
• Multiple channels can use the same services!

9
The Business Rules ServiceThe physical
architecture

• Why are they important?
• A business service, not a technical service
• True separations of messaging and execution
• Load balancing and disaster recovery through JMS
  provider clustering

10
The Business Rules ServiceThe logical
architecture

• A rule service answers a SINGLE business
  question.
• Is this allowed?
• Validation
• Whats next?
• Decision points
• Is something wrong?
• Exception detection
• Can you give me complex advice?!
• Generating reference data
• They all work the same way

11
The Business Rules ServiceNOT a process flow!
A cloud of potential logic
12
The Business Rules ServiceNOT a process flow!
A cloud of potential logic

• Both traditional procedural programming and rules
  programming work as collections of if/then
  statements.
• However a business rules service should not
  dictate the procedural execution of if then
  statements.
• Rather it should be the execution of every logic
  statement in any order where the pre-requisite
  objects and attributes are available.
• This provides incredible flexibility for a single
  service to be able to approach a decision making
  process from almost infinite angles, with the
  lowest number of interations.

13
The Business Rules ServiceAn example any
combination of events is possible!U User
through a front end channel, B Business rules
engine

• U What are the fees?
• B Fees for what?
• U For a product.
• B Which one of these (list)?
• U Er, this one!
• B Ahh, a home loan! How much?
• U 1,000,000
• B Thats a lot! Whats their rating?
• U I dont know.
• B Well are they a customer here?
• U Yep!
• B And what is their id?
• U 123456789
• B Ahh yes, Bill Gates! Hes a good customer, so
  waive the fees. 0
• U Thanks!

• U What are the fees?
• B Fees for what?
• U What do you mean?
• B Well I know about fees on these things (list).
  
• U Ahh! A statement reorder please.
• B Those are 2.50 each.
• U The customers not happy, can I change that to
  1.00?
• B No, thats outside your authority. But you can
  make it 1.50
• U Thanks!

14
The Business Rules ServiceDesign considerations

• Does my object model capture all possible
  relevant objects and attributes? (Where not
  determined by architecture)
• Ignore mandated interfaces, where they do not
  map nicely to the business requirements. Push
  this to the middleware layer.
• What is my default position?
• What are ALL the possible answers to a question?
• Are any rules mutually exclusive?
• Infinite loops!
• What weight do each of my questions have?
• What weight do each of my outcomes have?
• Have you really thought hard enough, about the
  object model?

15
The Business Rules ServiceWorking with business

• Spend time understanding the core requirements,
  before starting design, as your role is 75
  analysis.
• Try to avoid allocating burned analysts to
  rules projects.
• Encourage exploration of a larger object model
  than first considered.
• Explore all possible values of each object
  attribute, there will be gaps in the business
  policy, guaranteed.
• Convey requirements will not be obfuscated as
  some obscure programming language, and encourage
  ownership.
• Establish requirements documents as two-way
  living artefacts.

16
In Summary

• Rules engines are inference engines are expert
  systems!
• SOA solutions allow true channel
  flexibilityTechnical architecture
• Inference solutions allow true business policy
  flexibility
• Logical architecture
• Questions?