Dorothy Russel, 416 4616606

1
An architectural introduction to Business Rules
IRMAC - Feb 19, 2003

• Dorothy Russel, [phone]
• dorothy_at_interlog.com
• v1.1
• February 2003

2
Abstract

• An architectural introduction to Business Rules
• If business entities are the things a business
  enterprise needs to know about, business rules
  define and control how the enterprise operates.
  Understanding both is necessary to build
  successful computer systems.
• The Business Rules Approach is a maturing
  discipline for business analysis. Tightly linked
  to data analysis and modelling, it provides a
  mechanism to discover and document the other part
  of the picture thats not data the process or
  activity side. It also provides a way to capture
  all the business rules you discover when doing
  data analysis, but lose because theres no place
  to put them.
• This presentation will outline the state of the
  art and discuss a top-down approach for analysing
  business rules thats based on Enterprise
  Architecture, the Zachman Framework and the
  disciplines of data modelling.

3
Why focus on business rules?

• . . . specific integrity rules of an
  enterprise, even though shared and universal .
  . . (just like its data should be), traditionally
  have not been captured in the context of its
  data model(s). Instead, they usually have been
  stated vaguely (if at all) in largely
  uncoordinated analytical and design documents,
  and then buried deep in the logic of application
  programs. Since application programs are
  notoriously unreliable in the consistent and
  correct application of such rules, this has been
  the source of considerable frustration and
  errors. It sometimes also has led, unjustly, to
  distrust of the data model itself.
• Ron Ross, Entity Modeling Techniques and
  Applications, pg. 102, 1987

4
Why are we here?

• The Problem
• organizations get complicated as they evolve
  simply automating the complexity results in
  complex, restrictive and inflexible systems
• The Solution
• top-down analysis of business requirements that
  rethinks whats truly required
• Essential about the essence
• Enterprise the whole business
• This Session
• an overview of proven analytical techniques from
  the perspective of business rules
• where are the rules?
• pitfalls
• lessons from the field

5
What do we want of our computer systems?

• Useful
• aligned with the business does what the business
  needs it to do
• effective does the right things
• (info in) system matches reality
• Stable
• immune from changes
• Robust
• functions well, reliable, doesnt break down
• performs as expected
• Integrated
• one concept defined only one time
• share data and meaning throughout the enterprise
• shareable, interchangeable parts reusable
  components
• Streamlined
• efficient, smooth flow, no awkward handoffs -
  doing things right
• Flexible
• able to accommodate changes in the business,
  quickly, easily

6
How do we get computer systems to be like this?

• Usefulness / Effectiveness
• define requirements from business fundamentals
• change data as reality changes - ie real-time,
  capture at source
• Stability
• base the system on the essence of the enterprise
  independent of organization and technology
  constraints
• separate things which change frequently from
  things which dont (eg. data from process from
  rules from interfaces from reports)
• Robustness
• thorough requirements, internal consistency,
  completeness, simplify
• Integration
• structure around data
• Efficiency (streamlined)
• logical chunking
• minimise redundancy
• Flexibility
• abstraction, generalisation each thing
  implemented in only one place minimal
• decouple independent variables

7
What does this mean for how we work?

• top-down analysis gives understanding of the
  business based on its mission
• mission-based systems are more likely to support
  the business in the future
• essential analysis focuses on the fundamentals
• fundamentals are less likely to change over time
  than implementations, designs and organization
  structure
• But things WILL change, so . . .
• analysing dimensions separately gives
  understanding of each thing in its own right
• independent components can be changed more easily
• And about rules . . .
• business rules appear in each dimension of
  analysis (Zachman column) (and also in the
  cracks)
• there are rules in data model, process model, and
  workflow model

8
Context of remaining discussion

• I am at Row 2 - business requirements / business
  definition level
• not talking about
• data structures or designs
• computer system constraints
• data transformation rules
• software
• process flows
• the essence of the business - what it needs to do
  to achieve its goals
• independent of technology
• independent of organization, even
• independent of currently implemented business
  rules
• architecture based
• considering the whole business system
• distinct, independent engineered components

9
Business Rules in the Business Concept (data)
Model
what should happen to a car thats never rented?
a rental is for exactly one customer

• we care about cars that are rented by customers
  (not other cars) and
• we care about customers (people) who rent cars
  (not other people)

customers are important to the enterprise
a given car may be used for no rentals or for
many rentals
cars are important to the enterprise
cu-rents-ca
EZ-Rent only rents Ford and GM cars
the characteristics of cars that are important
no car has more than 5 doors
a customer must have at least one rental could
have many
must be one of the states EZ-Rent operates in
the characteristics of customers that are
important

• must be one of
• sedan
• coupe
• wagon
• minivan
• sport utility
• truck
• convertible

customer who rented must be known to EZ-Rent
car rented must belong to EZ-Rent
the characteristics of rental that are important
date/time in must be later than date/time out
10
Rules around business objects core concepts

• existence / identity of things
• define the meaning
• identify restrictions, eg. no more than 100
  courses may be offered at any one time
• properties / characteristics of things
• define the meaning
• legal values
• associations what one thing has to do with
  another
• name the relationship
• optional / mandatory
• one or many
• Principle
• each concept must be defined
• each concept occurs only once in the model

11
Pitfalls in the Business Concept Model confusing
artifacts and essence
a customer must have at least one account could
have many accounts
the essence
an account belongs to at least one
customer could belong to many customers
12
Lessons from the field - Business Concept Model

• if you find the wrong concepts, youll get the
  wrong rules
• ensure identity of things is clear and
  non-overlapping
• each characteristic has a single home
  (normalisation)
• watch for opportunities for Abstraction /
  generalisation
• look for similarities not exceptions
• develop patterns for re-use
• beware different forms, representations or
  channels that are essentially the same thing, eg.
• telephone order
• internet order
• order form
• identify the underlying concept, i.e. request
  for product
• context is important - not everything is relevant
• dont assume something is important just because
  you thought of it
• done assume its not important just because the
  person youre talking to thinks it isnt maybe
  its important to someone else

13
Business Rules in the Business Process Model

• Output rule an inspection will identify
• servicing needs (eg. fuel, cleaning, maintenance)
  
• and damage to be repaired

Input rule a car must be present to be inspected
Initiation rulea returned car must be inspected
before the customer departs
14
Business Rules in the Business Process Model -
physical transform
Output rule a cleaned car is in a state ready
for a customer
Input rule a car must be present to be cleaned
Initiation rulea car must be cleaned before it
is given to a customer

• a car must be washed before every new rental
• the ashtrays must be emptied after every rental
• a car must be vacuumed, including the trunk after
  every three rentals, or if very dirty

• Cleaning a car involves
• washing the exterior
• empting ash trays
• vacuuming interior
• vacuuming trunk

15
Business Rules in the Business Process Model -
computation rules
a car out for 8 hours is charged at the daily
rate
total charge usage charge fuel charge
damage charge
re-fuelling charge is 25 cost of fuel
usage charge days daily rate hours
hourly rate
16
Business Rules in the Business Process Model -
decision rules

• Initiation rule cant perform this activity
  until
• there is a request to fill
• there are cars available to assign

• only cars that are physically present may be
  assigned 1
• the specific model requested should be assigned
  if a car of that model is available
• the assigned car should be of the type requested
• the end date of the rental must be before any
  scheduled booking of the assigned car for
  maintenance or transfer
• 10 of cars of each type should be held back for
  walk-in customers and not assigned
• an upgrade of one level may be made if there are
  not sufficient cars of any type to meet demand
• customers in the loyalty program have priority
  for upgrades
• assign lowest mileage cars of each type first

1 rule samples based on car rental example
developed by Model Systems Ltd.
17
Rules arising from business activities

• activity definition
• define the purpose
• identify outputs
• determine required inputs
• activity initiation / control rules
• condition where activity should / must happen
• condition where activity must be prohibited
• physical transformation
• definition of physical changes and efforts
• computation
• how to calculate new data values
• decision rules
• guidelines, policies, etc. to guide choice among
  options, optimise performance, manage risk,
  ensure legal behaviour
• evaluate a particular situation
• range from stringent to loose
• Principle
• each activity must be defined
• each activity occurs only once in the model

18
Pitfalls in the Business Process Model
extraneous activities
customer identity
rental estimate
Accept Rental Requests
customer requirements type of car, date
required, planned duration of rental
rental confirmation / reservation
Customer
whats the output?
rental confirmation / reservation
what value does this activity add? whats its
purpose?
19
The Concept of Perfect Technology 2.

• A perfect processor that
• is adaptable, skilled at any activity
• has infinite capacity to carry out activities,
  never tires
• makes no mistakes
• never breaks down
• produces results instantly
• costs nothing
• consumes no energy, takes no space, generates no
  heat
• and a perfect container with
• infinite capacity
• zero cost
• accessible by any processor

It is my opinion that if you define the
primitives relative to the Enterprise, they
likely do not change appreciably as long as you
stay in the same business. John Zachman,
Business Rules Journal, February 2003
2. Essential Systems Analysis, McMenamin
Palmer. 1984
20
Finding the Essence

• the essence of a business system may be
  relatively small, and yet the size of the
  incarnation makes it hard to find and understand
• to find the essence ask what would be left of
  the system if it were implemented with perfect
  technology? The system that would exist no
  matter what particular technology is used to
  implement it is the systems essence.
• by imagining how a particular system would look
  if you could implement it using such a perfect
  technology, you can distinguish the essential
  features of that system

21
Business Delivery Life Cycle
22
EZ-Rent Essential Activities
Implicit in the Enterprise are all of the
primitive models . . . it is only a question of
whether you make them explicit or not
Zachman, Feb 2003
23
Lessons from the field - Business Process Model

• if you find the wrong activities, youll get the
  wrong rules
• be clear about the purpose of every activity
• physical transform
• computation (data transform)
• decision
• beware activities rules arising from imperfect
  technology, e.g.
• checking activities
• approval rules
• co-ordinating activities
• activities that move data around inside the
  enterprise
• If I had a perfect processor and a perfect
  container would I still need this?
• tramp inputs - come in a package with other
  inputs, but are not really required by the
  activity (just passes through the activity
  without contributing)
• often happens with data collection
• outputs with no known inputs (spontaneous
  creation)

24
Business Rules in the Cracks - interprocess
dependencies
customer identity
rental estimate
customer requirements type of car, date
required, planned duration of rental
rental confirmation / reservation
Customer
rental confirmation / reservation
car available to rent
fulfilled rental request
Enterprise Memory
available cars
assigned car
Acquire Cars to Rent
new car to rent

• cant perform this activity until
• there is a request to fill
• there are cars available to assign

25
Pitfalls of ignoring dependencies
26
Concept to Activity mapping highlights dependency
rules
Business Concepts
Business Activities
The activity Accept Returned Car is dependent on
the activity Accept Rental Requests
27
Business Rules in the State-Transition Diagram
States of a Rental Car
a car thats in for servicing may not be assigned
28
Lessons from the field - Interaction Analysis

• beware gaps, inconsistencies, redundancies
• concepts in the concept model with no activity to
  acquire them
• what activity are we missing that should produce
  this concept as an output? or
• what output is missing from a known activity?
• concepts in the concept model that are not used
  by any activity
• why are we collecting it?
• what activity is producing it? is this activity
  necessary?
• missing business concepts - an input to an
  activity with no related concept
• what business concept does the defined activity
  input pertain to?
• does the activity really require that input to
  create its output?
• ill-formed activity definitions
• activity purpose unclear
• no outputs defined
• inputs not identified, unclear or incomplete
• use dependency information to guide organization
  and system design

29
Business Rules in the Workflow Model Rent Cars
only the supervisor may assign cars
30
Rules arising from Workflow Designs

• activities assigned to processors (people and /
  or technologies)
• who can do what
• level of authority
• recommended or required sequence of steps -
  process sequence and control rules
• some are essential dependencies, some are
  artificial
• affected by technology, organization structure,
  skills, etc.
• highly changeable

31
Pitfalls in the Workflow Model fragmentation and
redundancy
Customer
Loyalty customers are handled by specialists in
the loyalty department
customer makes reservation
customer accepts estimate confirms request
Reservation Clerk
cost estimate
Loyalty Program
Supervisor
Enterprise Memory
customer identification CUSTOMER
customer requirements RENTAL
costed rental RENTAL
confirmed rental RENTAL
32
Lessons from the field - Workflow Model

• opportunities to simplify
• extraneous activities which are not part of the
  essence
• convoluted workflow thats not simple,
  straightforward and direct
• communication flows between activities
• interprocess administration - activities that
  monitor and co-ordinate activities among
  processors
• opportunities to streamline
• different parts of an essential activity carried
  out by different processors (fragmentation)
• many processors performing the same activity
  (redundancy)
• the same concept managed in more than one place
  in the enterprise
• fragments of unrelated essential activities
  assigned to the same processor (conglomeration)
• align partitions of work with the essence
• keep activities whole
• honour dependencies - group highly interdependent
  activities together
• workflow and task assignment are highly
  changeable
• build very flexible solutions to enforce workflow
  rules

33
Stability Hierarchy of Rules

• Essential Rules
• Existence rules identity of things we care about
• Properties descriptive characteristics or
  attributes of a thing, legal values,
• Associations what one thing has to do with
  another - aka relationships
• optionality / cardinality rules
• Transformations input - process - output
• inputs required outputs produced
• physical transforms data transforms
  (computations)
• activity initiation rules (permission /
  prohibition)
• Inter-process dependencies input depends on
  output
• Optimizing Rules
• Evaluations guide a decision, choice among
  options, determine subsequent action
• Processor assignments who can do what?
• Sequencing rules what happens first, what next?

34
Practical considerations for computer systems
design

• Create stability
• base design on the essence
• Share data for integration
• common definitions
• shareable data stores
• Partition systems on natural boundaries
• keep activities whole
• group dependent activities together
• Design in adaptability
• Segregate components by degree of stability for
  low impact changes
• Provide flexibility where rules change frequently

35
The Bottom Line

• Rules are easy to find
• If you get the wrong business concepts, youll
  get the wrong rules
• If you get the wrong activities, youll get the
  wrong rules
• Dont pave the cow paths simplify the business
  system before applying technology, including
  rules technologies
• Some rules are more changeable than others, build
  more flexibility where rules are most likely to
  change

Implicit in the operating Enterprise are all of
the primitive models . . . it is only a question
of whether you make them explicit or not. Making
them explicit enables you to remove the erroneous
assumptions (defects), reconcile dissonant
perceptions (entropy), or engineer improvements
(change). It is unlikely that you are going to
be able to remove defects, reduce entropy, or
change the Enterprise appreciably without somehow
or other building primitive models. Clearly,
writing more code is not going to fix the
problem. John Zachman,
Business Rules Journal, Feb. 2003
36
Whats happening in the field?

• Conferences
• Business Rules Forum 03 - 3-7 Nov, 2003,
  Nashville www.BusinessRulesForum.com
• DAMA International Symposium Wilshire Meta-Data
  Conference, Orlando, Florida, April 27 - May 1,
  2003
• European Business Rules Conference 03 - Zurich,
  June 10-12, 2003, eurobizrules.org
• Business Rules Community - BRCommunity.com
• online reference place for people interested in
  Business Rules
• includes online version of the old Database
  Newsletter with many of the same contributors
• Business Rules Group - businessrulesgroup.org
• think tank on Business Rules
• formerly GUIDE Business Rules Project
• severval white papers and proposed models - see
  References
• Object Management Group (OMG)
• working group on Business Rules (BRWG) working to
  establish standards for rule technologies
• have issued an RFI for interested parties to
  indicate what theyre working on

37
Business Rules Forum, Nov 2002

• Product Derby
• ESI (Expert Solutions International) - Logist
  -converts business language rules to working
  application
• Sapiens - eMerge Enterprise Server - business
  logic server rules-based development highly
  scalable
• FairIsaac - Blaze Advisor - a callable rules
  processing component, no user interface
• Computer Associates - some rules-y tools on top
  of traditional client-server environment
• Keynotes
• Terry Moriarty - Survey of the Landscape
• Ron Ross - Business Rules and the New Service
  Equations
• James Sinur, Gartner Group - where he sees
  business rules going

38
Business Rules Forum, Nov 2002, contd.

• Presentations in three tracks
• Experiences
• Techniques
• Architecture Technology
• practitioners panel
• BOFs (birds of a feather) small group discussions
• Vendor exhibits presentations
• Workshops Tutorials
• Ron Ross, Business Rules Solutions - basics
• Donald Chapin, Business Semantics Ltd. - the
  language of business rules
• Sridhar Iyengar, IBM - Object modelling meets
  business modelling rules
• John Zachman, The Enterprise View of Business
  Rules
• Chris Date - WHAT not HOW An Introduction to
  Business Rule Technology
• Terry Moriarty - Building a Business Rule Driven
  Enterprise
• Roger Burlton, Kathy Long - A Method for Aligning
  Stakeholders, Processes and Rules

39
Conference Takeaways

• repository required
• will need to rationalise, refine and normalise
  rules to ensure consistency
• technologies are emerging to verify the logical
  correctness of a set of rules
• interactive cross-functional workshops more
  effective than interviews
• need to reconcile different viewpoints
• all the best data modelling disciplines still
  apply
• use the appropriate type of model for the
  perspective (row) youre working at, ie. business
  concept models do not need to be in 5th normal
  form.
• the things the model describes are different in
  the different rows
• business concepts in row 2, vs
• logical data collections in row 3, vs
• relational tables in row 4, vs
• Oracle data structures in row 5

40
Products and Vendors

• Rule Engines / Rule Execution
• Computer Associates - some rules-y tools on top
  of traditional client-server environment
  -www.CA.com
• Data Kinetics - tableBASE - table driven
  approach to business rules - www.DKL.com
• ESI (Expert Solutions International) - Logist
  -converts business language rules to working
  application - www.ESI.co.il
• FairIsaac - Blaze Advisor - a callable rules
  processing component, no user interface -
  www.BlazeSoft.com
• The Haley Enterprise - knowledge automation -
  www.Haley.com
• ILOG - ILOG JRules - rules engine for Java -
  ilog.com
• Pegasystems - rules driven process automation
  technology - www.Pegasystems.com
• Sapiens - eMerge Enterprise Server - business
  logic server rules-based development highly
  scalable - www.Sapiens.com
• YASU Technologies - component based solutions
  QuickRules rules engine -www.Yasutech.com

41
Products and Vendors contd.

• Analysis, Design Rule management tools
• Corticon Technologies - corticon.com
• Corticon Studio - analyst friendly tool for
  ensuring integrity of rules
• Corticon Server - deploy rules as web services
• CSC - Visual Product Modeling System -
  www.CSC.com
• ILOG - ILOG Rules - repository rule management
  software - ilog.com
• Business Rule Solutions - BRsolutions.com
• RuleSpeak - guidelines for writing clear, concise
  rules
• RuleTrack automated tool for recording
  organizing business rules -
• Methodologies
• BRS - Proteus
• KPI - STEP Approach
• ORM - Object Role Modeling, Terry Halpin
• Sapiens - Rapid Architected Application
  Development (RAAD) methodology

42
Products and Vendors concl.

• Consulting and Education
• Business Rules Solutions, Ron Rosss company -
  BRSolutions.com
• Knowledge Partners Inc. Consulting, Barbara von
  Halle - kpiusa.com
• white papers, see web-site
• Inastrol, Information Management Consultants -
  Terry Moriarty -www.Inastrol.com
• DCI courses dciseminars.com -
• Capturing Business Rules Business Analysis and
  Requirements Workshop
• Analyzing and Managing Business Rules Business
  Rule Specification and Renewal Workshop

43
References

• Business Rule Concepts, Ron Ross, 1998 -
  easy-to-read, non-technical explanation of
  business rules
• Business Rules Applied, Barbara von Halle, 2002
• Defining Business Rules - What are they Really?,
  The Business Rules Group, 1995
• Essential Systems Analysis, Stephen McMenamin
  John Palmer, Prentice-Hall, 1984
• Information Modeling and Relational Databases,
  Terry Halpin, Morgan Kaufmann, 2001
• Organizing Business Rules The Standard Model for
  Business Rule Motivation, The Business Rules
  Group, Nov 2000
• Requirements Analysis, David C. Hay,
  Prentice-Hall, 2003
• Resource Life Cycle Analysis A Business Modeling
  Technique of IS Planning, Ron Ross, 1992 -
  introduces a practical approach to Enterprise
  Architecture
• The Business Rule Book Classifying, Defining and
  Modeling Rules, Ron Ross, second edition, 1997 -
  Rons early definitive thinking - a real slog
• The Business Rules Manifesto, The Business Rules
  Group, 2003, www.businessrulesgroup.org/manifesto.
  htm
• What Not How The Business Rules Approach to
  Application Development, C.J. (Chris) Date,
  Addison-Wesley, 2000

44
QUESTIONS?