Pg. 1© Dorothy Russel, 2003 Dorothy Russel, (416) 461-6606 [email protected] v1.1 February 2003...

Pg. 1© Dorothy Russel, 2003

Dorothy Russel, (416) [email protected]

v1.1

February 2003

An architectural introduction to Business RulesIRMAC - Feb 19, 2003


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 that’s 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 there’s no place to put them.

• This presentation will outline the state of the art and discuss a top-down approach for analysing business rules that’s based on Enterprise Architecture, the Zachman Framework and the disciplines of data modelling.


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


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 what’s

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


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, doesn’t 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


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 don’t (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


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


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


must be one of:

•sedan•coupe•wagon•minivan•sport utility•truck•convertible

Business Rules in the Business Concept (data) Model

cu-rents-caCUSTOMER CAR

must be one of the states EZ-Rent

operates in

EZ-Rent only rents Ford and

GM cars

no car has more than 5 doors

customers are important to the

enterprise

cars are important to the enterprise

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

the characteristics of cars that are important:

•car make•car model•car model yearmanufacturer•vehicle identification no. (VIN)•number of doors•colour•date purchased•licence number•licence state•miles driven•car style

the characteristics of customers that are important:

•customer name•customer address•customer since -•customer telephone number

rentalr-is for-cc-makes-r

a rental is for exactly one customer

a given car may be used for no rentals

or for many rentals

what should happen to a car that’s never rented?

a customer must have at least one rental;could have many

date/time in must be later than date/time out

car rented must belong to EZ-Rent

customer who rented must be known to EZ-Rent

•customer who rented•which car was rented•pick-up location•date out•time out•mileage out•return location•date in•time in•mileage inthe characteristics of rental

that are important:


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


•chequing account number•date chequing account opened•balance in chequing account •customer name•customer address•customer telephone number•customer since -•Social Insurance Number•date of birth

CHEQUINGACCOUNT

•savings account number•date savings account opened•balance in savings account•customer name•customer address•customer telephone number•customer since -•Social Insurance Number•date of birth

SAVINGSACCOUNT

•VISA account number•date VISA account opened•balance owing in VISA account•customer name•customer address•customer telephone number•customer since -•Social Insurance Number•date of birth

VISAACCOUNT

•mortgage number•date mortgage issued•balance owing on mortgage•customer name•customer address•customer telephone number•customer since -•Social Insurance Number•date of birth

MORTGAGE

•customer name•customer address•customer telephone number•customer since -•Social Insurance Number•date of birth

CUSTOMER

•account number•date account opened•balance in account•type of account

ACCOUNTc-has-a

a-belongs to-c

a customer must have at least one account;

could have many accounts

Pitfalls in the Business Concept Model: confusing artifacts and essence

an account belongs to at least one customer;

could belong to many customers

the essence


Lessons from the field - Business Concept Model

• if you find the wrong concepts, you’ll 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 formidentify the underlying concept, i.e.: request for product

• context is important - not everything is relevant– don’t assume something is important just because you thought of it– done assume it’s not important just because the person you’re talking to

thinks it isn’t; maybe it’s important to someone else


Business Rules in the Business Process Model

InspectReturned Car

returned car car to be serviced; service required

car to be repaired; repairs required

car available to rent

car condition description

Initiation rule:a returned car must be inspected

before the customer departs

Input rule: a car must be present

to be inspected

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


Business Rules in the Business Process Model - physical transform

Cleaning a car involves:

•washing the exterior•empting ash trays•vacuuming interior•vacuuming trunk

Clean Cardirty car clean car

empty ashtrays

dirt-free interior and trunk

full ashtrays

•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

Initiation rule:a car must be cleaned before it is given to a

customer

Input rule: a car must be present

to be cleaned

Output rule: a cleaned car is in a state ready for a customer


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

Determine Rental

Charges

mileage in / out usage charge

fuel charge

damage charge

day / hour in / out

car condition

total rental charge

usage charge = # days * daily rate +

# hours * hourly rate


Business Rules in the Business Process Model - decision rules

Initiation rule: can’t perform this activity until:•there is a request to fill•there are cars available to assign

Assign Cars to Requestsrental confirmation / reservation fulfilled rental request

assigned caravailable cars

•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.


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


Pitfalls in the Business Process Model: extraneous activities

Accept Rental Requests

customer identity rental estimate

rental confirmation / reservation

customer requirements:type of car, date required, planned duration of rental

Review Rental Reservations

Customer

Enterprise Memory


what’s the output?

what value doesthis activity add?

what’s its purpose?


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

2. Essential Systems Analysis, McMenamin & Palmer. 1984

“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


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 system’s 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


Business Delivery Life Cycle

Accept returned cars

Ready cars for rental

Assign cars to requests

Clean car

Re-fuel car

Put away car

File key

Replenish fluids

Inspect returned car

Record rental mileage in

Record rental fuel level in

Obtain key

Determine rental charges

Accept payment for rental

Provide rental car to customer

Check car condition

Record rental mileage out

Record rental fuel level out

Provide key

Accept rental requests

Identify customer

Determine customer requirements

Provide cost estimate

Confirm request/ reservation

Match available cars to requests by type

Upgrade assignment to balance availability


EZ-Rent Essential Activities

1 ESTABLISH ENTERPRISE DIRECTION

2 MARKET CAR RENTAL SERVICES

3 MAINTAIN INVENTORY OF RENTAL CARS

4 RENT CARS 5 MANAGE PHYSICAL RESOURCES

6 MANAGE HUMAN ASSETS

7 MANAGE FINANCIAL RESOURCES

8 MANAGE INFORMATION RESOURCES

9 MANAGE ENTERPRISE

1.1 Define business mission

3.1 Plan marketing

3.1 Plan rental car requirements

4.1 Accept rental requests

5.1 Plan physical resource requirements

6.1 Define personnel requirements

7.1 Plan financial resource

8.1 Plan information systems

9.1 Develop business practices

1.2 Define business objectives & strategy

3.2 Communicate with consumers and customers

3.2 Acquire cars to rent

4.2 Assign cars to requests

5.2 Acquire store premises & facilities

6.2 Provide people to the business

7.2 Acquire financing

8.2 Acquire / Develop information systems

9.2 Employ EZ-Rent resources

1.3 Establish business locations

3.3 Register loyalty members

3.3 Service rental cars

4.3 Provide rental car to customer

5.3 Maintain EZ-Rent facilities

6.3 Develop human resources

7.3 Conduct financial operations

8.3 Maintain information systems

9.3 Audit business processes

1.4 Define organizing structures

3.4 Provide loyalty rewards

3.4 Repair rental cars

4.4 Accept returned cars

5.4 Manage supplies

6.4 Evaluate individuals

7.4 Manage customer credit

8.4 Operate computer systems

9.4 Ensure legal conduct

1.5 Evaluate corporate performance

3.5 Evaluate loyalty program performance

3.5 Transport cars between locations

4.5 Ready cars for rental

5.5 Manage transportation resources

6.5 Compensate human resources

7.5 Retire debt 8.5 Provide management information

9.5 Evaluate overall business operations

3.6 Dispose of surplus cars

4.6 Evaluate rental performance

5.6 Evaluate physical resource effectiveness

6.6 Maintain worker relations

7.6 Execute financial responsibilities

8.6 Dispose of information system

3.7 Evaluate inventory perf'nce/ profitability

6.7 Evaluate human resources effectiveness

7.7 Evaluate financial resource effectiveness

8.7 Evaluate information system performance

“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


Lessons from the field - Business Process Model

• if you find the wrong activities, you’ll 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)


Business Rules in the Cracks - interprocess dependencies




customer requirements: type of car, date required, planned duration of rental

Assign Cars to Requests

Customer

Enterprise Memory


Inspect Returned Cars

car available to rent fulfilled rental request

assigned car

can’t perform this activity until:•there is a request to fill•there are cars available to assign

Acquire Cars to Rent new car to rent

available cars


Pitfalls of ignoring dependencies

Assign Cars to

Requests


fulfilled rental request

assigned caravailable cars

Rentals

Available Cars

Rentals

Available Cars

Inspect Returned

Cars

Available Cars

Accept Rental

Requests



customer requirements: type of car, date required, planned duration of rental

Customer

RentalsCustomers

Acquire Cars to Rent

Available Cars


Concept to Activity mapping highlights dependency rules

Car Rental Customer

Acquire Car to Rent

creates


creates creates

Assign Cars to Requests

updates updates

Provide Rental Car to Customer

updates updates reads

Accept Returned Car

updates updates reads

Business ConceptsBusines

s Activities

The activity Accept Returned Car is dependent on the activity Accept Rental Requests


Business Rules in the State-Transition Diagram

available

damaged

requiring service

on rental

in for servicin

g

a car that’s in for servicing may not be assigned

assigned

customer reservation for pick-up tomorrow

service bay available

customer cancels reservation

walk-in customer rents car

servicing complete

returned car due for / requires service

car returned with major damage

customer returns car

car sent for repairs

car is scrapped

car is sold

reservation customer picks up car

States of a Rental Car


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


Business Rules in the Workflow Model: Rent Cars

Customer

Customer Care

Supervisor

Service Dept.

Enterprise Memory

Accept returned cars

Ready cars for rental

Assign cars to requests

Provide rental car to customer

Accept rental requests

customer makes reservation

customer identificationCUSTOMER

customer requirementsRENTAL

available carsCAR

fulfilled rental requestRENTAL

assigned carCAR

customer picks up car

customer returns car

completedrentalRENTAL

available carCAR

car conditionCAR

car on rentalRENTAL

only the supervisor may

assign cars


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


Pitfalls in the Workflow Model: fragmentation and redundancy

Confirm reservation / request

Provide cost estimate

Identify loyalty customer


Identify customer

Customer

Reservation Clerk

Loyalty Program

Supervisor

Enterprise Memory

customer makes reservation

customer identificationCUSTOMER

customer requirementsRENTAL

cost estimate

customer accepts estimate & confirms request

costed rentalRENTAL

confirmed rentalRENTAL

Confirm reservation / request


Loyalty customers are handled by specialists in the loyalty

department


Lessons from the field - Workflow Model

• opportunities to simplify:– extraneous activities which are not part of the essence– convoluted workflow that’s 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


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?


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


The Bottom Line

• Rules are easy to find

• If you get the wrong business concepts, you’ll get the wrong rules

• If you get the wrong activities, you’ll get the wrong rules

• Don’t 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


What’s 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 they’re working on


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


Business Rules Forum, Nov 2002, cont’d.

• 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


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) you’re 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


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


Products and Vendors cont’d.

• 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


Products and Vendors concl.

• Consulting and Education– Business Rules Solutions, Ron Ross’s 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


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 - Ron’s 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


QUESTIONS?

Date post:	23-Dec-2015
Category:	Documents
Upload:	jeremy-harper
View:	221 times
Download:	0 times

Pg. 1© Dorothy Russel, 2003 Dorothy Russel, (416) 461-6606 [email protected] v1.1 February 2003...

Documents