Business Rule Revolution

21265 Stevens Creek Blvd.Suite 205

Cupertino, CA 95014

The Business Rule RevolutionRunning Business the Right Way

Editors:Barbara von Halle

Larry Goldberg

Guest Contribution:John Zachman

The Business Rule Revolution

Copyright © 2006 by Happy About®

All rights reserved. No part of this book shall be reproduced, stored in a retrieval system,or transmitted by any means electronic, mechanical, photocopying, recording, orotherwise without written permission from the publisher. No patent liability is assumedwith respect to the use of the information contained herein. Although every precautionhas been taken in the preparation of this book, the publisher and author(s) assume noresponsibility for errors or omissions. Neither is any liability assumed for damagesresulting from the use of the information contained herein. Portions of this book iscopyrighted as follows (Chapter 3 is to Zachman International, Chapter 12 is to iLog,Inc.).

eBook Version 1.0: October 2006ISBN 1-60005-014-XPlace of Publication: Silicon Valley, California, USA

Trademarks

All terms mentioned in this book that are known to be trademarks or service marks havebeen appropriately capitalized. Happy About® cannot attest to the accuracy of thisinformation. Use of a term in this book should not be regarded as affecting the validity ofany trademark or service mark.

Warning and Disclaimer

Every effort has been made to make this book as complete and as accurate as possible,but no warranty of fitness is implied. The information provided is on an “as is” basis. Theauthors and the publisher shall have neither liability nor responsibility to any person orentity with respect to any loss or damages arising from the information contained in thisbook.

Publisher

• Mitchell Levy, http://www.happyabout.info/

Executive Editors

• Barbara von Halle, http://www.kpiusa.com/• Larry Goldberg, http://www.kpiusa.com/

Copy Editor

• Jennifer Finger, http://www.keenreader.com/

Cover Designer

• Cate Calson, http://www.calsongraphics.com/

Layout Designer

• Val Swisher, President, Oak Hill Corporationhttp://www.oakhillcorporation.com/

http://www.happyabout.info/

http://www.kpiusa.com/

http://www.kpiusa.com/

http://www.keenreader.com/

http://www.calsongraphics.com/

http://www.oakhillcorporation.com/

A Message From Happy About®

Thank you for your purchase of this Happy About book. It is available online athttp://HappyAbout.info/business-rule-revolution.php or at other online and physicalbookstores.

• Please contact us for quantity discounts at [email protected] • If you want to be informed by e-mail of upcoming Happy About®

books, please e-mail [email protected]• If you want to contribute to upcoming Happy About® books,

please go to http://happyabout.info/contribute/

Happy About is interested in you if you are an author who would like to submit anon-fiction book proposal or a corporation that would like to have a book written for you.Please contact us by e-mail [email protected] or phone (1-408-257-3000).

Other Happy About books available include:

• Happy About Global Software Test Automation: http://www.happyabout.info/globalswtestautomation.php

• Happy About Joint Venturing: http://happyabout.info/jointventuring.php• Happy About LinkedIn for Recruiting: http://happyabout.info/linkedin4recruiting.php• Happy About Website Payments with PayPal http://happyabout.info/paypal.php• Happy About Outsourcing http://happyabout.info/outsourcing.php• Happy About Knowing What to Expect in 2006 http://happyabout.info/economy.php

Other soon-to-be-released Happy About books include:

• Happy About CEO Excellence: http://happyabout.info/ceo-excellence.php• Happy About Working After 60: http://happyabout.info/working-after-60.php• Happy About Open Source: http://happyabout.info/opensource.php

http://HappyAbout.info/business-rule-revolution.php

http://happyabout.info/contribute/

http://www.happyabout.info/globalswtestautomation.php

http://happyabout.info/jointventuring.php

http://happyabout.info/linkedin4recruiting.php

http://happyabout.info/paypal.php

http://happyabout.info/outsourcing.php

http://happyabout.info/economy.php

http://happyabout.info/ceo-excellence.php

http://happyabout.info/working-after-60.php

http://happyabout.info/opensource.php

Acknowledgments

No book is possible without the support of personal and professional comrades. Thisbook is no exception.

From a historical perspective, we wish to acknowledge those who defined and pursuedthe fields of knowledge engineering and artificial intelligence, paving the way tounderstanding intelligence, such as Patrick Winston. Also, from a historical perspective,this book owes acknowledgement to the pioneering vendors of business rule enginetechnology, some of which no longer exist while others are in found in these pages.

Of great significance to this book are the contributors, of course, who gave of their timeand experience, meeting various deadlines most graciously. Deserving of specialmention is John Zachman, who found time in his incredibly demanding schedule, toprovide us with a valuable chapter on Enterprise Architecture.

We also wish to thank those who financially sponsored the book, up front and unseen:ILOG, Inc., Fair Isaac Corporation, and InScope Solutions Inc.

We could not have brought this book from vision to reality without the patience andcreativity of Mitchell Levy and excellent work by Jennifer Finger, Cate Calson, andChristine Milbank.

Our greatest acknowledgement belongs to you, the readers. It is your interest and yourvision in the Business Rules Approach that gave birth to this book and will keep it going.

Dedication

This book is dedicated to our spouses, Mike and Jill, for their enduring patience.

c o n t e n t s

The Business Rule Revolution Page vii

Letter from Editor An Important Letter from the Editors: Is the Business Rule Revolution Real? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - xv

Authors Contributing Authors - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - xix

Introduction Introduction: Welcome to the Business Rule Revolution - - - - - - - - - - - xxiii

Part I The Compelling World of Business Rules

chapter 1 The Essential Business Rule Roadmap - - - - - - - - - - - - - - - - - - 3What is the Business Rule Revolution?- - - - - - - - - - - - - - - - - - - - - - - - - 3What Exactly Are Business Rules?- - - - - - - - - - - - - - - - - - - - - - - - - - - - 4What is the Business Rules Approach?- - - - - - - - - - - - - - - - - - - - - - - - - 5Putting the Business First - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6What is the Rule Maturity Model? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7What the Rule Maturity Model is Not- - - - - - - - - - - - - - - - - - - - - - - - - - - 8How the Rule Maturity Model is Used Today - - - - - - - - - - - - - - - - - - - - 10Today’s Leaders: RMM Levels 1, 2 - - - - - - - - - - - - - - - - - - - - - - - - - - 11Tomorrow’s Leaders: RMM Levels 3, 4, 5 - - - - - - - - - - - - - - - - - - - - - 13The Rule Maturity Model and the Changing Relationship between Business and IT - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 15What Happens Next-Technology Predictions in the Rule Maturity Model? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 15Summary and Future Vision - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 16

chapter 2 Business Rules Marketplace Today and Tomorrow: Based on a Maturity Survey - - - - - - - - - - - - - - - - - - - - - - - - - 17Roots of the Business Rules Approach - - - - - - - - - - - - - - - - - - - - - - - - 17Short-term Purpose of the Survey - - - - - - - - - - - - - - - - - - - - - - - - - - - 18Longer-term Purpose of the Survey - - - - - - - - - - - - - - - - - - - - - - - - - - 191. Industries - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 192. Point of Contact for the Survey- - - - - - - - - - - - - - - - - - - - - - - - - - - - 193. Business Rule Champion- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 204. Scope of Business Rules Approach - - - - - - - - - - - - - - - - - - - - - - - - 205. Major Motivations for the Business Rules Approach - - - - - - - - - - - - - 21

Page viii Contents

6. The Need for Good Planning - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -227. Is a BRMS Part of the Solution? - - - - - - - - - - - - - - - - - - - - - - - - - - -228. Is a BPM or Workflow Product Part of the Solution?- - - - - - - - - - - - - -239. Where Are Source Rules Stored? - - - - - - - - - - - - - - - - - - - - - - - - - -2310. Process for Discovering Rules - - - - - - - - - - - - - - - - - - - - - - - - - - - -2311. Current Sources of Rules - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -2412. Anticipated or Actual Classifications of Target Rules - - - - - - - - - - - -2413. Desired Software Functionality - - - - - - - - - - - - - - - - - - - - - - - - - - -2514. Common Current States of Rule Maturity - - - - - - - - - - - - - - - - - - - -2615. Common Target States of Rule Maturity - - - - - - - - - - - - - - - - - - - - -27Survey Summary - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -28Lessons in the Survey - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -29 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -30Next Steps for the Survey- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -30Reference to Another Survey - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -31

chapter 3 Enterprise Architecture: Managing Complexity and Change - - 33Introduction- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -33The Changing Enterprise Concept - - - - - - - - - - - - - - - - - - - - - - - - - - - -35Increased Complexity in the Information Age - - - - - - - - - - - - - - - - - - - -35The Zachman Framework for Enterprise Architecture - - - - - - - - - - - - - -37A Framework Metaphor - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -41The Zachman Framework and Business Rules - - - - - - - - - - - - - - - - - - -42Conclusion - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -43References - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -43

chapter 4 The Business Architecture of Business Rules Based Enterprises - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 45Introduction- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -45Business Rules in the Context of Business Enterprise Architecture - - - - -46A Brief Discussion of the KPI RMM and its Impact on Architecture - - - - -47An Architectural Approach to Business Rules - - - - - - - - - - - - - - - - - - - -48The Rule Authoring and Governance Environment - - - - - - - - - - - - - - - -49The Rule Design Environment- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -51The Rule Deployment Environment - - - - - - - - - - - - - - - - - - - - - - - - - - -51

The Business Rule Revolution Page ix

A Brief—But Important—Digression from Architecture - - - - - - - - - - - - - 51Returning to the Architectural Considerations in the Design Environment - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 53Deployment Environment - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 55A Special Problem: Business Rules versus Business Process Management - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 56Conclusion - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 58

Part II The Business Side of Business Rules

chapter 5 Business Engineering and the Role of Business Rules - - - - - - 61A Definition of Business Engineering - - - - - - - - - - - - - - - - - - - - - - - - - 61Three Ways to Represent Knowledge Behind Business Engineering - - - 62The Importance of Capturing Decisions in Business Engineering- - - - - - 63Business Decisioning - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 64Incorporating Business Level Specifications with Automation Specifications- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 65The Gap in Business Entities Today - - - - - - - - - - - - - - - - - - - - - - - - - - 66The Gap in Business Processes Today- - - - - - - - - - - - - - - - - - - - - - - - 67The Business Rule Revolution - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 69Back to Business Decisions- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 71Summary- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 73

chapter 6 A BPM-Driven Approach to Business Rules - - - - - - - - - - - - - - 75About OPERS - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 75Background - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 76Business Drivers for OPERS’s Business Rules - - - - - - - - - - - - - - - - - - 76Establishing a Business Rules Group and Related Tools - - - - - - - - - - - 77IT-Driven Approach versus Business and BPM-Driven Approach- - - - - - 78The Business-Driven Project - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 84Summary- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 87

chapter 7 Modeling the Business: Improving Process Models through Business Rules - - - - - - - - - - - - - - - - - - - - - - - - - - - - 89Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 89

Page x Contents

The Impact of Business Rules on the Process Model - - - - - - - - - - - - - -90The Impact of Business Rules on the Data Model - - - - - - - - - - - - - - - - -96Business Rules and Business System Requirements - - - - - - - - - - - - -100Business Rules and Testing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -102Summary - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -104

chapter 8 Better Rules Through Innovative Rule-Authoring Software - - 107Introduction- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -107Background - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -108Laying the Foundation: The Concepts and Complexity Behind the Rules - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -109The Learning Curve and Dealing With Rule Errors - - - - - - - - - - - - - - -111More and Better Software Solutions- - - - - - - - - - - - - - - - - - - - - - - - - -113The Rule Wizard - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -114Wizards Are Us - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -117Application Emulation- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -117Ongoing Efforts - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -118Timeline - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -119Conclusions and Summary - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -120

Part III The Technology Side of Business Rules

chapter 9 The Role of the Rule Architect in Organizing Thousands of Rules - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 127Introduction- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -127Introducing the Role of the Rule Architect- - - - - - - - - - - - - - - - - - - - - -127Architecture: General - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -128Architecture: Rule-Specific - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -129Relationship of the Rule Architect to Other Architects - - - - - - - - - - - - -130BPMS and BRMS - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -131How Best to Write a Rule - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -133How to Express Rules in Sets - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -134How to Organize Rule Sets- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -136Summary of the Chapter - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -138

The Business Rule Revolution Page xi

Suggested Topics to Explore Further - - - - - - - - - - - - - - - - - - - - - - - - 139References - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 139

chapter 10 Building a Business Rules Architecture that Will Stand the Test of Time - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 141The Climate of Today’s Global Market Requires a Business Rules Architecture - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 141Delivering Product Strategy Through Business Rules - - - - - - - - - - - - - 142What is Business Rules Architecture?- - - - - - - - - - - - - - - - - - - - - - - - 143Process, Rules, Objects and How They Work Together - - - - - - - - - - - 144How to Identify Rules vs. Non-rules - - - - - - - - - - - - - - - - - - - - - - - - - 144What is Considered a Business Rule? - - - - - - - - - - - - - - - - - - - - - - - 145What is Not Considered a Business Rule? - - - - - - - - - - - - - - - - - - - - 145Guidelines for the Business Rule Acquisition Phase - - - - - - - - - - - - - - 145Where and How to Find the Business Rules - - - - - - - - - - - - - - - - - - - 146Business Rule Analysis Guidelines- - - - - - - - - - - - - - - - - - - - - - - - - - 146Business Rule Implementation Guidelines- - - - - - - - - - - - - - - - - - - - - 147Guidelines for Defining an Enterprise Business Rules Architecture - - - 147Guiding Principles for Defining an Enterprise Business Rules Architecture - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 147Business Rules Design Guidelines - - - - - - - - - - - - - - - - - - - - - - - - - - 148Roles and Responsibilities of Individuals Involved in Business Rules Architecture - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 149The Business Rules Architect - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 149Business Rules Analyst- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 150Systems Integration Engineer - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 150The Controversy of Who Owns the Business Rules - - - - - - - - - - - - - - 151Summary- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 151

chapter 11 Positioning the Enterprise for Business Rules: People, Processes, and Organization - - - - - - - - - - - - - - - - - 153The Call for Business Rules- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 154The Starting Point for Business Rules in the Enterprise - - - - - - - - - - - 155People: The Collaborative Organization - - - - - - - - - - - - - - - - - - - - - - 156Process: Stewardship for the Tactical Organization - - - - - - - - - - - - - - 157Organization: Governance for the Strategic Organization - - - - - - - - - - 159

Page xii Contents

Summary - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -160

chapter 12 Achieving Rule Maturity for Competitive Advantage — A Case Study of Equifax - - - - - - - - - - - - - - - - - - - - - - - - - 163Introduction- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -163A Recent History of Business Rules at Equifax - - - - - - - - - - - - - - - - - -164Why did Equifax select ILOG JRules? - - - - - - - - - - - - - - - - - - - - - - - -167How is JRules helping Equifax? - - - - - - - - - - - - - - - - - - - - - - - - - - - -167How Have Customer Experiences Like Equifax’s Influenced ILOG to Enhance JRules? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -169Lessons Learned - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -170What do Equifax Customers Think? - - - - - - - - - - - - - - - - - - - - - - - - - -171Looking Ahead—InterConnect and JRules 6- - - - - - - - - - - - - - - - - - - -172Summary - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -175References - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -176

chapter 13 Implementing an Enterprise Policy Hub - - - - - - - - - - - - - - - - 177Beyond Productivity Gain to Enterprise Policy Hubs - - - - - - - - - - - - - -177The Blaze Advisor Business Rules Management System - - - - - - - - - - -178Key Strengths and Features of Blaze Advisor - - - - - - - - - - - - - - - - - - -180Blaze Advisor Customers - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -182Definition of an Enterprise Policy Hub - - - - - - - - - - - - - - - - - - - - - - - -184The Benefits of an Enterprise Policy Hub - - - - - - - - - - - - - - - - - - - - - -187Best Practices in Implementing an Enterprise Policy Hub- - - - - - - - - - -188Integrating an Enterprise Policy Hub with BPM, SOA, and BI - - - - - - - -191Summary - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -192References - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -192

chapter 14 Putting the Business Back in Business Rules - - - - - - - - - - - 193The Significance of RMM Level 2 - - - - - - - - - - - - - - - - - - - - - - - - - - -193The Greatest Challenge for RMM Level 2- - - - - - - - - - - - - - - - - - - - - -194Meeting the Challenge of RMM Level 2 - - - - - - - - - - - - - - - - - - - - - - -194Sample Best Practices and Standards Today - - - - - - - - - - - - - - - - - - -195Enterprise Architecture, the Zachman Framework, and Business Rules-196Separating Business Rules in a Process Chart - - - - - - - - - - - - - - - - - -197

The Business Rule Revolution Page xiii

Separating Business Rules in a Use Case - - - - - - - - - - - - - - - - - - - - 198The Rule-Rich Decision As a Critical Business Lever - - - - - - - - - - - - - 200Business vs. Technical Analysis of Business Rules - - - - - - - - - - - - - - 200Tracing Business Rules to Process Charts in the KPI STEP™ Workbench - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 201Tracing Business Rules to Use Cases in the KPI STEP™ Workbench - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 203Tracing Object Models to Business Rules in the KPI STEP™ Workbench - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 204Pulling It All Together and Delivering Rule Maturity Model Level 2 - - - - 205Beyond Rule Maturity Model Level 2 - - - - - - - - - - - - - - - - - - - - - - - - 206Summary and Lessons Learned from RMM Level 2 Software - - - - - - - 207Essential Lessons Learned - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 207

Part IV Wrap Up

chapter 15 The Time is Now: The Economic Imperative for the Business Rules Approach - - - - - - - - - - - - - - - - - - - - - - - - - 211

About KPI About Knowledge Partners, Inc. - - - - - - - - - - - - - - - - - - - - - - - - - - - - 217IBM® Rational Unified Process or RUP® Plug-in - - - - - - - - - - - - - - - - 217Business Rules Mining Methodology - - - - - - - - - - - - - - - - - - - - - - - - 217KPI Rule Maturity Model (KPI RMM™) - - - - - - - - - - - - - - - - - - - - - - - 218KPI STEP™ License Program - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 218

Your Book Create Thought Leadership for Your Company - - - - - - - - - - - - - - - - - 221

Page xiv Contents

The Business Rule Revolution Page xv

Letter from Editor

An Important Letter from the Editors: Is the Business Rule Revolution Real?

Barbara von Halle and Larry Goldberg

What Did WeLearn From This

Book?

Without a doubt, every contributor to this book is a hero in their own right. Eachhas a story to tell. Each has been responsible for business rule successes.Each has witnessed business rule mistakes. None are afraid to share bothgood and bad so that readers can grow from their experiences.

Together, common lessons emerge:

• Business rules are an under-valued asset at most organizations today.• Business rules may hold the key to organizational agility, consistency, and

organizational knowledge, if not organizational intelligence and integrity.• Business rules are related to, but separate from, process and information

(or data).• The “decision” emerges as the missing link in methodologies by which

business rules become visible and manageable.• The Business Rules Approach has many versions in practice, requires

new skills, and aims to bring IT and the business closer together.

But, Is ThereTruly a BusinessRule Revolution

Taking Place?

Commonality alone does not a revolution make. Rather, we see evidence of arevolution in a most unlikely place: the intriguing discrepancies and their impacton businesses.

The major discrepancy, surfacing across chapters in this book, is the answer tothe one key question: Who ought to be the operational managers and authorsof business rules as those rules are to operate in the business and in itssystems?

On one hand, the answer is a rule analyst who is an intermediary. Such a ruleanalyst translates business words from other business sources into a businessrule construct that can be acted upon by a human, but mostly by a system. Thisrule author has a business background and a level of technical background, butis not as technically-oriented as a programmer or object modeler.

On the other hand, the answer is a business policy maker who serves bothas the business source of business words and as translator, without theintervention of a rule analyst. This rule author is a business operations personwith a strong business background, such as an underwriter, legalrepresentative, or product manager.

Page xvi Letter from Editor

This distinction makes all the difference in the world regarding the ultimateimpact of the Business Rules Approach and technology on a business. It willdifferentiate market leaders from followers and losers. It will handle more easilyZachman’s escalating complexity and change (see Chapter 3).

The second answer requires business policy makers to see the power of theirenhanced role and have the willingness to accept responsibility for it. Thesecond answer also requires technical experts to encourage that desire,welcome that new business role, and deliver and support the technicalinfrastructure to make it happen.

This is precisely where the storm is brewing (see Chapter 15). There remainsconflict in this area in most places, although not in all places. This is preciselywhy we believe we are at the brink of a Business Rule Revolution, and why theRule Maturity Model (RMM) focuses on this line in the sand—the line betweenbusiness policy makers and business rule translators that is disappearing.

Planning an Organization’s Part in the Business Rule Revolution

Two of the RMM’s vectors originate from the business (i.e., business controland business value of business rules). The third vector of the RMM (i.e., thetechnical state of business rules) at any level enables the business control andbusiness value of the rules at that level.

While the RMM, by itself is not a report card, business competition will occurover RMM levels. That is, as one organization matures along the RMM, thatorganization raises the bar for its competition. Therefore, over time it willbecome more important to achieve higher levels of the RMM. This is morelikely to be successful when an organization passes through lower levels alongthe way. That is why, today, both answers to the one key question are correct– because organizations are taking the journey one step at a time. Someorganizations are further along in that journey. That is why, in the future, thesecond answer will be more correct.

One More Time: Isthe Business

Rule RevolutionReal?

According to the Encarta Dictionary (English, North America), there are fourdefinitions for revolution.

The first is “overthrow of government: overthrow of a ruler or political system.”In a business rule world, the word “ruler” couldn’t be more appropriate. In abusiness rule world, this definition implies a more direct, powerful, andbalanced political system, defined by rules, and driven more by businesspeople and goals than by technology experts and technology constraints.

The Business Rule Revolution Page xvii

The second definition of revolution is “major change: a dramatic change inideas and practices.” Notice that this definition is about new ideas andcorresponding practices. New practices around business rule managementare emerging and the enterprise perspective is becoming intriguing.

The third definition for revolution is “a circle around something: a completecircle made around something, such as the orbit made by a planet or satellitearound another body.” We are, in fact, circling back around the business rulesin the center. Before there were computers, business leaders set policies andrules, often based on trial-and-error until the rules seemed to work sufficiently.Along came information technology, and with all good intentions, we automatedthose policies and rules without their changing much. We buried them intechnology where many became lost and unknown. The Business RuleRevolution circles back, giving those policies and rules back to the rightfulparties so those parties can rule more effectively in today’s world, where thesepolicies and rules need to change often and on demand.

The final definition of revolution is a “period of major geological change: aperiod during which the Earth’s crust changes considerably and major featuressuch as mountain ranges may emerge.” This definition, perhaps, says it all.

Where Can WeFind It?

No matter how you look at it, the Business Rule Revolution is happening. If youlook closely, it is changing the crust of the business world as we know it. New,business-empowered products and features are emerging as organizationsembark on their business rule journey.

Look for them in the pages of this book!

Page xviii Letter from Editor

The Business Rule Revolution Page xix

A u t h o r s

Contributing AuthorsContributors of this edition of the Business Rule Revolution, in alphabeticalorder, are:

May Abraham is the founder of a management consulting firm, GlobalKnowledge Architects, focused on helping companies manage and implementtheir core business knowledge using a Business Rules Approach andstructured methodologies. May is a senior Knowledge manager and has morethan fifteen years of experience in the knowledge management areas includingbusiness rules, geographic information systems, business analytics anddecision support systems. In her former job at AIG as Director, knowledgemanagement, she guided many strategic business rules projects and hassuccessfully established enterprise wide methodologies and implementations.May has a Masters degree in Mathematics from Annamalai University, India.

Michael Beck is President of Organization Solutions Inc., and a businessexecutive and senior management consultant with over twenty-five years’experience in both consulting and line management in commercial andgovernment positions. His broad experience includes strategic planning,business reengineering; requirements development and management,business rules methodology, and management process development. Michaelhas applied his knowledge and experience to the modernization of taxadministration systems in both federal and state governments.

Larry Goldberg is Managing Partner of Knowledge Partners, Inc., specializingin business strategy and architecture. Larry has over thirty years of experiencein entrepreneurship on three continents—Africa, Europe and North America. Inthe last twenty three years his focus has been in creating rules-basedtechnologies and applications. He has sponsored and played a primaryarchitectural role in Business Rules Management Systems, and businessrules-based commercial software applications in healthcare, supply chain,property and casualty insurance, and taxation regulation. Prior to joiningKnowledge Partners, Inc. in 2005 as Managing Partner, he sold his company,PowerFlex Software, to Sapiens Americas, Inc., in 1999, becoming a SeniorVice President of Sapiens.

Barbara von Halle is the Founder and Managing Partner of KnowledgePartners Inc. As a recognized leader in today’s Business Rules Approach,Barbara led the development of the best-selling Business Rules methodologybook (Business Rules Applied, 2002: John Wiley & Sons), the KPI STEP™

licensed product of Business Rules Management methods and tools, the KPIRMM™, and a proven approach for excavating rules from code. As a BusinessRules pioneer, Barbara received the Outstanding Individual Achievement

Page xx Authors

Award from the International Data Management Association. She has earneda bachelor’s degree in mathematics and an master’s degree in computerscience with an electrical engineering focus.

Neal McWhorter is a Principal at Enterprise Agility. Neal helps organizationstransform their business goals into business solutions. He has worked withnumerous large organizations to help them realize their goals of achievinggreater business agility by helping them adopt a business engineeringapproach. The Enterprise Agility Business Engineering approach allows anorganization's business process and rules to bridge the business/IT divide andbecome the actual implementation on which the business operates.

Jordan Masanga is IT Quality Assurance Manager and Technology Officer ofOregon Public Employees Retirement System (OPERS). Jordan has directedOPERS in implementing QA best practices, IBM Rational Unified Process®(RUP®), business process management initiatives, and automated workflowfor over three years. He has over eighteen years’ experience in informationand high technology, specifically software development and systemsintegration. He was previously a Vice President and Director of Engineering,Quality and Process of ADC Telecommunications, where he managed adivision with five distributed international offices.

Art Moore is a Managing Partner of Clear Systems LLC. Art has over twentyyears of IT experience, from systems development to IT strategic planning andpractice management. He has focused extensively on assisting large projectsand organizations to establish and integrate business rule-related systemspecification and development methods, technology, and management toolsand processes in their total business systems development and managementcontext. Mr. Moore is a co-author of Barbara von Halle’s last book, BusinessRules Applied (2002: John Wiley & Sons).

Linda Nieporent is BRMS Product Manager at ILOG, Inc. Linda has over tenyears of IT experience, the last six focused on business rules, both from abusiness user perspective and an IT implementation perspective. Ms.Nieporent is a co-author of Barbara von Halle’s last book, Business RulesApplied (2002: John Wiley & Sons). As an active proponent of business rulespractices, she has written articles and presented on business rules-relatedtopics at user groups and industry conferences.

John Semmel is Designer and Developer of Rating and Quoting Applicationsat Aetna. John has spent more than twenty-eight years in IT, the last ten atAetna where he spent four years working with business rules. He also spent

Authors

The Business Rule Revolution Page xxi

several years at EDS on a team that developed a mainframe-based,rules-driven rating and underwriting application in the late 1980’s to early1990’s.

Brian Stucky is Vice President of Business Rule Solutions at InScopeSolutions, Inc. Brian has nearly two decades of experience designing andimplementing business rule systems and directs the company’s business rulepractice area. Prior to joining InScope Solutions, Brian served as theEnterprise Rule Steward at Freddie Mac where he set the business andtechnology strategy for business rule development across the corporation.Brian also co-founded two companies that specialized in the design andimplementation of intelligent systems.

James Taylor is Vice President of Enterprise Decision Management (EDM) atFair Isaac Corporation. James is widely recognized as a leading proponent ofthe Enterprise Decision Management approach that uses business rules andpredictive analytics to deliver excellence in operational decision making. Jameshas experience in all aspects of software development. He previously workedat a start-up, in PeopleSoft’s R&D group and at Ernst and Young. He writes andspeaks extensively on EDM and is often quoted and interviewed.

Gene Weng is Business Rule Lead in a major American financial servicecompany. Gene also worked as an IT architect for Perot Systems. He holdsa master's degree in mathematics from the University of Science andTechnology, Beijing, and a master's degree in computer science from theUniversity of Oregon.

Larry Ward is Quality Assurance Project Manager at Oregon PublicEmployees Retirement Systems. Larry has over forty years’ experience insystems analysis and design, industrial engineering, and QA, including overten years’ Business Rules Approach experience. He is working on a majorsystems conversion project that implements BPM at OPERS and uses theOPERS Business Rules Approach. Larry designed the process to apply aBusiness Rules Approach at OPERS and was the project coordinator for fiveyears; he managed IBM® Rational® RequisitePro® and ClearCase® databaserepositories, requirements, and content for over five years, and assisted indeveloping tools and processes to update the rule databases. He has earneda bachelor’s degree in business and management, a master’s degree inmanagement, and a Juris Doctor degree.

John A. Zachman is CEO of Zachman Institute for Framework Advancement,Chairman of the Board of Zachman Framework Associates, and operator ofZachman International. John is well-known as the originator of the “Frameworkfor Enterprise Architecture” which has received broad acceptance around the

Page xxii Authors

world as an integrative framework, or "periodic table," of descriptiverepresentations for Enterprises. He is also known for his early contributions toIBM’s Information Strategy methodology (Business Systems Planning) as wellas to their executive team planning techniques (Intensive Planning). Johnserves on the Executive Council for Information Management and Technologyof the United States General Accounting Office. He is a Fellow for the Collegeof Business Administration of the University of North Texas; he serves on theAdvisory Board for the Data Resource Management Program at the Universityof Washington and on the Advisory Board of the Data AdministrationManagement Association International (DAMA-I), from whom he won the 2002Lifetime Achievement Award. He was awarded the 2004 Oakland UniversityApplied Technology in Business (ATIB) Award for IS Excellence andInnovation. He is the author of the e-Book The Zachman Framework forEnterprise Architecture: A Primer on Enterprise Engineering andManufacturing.

The Business Rule Revolution Page xxiii

I n t r o d u c t i o n

Introduction: Welcome to the Business Rule Revolution

Barbara von Halle

Why This Book? Business rules are everywhere. The right ones bring success, represent thesmartest thinking, and make people such as customers feel good. The wrongrules bring trouble and uncertainty. You never know when the wrong rules maystrike. You probably don’t even know which ones they are.

Obviously, business rules are the very core of any business and determinewhether it succeeds and how well, or fails and how badly. And yet, the currentstate of business rule best practices in the marketplace is unknown, until thisbook. This book is part of a series destined to be the Voice of the BusinessRule Revolution, sharing and measuring its progress.

The Business Rule Revolution is the awakening of business leaders to theimportance of business integrity and governance through management ofindividual rules. Some organizations are making great investments in it. Somehave not begun. And most, are somewhere in the middle. But, there is nopublished book to serve as an anchor point—a book where real people sharereal experiences so that the Business Rule Revolution does its job.

Six important aspects of the book are:

1. It is for managers and decision-makers who make things happen in theirorganizations.

2. It addresses business rules to be leveraged for agility, compliance, andcorporate intelligence as a key mechanism for engineering the businessitself.

3. It is not meant to be read cover-to-cover. 4. Together, the sections provide a step-by-step management approach

that crosses business and information technology barriers.5. Real case studies are written by real people as practiced in

well-respected corporations, government agencies, consultancies, andsoftware vendors.

6. Leading technology is highlighted.

Who Is This BookFor?

This book is for anyone interested in starting, planning, learning about, orparticipating in the Business Rule Revolution. These are the people who seethe value and want to be part of it.

Page xxiv Introduction

How Is This BookUnique?

There is no book like this one in the business rule space. Its uniqueness is thatno one person wrote it. It is a true anthology of experiences, successes and ofdisappointments, but full of practical guidance, contributed by everyday people.

Goals of ThisBook

As the first book in the series, the goals of this book are to:

• Expose the practicality of the Business Rules Approach throughsuccesses in major organizations

• Bring business and information technology professionals together• Present the achievements from a Business Rules Approach for both

business and information technology

Who Wrote ThisBook?

Most of the people who wrote this book are not professional writers, teachersor speakers, although some of them present at Business Rules- and relatedconferences. They are not theorists, although some have formal education infields related to business rules, such as artificial intelligence, knowledgeengineering, and software engineering. Most of them don’t know each other.The one common characteristic they share is their generosity in disclosing theirbusiness rule lives to you.

While only a few chapters have been coordinated with other chapters, togetherthey tell a true and complete story. The story has a business side and atechnical side. These sides come together in these pages, to be shared bybusiness and technical people. Our hope is that it brings these people togetherto realize the same business goals through business rules.

How to Read ThisBook

The book has three sections.

For both business and technical audiences, Section 1 is an introduction tobusiness rule topics. As such, it summarizes the current and desired state ofpractitioners of the Business Rules Approach. It explains the Rule MaturityModel (KPI RMM™), where the marketplace is on that model today, and whereit wants to go. The Rule Maturity Model is a prevalent theme throughout manyof the chapters.

Section 1 also contains a pivotal chapter from John Zachman, clarifying theconcept of Enterprise Architecture which is the application of traditionalarchitecture principles to an enterprise, not merely technology. From here,Larry Goldberg’s chapter presents the role of business rules in anorganization’s Enterprise Architecture.

The Business Rule Revolution Page xxv

For the business audience, Section 2 focuses on understanding businessprocesses and insights into the business policy maker as rule author.Specifically, Neal McWhorter explains business engineering with businessrules, Art Moore and Michael Beck uncover the integration of business processmodeling and business rules, and Larry Ward and Jordan Masanga explainhow business process management (BPM) activities improve the business(with ties to business rules). A very special chapter from John Semmeldescribes home-grown software, by which non-technical rule authors conceive,author, analyze, and simulate rules.

For the more technical audience, Section 3 covers topics about rulearchitecture and technical rule support. Starting off, Gene Weng and MayAbraham each contribute a chapter on the role and importance of the rulearchitect and rule architecture when building complex rule systems. BrianStucky, representing a business rules service company called InScopeSolutions, provides insights into positioning an enterprise for business rules interms of people, processes, and organization. It is in Section 3 that softwarevendors present technology solutions to business rule opportunities. Twoleading business rule management system (BRMS) vendors are highlighted inthis section. James Taylor, representing Fair Isaac Corporation, describes theuse of business rule technology in delivering an enterprise policy hub. LindaNieporent, representing ILOG, presents a case study with Equifax as it evolvedin its use of ILOG’s BRMS. Both vendors and their products have been aroundand evolved for several decades. They have much experience to share andinteresting strategic visions for the Business Rule Revolution. Also in thissection is a description of the KPI STEP™ Workbench as a source rulerepository supporting organizations at Level 2 of the Rule Maturity Model.

The Open Door Hopefully, this book is the first in a long series. We welcome new contributorsand chapters. The journey begins today. Make this book, these authors, andthis series your business rule almanac.

Sincerely,

Barbara von HalleLarry Goldberg

Page xxvi Introduction

The Business Rule Revolution Page 1

Part IThe Compelling World of Business Rules

Appropriate for both business and technical audiences, this section is anintroduction to business rule topics. Its four chapters cover anexplanation of the KPI Rule Maturity Model™ (Chapter 1), the currentand target states of current practices based on a survey (Chapter 2),Enterprise architecture as a non-technical business-critical discipline(Chapter 3), and the role of business rules in such architecture (Chapter4).

In their own words, below are quotes selected by each author to providethe reader with insights into each chapter:

”The Business Rules Approach makes possible the opportunity tomanage the most important rules of the business, no matter what kindthey are or what kind of technology they best belong in, if any…..The KPIRule Maturity Model™ is a tested roadmap by which organizations setrealistic business rule expectations and design a practical roadmap forgetting there…. Through the RMM, the vision of the Business RulesApproach will be realized: To enable business leadership to takecontrol of the guiding levers of the enterprise, and enabletechnology to match the rate of business change.”

Chapter 1, Barbara von Halle

Page 2 Part I: The Compelling World of Business Rules

“The most common target state for [RMM survey] participants is RMMLevel 2. Higher levels of the RMM are achievable, but rare today.Achieving RMM Level 3 usually requires home-grown software.Therefore, more software advances are needed and expected forenabling rule management and authoring by the business's truebusiness rule stewards.”


“I don't think there is any question about whether an enterprise is goingto do enterprise architecture or not; that is, it will not be optional if anenterprise intends to be viable in the Information Age. The only questionis when they will start working on enterprise architecture, because therepotentially is a lot of work to do-and at the point in time the enterprise isgoing to need it, it is going to be too late to do it! Business rules maywell be a good place to start working on it.”

Chapter 3, John Zachman

“The architecture should reflect the need to place the business firmly incontrol of business rules, and the greater the maturity that the enterpriseneeds to achieve, the greater the role of the business in managing therules.”

Chapter 4, Larry Goldberg

c h a p t e r


1 The Essential Business Rule Roadmap

Barbara von Halle

What is the Business Rule Revolution?The Business Rule Revolution is happening everywhere, even if it seemsinvisible. In fact, the business rules that are unseen or unknown are preciselythe ones that can do the most damage. Invisible rules lurk behind a lack ofproper business rule management—creating a precarious business climate forthese times.

Consider the growing and painful awareness of questionable accountingpractices by some corporate executives in some major organizations. What isat play here? Business rules are at play—good or bad, known or unknown. Inthese cases, rules were broken or secret. Some were improper rules appliedto achieve improper objectives. Think of the Business Rule Revolution asappropriate parties knowing what the rules are, applying the rules in all the rightplaces, and the organization therefore taking full responsibility for its rules andits integrity.

In a nutshell, the Business Rule Revolution represents an emerging undeniableneed for the right people to know what a business’s rules are, to be able tochange those rules on demand according to changing objectives, to beaccountable for those rules, and to predict as closely as possible the impact ofrule changes on the business, its customers, its partners, its competition, andits regulators.

This means that the Business Rule Revolution reflects a pent-up need forbusiness people to play a more prominent role in safely stewarding thebusiness’s rules from their inception to execution, with probable automation.Otherwise, the business is driving in the dark, off-road without headlights—anenvironment where serious accidents can happen. An organization aiming to

Page 4 Chapter 1: The Essential Business Rule Roadmap

better manage its important business rules needs a goal, a roadmap, and aplan for action. This is where KPI’s Rule Maturity Model (KPI RMM™ or RMM)fits.

This chapter explains the KPI Rule Maturity Model as the essential roadmap bywhich organizations chart their course in the Business Rule Revolution. Thischapter covers:

• What exactly are business rules?• What is the Business Rules Approach?• Putting the business first• What is the Rule Maturity Model?• What the Rule Maturity Model is not• How the Rule Maturity Model is used today• Today’s leaders: RMM levels 1, 2• Tomorrow’s leaders: RMM levels 3, 4, 5• The Rule Maturity Model and the changing relationship between business

and IT• What happens next-technology predictions in the Rule Maturity Model• Summary and future vision

What Exactly Are Business Rules?Business Rules are the ultimate levers with which business management isable to guide and control the business. In fact, the business’s rules are themeans by which an organization implements competitive strategy, promotespolicy, and complies with legal obligations.

In reality, not every business rule is worth explicitly stating or even automating.Also, while business rule management systems (BRMS) are extremelyvaluable, not all business rules belong in one. A critical aspect of a successfulBusiness Rules Approach, therefore, is assessing the value of specificbusiness rules to the business, how often those rules need to change, howurgently the change is needed, and how much control the business peopleneed or want over those changes, from start to finish.

The following are examples of business rules or business policies as abusiness person might initially express them:

• A premium customer is every customer whose credit rating is A or B.


• If a premium customer requests a loan for greater than $500,000, allow adelay in the first payment date by 30 days.

• The formula for computing a student’s cumulative grade-point average isfound on page 6 of the student policy manual.

• A driver should proceed in a particular direction if the street is labeled“senso unico,” but can proceed in the opposite direction without penaltyunless the driver causes an accident.

• If a loan applicant’s outside credit rating is marginal and the applicant alsohas a credit card balance greater than $5,000, then it is highly likely thatthe applicant will default on a loan.

• An employee who has completed five years of full-time employment withthe company is entitled to four weeks of paid vacation.

• Stock options vest at a rate of one-third each year over three years.• A customer with outstanding payments due must pay in full prior to a new

order being shipped.• A preferred customer automatically receives free express shipping on all

orders.

These examples illustrate that there are different kinds of business rules.Some rules impose constraints (constraint rules), some provide suggestions(guideline rules), some make calculations (computation rules), some inferinterim conclusions (inferred knowledge rules), and some infer actions(action-enabler rules).

What is the Business Rules Approach?There have been generations of advances in business and softwareengineering techniques and technology; yet, the rules of most businessesremain lost, unknown, inconsistent, inadequate, or simply resistant to change.Such rules, if crucial to business operations, are a hidden liability. Unmanagedrules result in lost time-to-market, regulation violations, and customerdissatisfaction: a sub-optimal running of the business at best.

Today, the Business Rules Approach is best defined as a formal way ofmanaging and automating an organization’s business rules so that thebusiness behaves and evolves as its leaders intend. Organizations today applythe Business Rules Approach to rules carried out by humans during the courseof manual processes as well as those in automated systems. Therefore, theBusiness Rules Approach enables business leaders to confirm that the rightrules are guiding the business in all of the right places. This becomes possibleby identifying rule-rich business processes and understanding the importanceof the rules that are to guide specific aspects of those processes.


The Business Rules Approach includes tasks, roles, and a rule repository forbusiness people, rules engines for automation, and formal ways of expressingrules so that the business’s policies and supporting rules can be quantified,accessed, and changed as needed.

When the Business Rules Approach results in the automation of rules insystems, often a business rule management system (BRMS) is deployed.Applying the Business Rules Approach with a BRMS “builds better, changeablesystems faster than any previous approach.”1 Real-world experience provesnot only that business rule projects are completed faster, at less cost, and withless risk, but they continue to deliver substantial savings in time and moneybecause rule maintenance is significantly accelerated.

Putting the Business FirstWhile the Business Rules Approach has wide applicability, it always beginswith the business itself, specifically its goals. After all, business rules existedlong before there were computers. The Business Rules Approach recognizesthat business rules are first about business directions, and later aboutdatabases and engines. With this perspective in mind, the Business RulesApproach makes possible the opportunity to manage the most important rulesof the business, no matter what kind they are or what kind of technology theybest belong in, if any.

This means that the adoption of the Business Rules Approach starts byunderstanding business objectives and letting those objectives drive thebusiness rule management practices that are optimum for the organization orproject.

To be business-centric, the Business Rules Approach requires a source rulerepository. A source rule repository provides the following:

• Storage of rules for the business audience, in a central or coordinatedlocation

• Access to rules by anyone who needs to know them• Analysis of rule sets for redundancy, inconsistency, etc.• Involvement of all stakeholders in the rule change process• Traceability to where rules are executing in the business and its systems

1. von Halle, Barbara, Business Rules Applied (2002: John Wiley & Sons, New York)


• Traceability of business rules to relevant items, such as processes, usecases, decisions, business terms, data fields, stakeholders, motivations,data, and object models.

Critical to the Business Rules Approach is a newly defined business rule lifecycle. It starts with a business opportunity or challenge, moves through thearticulation of policies and rules with a business focus, and may culminate inautomated rules in systems. The newly defined business rule life cycle typicallyenables shorter change cycles and may shift more of the responsibility forstewarding rule changes from technical to business people.

The optimum business rule management practices will enable management ofunderlying business rules by appropriate business stewards, regardless ofwhat kinds of rules they turn out to be, what kind of rule authoring techniqueswill work best, and what kinds of technology options might be optimal. Theoptimum business rule management practices should therefore be designed tofit an organization’s or project’s goals and culture. This brings us to the role ofthe RMM.

What is the Rule Maturity Model?Essentially, the RMM is a simple and practical model by which an organizationaligns its business objectives with the optimum business rule managementpractices for achieving those objectives. It provides a straight-forwardroadmap, customizable for each organization or project.

Like other maturity models, the RMM has six levels, starting from 0 and leadingto 5. In a level 0 organization, people are unaware that business rules have avalue worth contemplating; at level 5, organizations are utilizing business rulesas proactive and predictive levers for change and compliance, as well as forgaining momentum over the competition, and predicting the future. Therefore,each RMM level represents an alignment between specific organizationalobjectives and corresponding business rule management practices, supportedby refined roles, techniques, and software requirements. Each level alsorepresents a major change in an organization’s culture and its ability to reachfor higher goals. Therefore, skipping levels is not recommended.

At a glance, each level of the RMM represents one major goal with respect tobusiness rule management, as depicted in Figure 1 and listed below:

• RMM Level 1 Knowledge of Rules• RMM Level 2 Agility of Rules• RMM Level 3 Consistency and Alignment of Rules


• RMM Level 4 Prediction of Rules• RMM Level 5 Stewardship of Rules.

Figure 1: The RMM at a Glance

What the Rule Maturity Model is NotThe RMM is not a report card. In fact, higher RMM levels are not necessarilybetter than lower ones. It would be incorrect to judge organizations or projectsseeking or achieving lower levels of the RMM as falling short in any way. Tothe contrary, applying the RMM successfully means achieving the RMM levelthat delivers desired business objectives through the managing of relatedbusiness rules.

Figure 2 depicts more details of the RMM2, along three vectors. The first vectoris the business value which addresses the influence over rule changesmaterialized by each RMM level. The second vector is the technical statewhich describes where rules reside and how they are managed at each level.

2. The original version of the RMM is at www.kpiusa.com/rmm.htm


The third vector is the business control which alludes to the role ofnon-technical rule stewards and how that role evolves at each level of theRMM.

Figure 2: The RMM in More Detail


How the Rule Maturity Model is Used TodayTo date, various organizations use the RMM for one or more of four mainpurposes:

• Assess their current state to understand where they are today withrespect to managing business rules. Most are at RMM Level 0.

• Define their target state to determine how far they should go in managingbusiness rules. Most are aiming for RMM Level 1 or 2, with a few aimingfor RMM Level 3.

• Certify achievement to publicize to internal and external audiences theirsuccesses as they achieve targeted RMM levels.

• Determine the business value of incorporating the Business RulesApproach to drive the adoption of the Business Rules Approach bytargeted business objectives and to determine the means and metrics ofmeasuring its outcome.

Organizations using the RMM to assess current and target states begin byidentifying business objectives to be achieved by managing business rules.This leads to answers to the following questions before determining the desiredtarget RMM Level:

• What objectives are achievable by better managing business rules?• What are the short-term and long-term timeframes for achieving those

objectives?• Which business rules are worth managing? • Who is to play which roles in managing business rules? Specifically, who

drives policies to new and changed rules for different parts of thebusiness?

• Is there a need for joint stewardship for some policies and rules?• How will political conflicts concerning rules be settled?• What technology is needed to support each of the roles?

Use of the RMM to certify achievement of specific RMM levels has uncovereda critical consideration. The RMM implies that all three vectors be managed atthe same level of maturity. That is, there is danger in achieving an RMM Level3 for the technical state (i.e., delivering enterprise-worthy rule authoringsoftware, etc.) but an RMM Level 2 for the business control vector (i.e., puttingthat technology into the wrong hands). Inconsistent maturity causesunexpected, possibly devastating havoc. An organization exhibiting disparateRMM levels in its business rule management may be dysfunctional, putting


anticipated benefits in jeopardy. In fact, most shortcomings of the BusinessRules Approach in practice can be attributed to inconsistent achievement ofRMM levels across these vectors.

Today’s Leaders: RMM Levels 1, 2It is important to understand the culture and capabilities of organizations ateach level of the RMM in more detail. Below, each level is introduced usingFigure 1, adding the detailed explanations for Figure 2.

Level 0: Unaware A Level 0 organization is unaware of business rules as being special. Therules remain hidden and unchartered. They are buried as details in processdescriptions, policy and procedures manuals, or in system designs where theyare vulnerable to becoming lost and unknown and resistant to change. As aresult, no one knows where to start looking, where to stop, or how long it maytake to find certain rules.

Even more importantly, business rules are not managed rigorously as strategiclevers for achieving objectives. People in an organization at RMM Level 0 carryout business transactions often without knowing what the rules are or wherethey are executing in business processes or automated systems. Theorganization survives with rule changes that are difficult, time-consuming, andcostly.

Level 1:Knowledge

A Level 1 organization wants to gain knowledge of some of its rules. Such anorganization separates the business rules from other kinds of business artifactsor requirement types. To achieve this separation, a Level 1 organizationcaptures the rules in a simple manner on a project-by-project basis, ofteninvolving only minimal investment in new software and organizational roles.Typically, rules are captured as free-form rule statements, stored in documents,spreadsheets, simple extensions to modeling or requirements tools, or arelational database that has room for rule-related metadata. Business peopleknow where to find the documented rules and are, therefore, able to find outwhere those rules are executing in the business processes and systems. Thisminimal traceability can lead to a shorter change cycle than is likely at Level 0,where the rules remain buried.

At Level 1, because rules are separated simply but without a lot of rigor, theytake on the characteristics of a new kind of non-rigorous business or systemrequirement. Therefore, as with other kinds of requirements, typically in Level1 organizations, business analysts interview business experts aboutobjectives, requirements, and source documents. The business analysts (with


some technical skills) write the rules but technical people are still needed toproduce automated rules. The business experts provide input and review theoutput, but do not play the direct role of creating the rule statements for thesource rule repository.

As such, a Level 1 organization does not apply much rigor in its Business RulesApproach. True agility is in its infancy at Level 1, which is why mostorganizations aim for Level 2.

Level 2: Agility A Level 2 organization aims for agility in its business rules; thus, it seeks morerigor in capturing and managing them. A Level 2 organization not onlyseparates the rules from other business and technical assets; it does so with awell-defined rule authoring process. This process starts with authoring rules orchanging rules, gaining business approval for them, analyzing them, testingthem, and putting them into production (if automated). Structured methods,parsed rule syntax or intelligent parsers, and manual analysis of rule groups(for correctness, completeness, etc.) are possible. A Level 2 organization orproject is well-positioned to take advantage of BRMS deployment becauserules are expressed in a more rigorous form, closer to that needed forautomation and for automated rule analysis (available through BRMS). Toachieve maximum agility, a Level 2 organization requires traceability fromchanging rules to other business and system artifacts. Thus, Level 2 requiresseparation and traceability of business rules to support business and technicalagility.

Organizations aiming for Level 2 store these rules in a more sophisticatedsource rule repository, used by business and technical people. The source rulerepository also captures standard terms and related reusable rule clauses,enabling more robust rule reporting and analysis. Rule related roles aredefined. Project-level rule stewardship exists. Typically, a BRMS is used forsome automated rules.

The transition to Level 2 involves adding the authoring, validating, andanalyzing of rules with an underlying semantic model. In some Level 2organizations, business analysts who are not so technically oriented mayauthor the business-friendly form of a rule, especially if the source rulerepository is one that is easy to use. Still, technically-oriented businessanalysts usually write the more formal form while technical people convertthese into an automated form. The responsibility for creating business rules isshared by business analysts and technical people.


Tomorrow’s Leaders: RMM Levels 3, 4, 5

Level 3:Consistency and

Alignment

An organization aiming for RMM Level 3 seeks consistency among its rulesand alignment of them to current and changing objectives. Therefore, anRMM Level 3 organization seeks business rule governance across projects,systems, and perhaps business unit boundaries.

Such an organization identifies business-driven benefits for standardizing orsharing business rule techniques and even automated business rule servicesacross projects. These organizations typically establish a Business RulesCenter of Excellence that endorses a standard business rules methodology.Sometimes multiple BRMSs are deployed, and common business rulestechniques, standards, and roles are shared across BRMSs, when appropriate.

The transition to RMM Level 3 is extremely significant as it meanscross-organizational rule governance as well as more sophisticated source rulerepository support. It implies organizational change and collaboration, andbrings with it some of the greatest business rule benefits.

Level 3 introduces automated rule analysis and simulation capabilities. Thismeans that the translation from the business-friendly form to an executableversion is either prompted by intelligent software or automatic in some manner.In this environment, business analysts or even business experts are able toauthor, change, and test rules without relying on technical people to bridge thegap. Usually, technical people put the resulting rules in production.

Level 4:Predictions

An organization at RMM Level 4 sees business rules as predictions for futuresuccess. Business people or analysts hypothesize about future events to whichthey wish to respond in a carefully pre-calculated manner. Business leaders oranalysts craft different rule sets, test, simulate and compare predictions, andhave these rule sets ready-and-waiting for deployment in anticipation of relatedthreats and opportunities. These people craft business rules to react to suchevents and predict the business impact of rule changes on the client base,revenue, profit, and staff levels.

Level 4 opens up a whole new world. A Level 4 organization supports a varietyof tools for capturing and analyzing rules and with metrics against whichdesired impact of rules on the business are managed. Business analysts orbusiness experts define their destination via metrics and then interactively craftthe rules by which they hope to arrive there. With tools and metrics at hand,business analysts or business experts can now proceed confidently from


understanding future business objectives to simulating rules within a futurecontext. Again, usually technical people put such rules into production, whenneeded.

Level 5:Stewardship

An organization aiming at RMM Level 5 embraces the full stewardship ofbusiness rules for refining and re-inventing itself as necessary. The differencebetween Level 4 and 5 is that Level 4 aims at immediate or short-term futures,whereas Level 5 looks to a variety of longer-term futures. It represents a worldof anticipation and planned reaction while hitting the ultimate goal of agility. ALevel 5 organization is not satisfied in just being fast, but plans on being first.A Level 5 organization defines various futures as the organizations wishesthem to play out before they happen!

The characteristics of each level of the RMM are summarized below.

Table 1: Culture and Capabilities for Each RMM Level

RMM Level Use of Rules

Primary Goal of RMM Level Comments

1 Re-orient or Re-discover (existing rules)

Knowledge of Rules • Rules in business language• Rules tied to process models or use cases• Rules traced to systems implementation • Rules stored in spreadsheets

2 Re-act (to change)

Agility of Rules • Rules in formal form possibly with rule authoring software• Glossary of terms tied to rules• Rules analyzable• Standard rule reports• Source rule repository with extensive traceability of rules to

rule metadata, process models, object models, etc• Rules in agile technology (BRMS)

3 Re-align (with objectives)

Consistency and Alignment of Rules

• Rule sets assigned to business metrics• Rule sets shared as services across processes and systems• Business Rules Center of Excellence established• Possibly more than one BRMS• Standard methodology, templates, etc

4 Re-envision(short-term futures)

Future Predictions with Rules

• Potential events identified• Potential rules simulated • Revenue, profit, people differences estimated• Rules recast according to analysis

5 Re-invent (longer-term future)

Full Stewardship with Rules

• Rule stewards identified• Fast, first to define and respond• Ever-changing organization


The Rule Maturity Model and the Changing Relationship between Business and ITEach higher level of the RMM, because there is more rigor in the methods andmore sophistication in the software, offers the opportunity to re-shape therelationship between business and technical people. To understand how thisrelationship can evolve, let’s first understand the basics of the business rule lifecycle, which can provide a much shorter change cycle.

The concept of a business rule life cycle is new and it applies to all RMM Levels,except Level 0. In fact, for RMM Levels 1 through 5, the business rule life cycleis much the same. It usually consists of the following tasks or activities:

1. Document business objectives or requirements initially or requiringchange.

2. Document business policies supporting the objective or requirement.3. Identify source materials for underlying rules.4. Discover and author rules in simple, business-friendly, natural language

form (with glossary).5. Author, validate, and analyze rules in rigorous, formal form with a

semantic model of the underlying glossary.6. Automate and test rules.7. Simulate rules within a context.8. Put rules into production.

A very significant difference among RMM Levels involves the role of businessversus technical people in the business rule life cycle. At higher RMM Levels,businesspeople are able to carry out more of the steps in the business rule lifecycle because there are methods, standards, and software that enable them todo so with minimal technical support.

What Happens Next-Technology Predictions in the Rule Maturity Model?The incremental methodology and technology requirements for each level ofthe RMM are becoming well-known and widely accepted. Practitioners use theRMM to prepare for future technology advancements. Software vendors usethe RMM to deliver on the promise of the Business Rules Approach.


Most recent advances include the interest in and addition of some businessrule management support for non-technical users to BRMS products. Anotherimportant trend is that of Enterprise Decision Management (EDM), which takesadvantage of BRMS technology and sometimes analytical models to improveoperational decisions. Per Cutter Consortium3, “EDM should be considered asa way to extend your organization's DW (data warehousing) and BI (businessintelligence) capabilities by automating decisions through the use of rule-basedsystems and analytic modeling techniques."

For more insights into current technology trends and visions, see Chapter 15.

Summary and Future VisionThe RMM is a tested roadmap by which organizations set realistic businessrule expectations and design a practical roadmap for getting there. The RMMkeeps an organization grounded in a step-by-step Business Rules Approachthat is customized to target business objectives. As such, the RMM is a guidefor matching desired or required business benefits to the appropriate amountof investment in managing business rules. The RMM assists in defining thefirst steps in getting started while keeping a longer-term vision in sight.

Through the RMM, the vision of the Business Rules Approach will be realized:

To enable business leadership to take control of the guiding levers ofthe enterprise, and enable technology to match the rate of businesschange.

References

1. von Halle, Barbara, Business Rules Applied (2002: John Wiley & Sons,New York)

2. Hall, Curt, “Enterprise Decision Management: Business IntelligenceAdvisory Service,” Executive Report volume 5, No. 6, Cutter Consortium

3. Hall, Curt, “Enterprise Decision Management: Business Intelligence Advisory Service,” Exec-utive Report volume 5, No. 6, Cutter Consortium

c h a p t e r


2 Business Rules Marketplace Today and Tomorrow: Based on a Maturity Survey

Barbara von Halle

Roots of the Business Rules ApproachThe Business Rule Revolution is certainly not new, but it is quickly gainingmomentum today. The Business Rule Revolution really has two parts:business rule technology revolution and business rule methodology revolution.Some aspects of the Business Rule technology revolution have existed formany decades, having beginnings in the technology of artificial intelligence andthe discipline of knowledge engineering. The Business Rule technologyrevolution continues to benefit from advances delivered in business ruleengines (today, often called business rule management systems or BRMS) thathave been around and evolved over several decades. It also continues todaywith a new growing population of business rule engines (BRMS) in theOpenSource marketplace (where specific business rule engines are publiclyavailable in part or in whole).

The recent Business Rule methodology revolution is also occurring today aspractitioners integrate newly defined business rule deliverables into traditionalrequirements approaches and modeling techniques. The methodologyrevolution is maturing to include emerging business rule standards andsoftware tools for capturing business rules in business terms for businessaudiences and preparing the rules for automation. In some cases, businessrule deliverables and corresponding tasks have been added to current familiarpractices. Some methodology plug-ins for IBM® Rational Unified Process® orRUP® include business rule aspects. Some organizations have created across-reference from business rule deliverables to models developed usingaspects of the Unified Modeling Language (UML).

Page 18 Chapter 2: Business Rules Marketplace Today and Tomorrow: Based on a Maturity Survey

Today, the methodology and technology roots of the Business Rule Revolutionare colliding and integrating, giving prominence to the word “revolution.” Giventhese various beginnings, where is the Business Rules Marketplace heading,and more importantly, what the current practices are in those areas? Thischapter summarizes a survey of willing corporate and governmentorganizations. It covers the following:

• Short-term purpose of the survey• Longer-term purpose of the survey• General background of participants• 1. Industries• 2. Point of contact for the survey• 3. Business rule champion• 4. Scope of Business Rules Approach• 5. Major motivations for the Business Rules Approach• 6. The need for good planning• 7. Is a BRMS part of the solution?• 8. Is a BPM or workflow product part of the solution?• 9. Where are source rules stored?• 10. Process for discovering rules• 11. Current sources of rules• 12. Anticipated or actual classifications of target rules• 13. Desired software functionality• 14. Common current states of rule maturity• 15. Common target states of rule maturity• Summary of the survey• Lessons in the survey• Reference to another survey

Short-term Purpose of the SurveyThe immediate purpose of the survey is to establish a baseline of the BusinessRules marketplace by documenting both the current and the future state ofbusiness rule practices based on an anonymous survey group. We alsowanted to correlate current and target states to the KPI RMM™ levels. Doingso provides insight into the maturity of the marketplace and, more importantly,where it wants and needs to go in the near future.


Longer-term Purpose of the SurveyThe longer-term goals of the survey are twofold. The first is to track theprogress of the survey group over time to determine the economic impact of theBusiness Rules Approach as these organizations mature, and to determine theeconomic impact of the Business Rules Approach at each RMM level.

The second longer-term goal of the survey is to create a collective set ofrequirements for business rule software that will support all desired levels of theRMM, in incremental fashion.

1. IndustriesSurvey participants represent organizations that have taken steps in adoptingthe Business Rules Approach. Obviously, some organizations are justbeginning their RMM journey. As such, these organizations are establishing asteering committee to investigate the benefits and applications. Others aremore mature, with existing methods, standards, and BRMS.

The participants were chosen from among practitioners and organizationsparticipating in Business Rules Conferences or attending Business RulesTraining. Based on KPI’s experience over the past 10 years, it is confident thatthis sample is representative of the most common characteristics occurring inthe Business Rule Revolution marketplace.

It is not surprising that the majority of participating organizations were in theinsurance industry, most being healthcare insurance providers. Mortgagecompanies and state governments were also prominent participants. Thisindicates that these types of businesses are undergoing rapid change, which isenabled by investment in the Business Rules Approach.

2. Point of Contact for the SurveyKPI’s point of contact for conducting the survey was almost always (over 90%)someone in the information technology (IT) department. This may be the resultof inviting participants from conferences, training classes, and practitioners. Itspoint of contact for three of those IT organizations was the head of a BusinessRules Center of Excellence. Participating organizations with artificialintelligence or knowledge engineering professionals and experience weremore likely to have Business Rules Centers of Excellence and a greatercomfort with managing technical rules. The other IT contacts were usually


within an IT architecture group or a major application development group. In afew cases, KPI’s point of contact was from the business side of theorganization.

Regardless, people participating in the survey consisted mostly of ITprofessionals, sometimes participating with business stakeholders or partners.

3. Business Rule ChampionA business rule champion is the person who initiates interest in the BusinessRules Approach, provides guidance for it, and usually supplies funding for it. In50% of the participating organizations, the business rule champion was adirector or vice president in the IT function. The other 50% was split between abusiness champion and a shared championship between a business and an ITleader.

4. Scope of Business Rules ApproachIt was important to understand the intended scope of the Business RulesApproach and corresponding business rule management. Differences in scope(e.g., small pilot, first project, across a business unit, entire enterprise) implydifferences in organizational change and business rule management software.

All but a small exception of the participating organizations indicated that thescope of their Business Rules Approach, at the time of the survey, was limitedto one project. An outlier was starting out with an enterprise approach,establishing first an enterprise methodology, standards, and a center ofexcellence.

However, in half of the organizations the goal beyond a successful project wasto extend the approach to a business unit perspective, or enterprise-wide.These organizations wanted to learn lessons from a pilot or project beforeleveraging methods, techniques, standards, roles, and software on a broaderscale.


5. Major Motivations for the Business Rules ApproachThe major motivations for investing in the Business Rules Approach were notsurprising to KPI. The list below indicates the motivations, starting with themost to the least popular. Organizations were invited to provide multiplemotivations, if appropriate.

• Agility: More than half of the participants indicated agility as a majormotivation. Likewise, such organizations tended to deploy a BRMS aspart of their technology solution.

• Consistency: Surprisingly, consistency and reusability of rule setssurfaced as the second most popular motivation, as 50% of theparticipants cited it as a major motivator.

• Business Control or Empowerment: The idea of the business peoplebeing closer to authoring, testing, and discussing rules was the thirdpopular motivation, earning votes from 30% of the organizations.

• Knowledge Retention: The need to document or manage a central rulerepository due to retirement of employees or outsourcing of developmentcame in fourth. It earned votes from about 20% of the participants.However, since the survey, this motivation has surfaced more frequentlyas the working population ages. KPI suspects this motivation is morecritical today than at the time of the survey.

• Legacy Renewal: The desire to modernize legacy systems was cited inonly one case. However, this is likely a subtle motivation as the need foragility, consistency, business empowerment, or knowledge retentionimplies legacy renewal and the Business Rules Approach.

Compliance was originally expected to be a top motivation, but did not take aprominent role at the time of KPI’s survey. The reason for its lack ofprominence may be that organizations needed time to absorb and translate themeaning of new compliance regulations (e.g., Sarbanes-Oxley). Initialcompliance endeavors focused on understanding and documenting criticalbusiness processes first. The need to document detailed rules behind theprocesses came later.

Not on this list, but mentioned often by contributors to this book, is themotivation to build a stronger partnership between the business and IT. Noneof the survey participants listed this motivation as a critical one; yet, fororganizations with more experience in the Business Rules Approach, this resultwas highlighted as the most significant benefit. This was true for at least oneparticipant that did not even deploy a BRMS.


6. The Need for Good PlanningBecause the participants were already started on their Business RulesApproach, KPI asked them to expose those areas needing extra attention soas to manage the revolution gracefully.

By far, the most common area needing good planning was the management ofchange. Over 80% of the organizations listed this as the most critical item.This area included considerations such as understanding the time it takes toabsorb new skills, allowing enough time to evaluate BRMS, allowing ampletime to consider a source rule repository, dealing with resistance to change,encouraging the value of sharing rules and stewardship, providing guidance ona reasonable evolution of business versus IT relationships, and enablingpositive collaboration.

About 30% of organizations also listed rule management issues as needingample planning. These included defining a full business rule life cycle (fromsource documents or people to source rule repository to simulation and testingto deployment) and the impact of having lost the old rules. The latter surfacedas the unexpected realization that no one actually knew the old rules, insystems or in manual processes, so additional time was needed to re-discoverthem or invent new ones. Another important item was to provide training andample time for rule authors to write rules consistently. A lack of standards forsome of the rule-related deliverables, requiring organization-specificstandards, was mentioned.

About 20% of participants cited technology issues that need attention. Theseranged from the time it takes to learn new technology (BRMS) to the time ittakes to implement rules in old technology (COBOL). It also included the timeto find a source rule repository.

7. Is a BRMS Part of the Solution?Most of the organizations included a BRMS as a critical part of the solution.This makes sense, since most organizations also listed agility as a motivatingfactor and are aiming for RMM Level 2. A few organizations indicated the needfor more than one kind of BRMS, and most of them had already selected theirchosen product; only a few had not selected a product. One organization wasnot sure whether it needed a BRMS.


8. Is a BPM or Workflow Product Part of the Solution?Approximately 65% of participants indicated that a BPM or workflow product isto be part of their solution, with the rest indicating that this was not so. Most ofthem, however, had not selected the BPM or workflow product of their choice.

This was interesting because the integration issues between BPM and BRMStechnology did not appear to be high priority or of great concern to this group.

9. Where Are Source Rules Stored?It was important to explore where organizations are storing the business rulesfor the business audience, how they are making the rules accessible, and howthey are managing changes over time by business people. The results werenot surprising to KPI, but still disappointing. The results demonstrate the needfor better available software for managing source rules (which are the rules asthe business person knows them). The answers to this question were so variedthat only Microsoft Excel spreadsheets stood out as the most common, withfewer than 30% of the organizations using spreadsheets.

There was an outlier documenting rules simply in the documentation for thelegacy code. In a similar vein, another stored them in the BRMS. About 15%of the organizations built a home-grown rule repository, 21 % stored such rulesin a requirements tool, and 15% did so in extensions to a modeling tool. Otherorganizations were not specific about whether these rules were storedanywhere or even managed after they were implemented in target technology.

10. Process for Discovering RulesOne survey question asked participants to explain their rule discovery process,specifically, what their starting point for finding rules was and what other piecesthey anchor those rules to. Their responses are, in order of popularity:

• Use Cases: Almost every participating organization utilized use cases asa starting point for soliciting rules and organizing them for action.

• Process Models: Most participants also utilized a process modelingtechnique as a starting point for harvesting business rules. These modelsincluded process maps, activity diagrams, and IDEF0 diagrams (onemethod for modeling decisions, actions, and activities of an organizationor system).


• Documents: Approximately 35% of the participants started withdocuments, such as process descriptions, policy manuals, or legaldocuments. Therefore, their rule discovery processes involved scanningdocuments, highlighting sentences resembling rules, building a glossary,and rewriting rules.

• Code: About 20% of the participants started with program code. Theseorganizations deployed business rule mining techniques to find rulesthere.

11. Current Sources of RulesTo learn where rules live in these organizations today, we explored the mostcommon rule sources. Each participant could list multiple sources. Theseturned out to be:

• People: More than 50% of the participants indicated that rules are bestobtained from people in the organization, either because these people areexperts or they are retiring. This indicates that rule harvesting techniquesthrough interviewing or facilitated sessions are very valuable in mostplaces, along with rule authoring training and software.

• Code: Also half of the participants indicated that a majority of rules aretruly buried in program code. Therefore, business rule mining from codemethods and tools are valuable.

• Documents: Half of the participants indicated that rules are buried indocuments.

12. Anticipated or Actual Classifications of Target RulesKPI wanted to learn whether there was a natural distinction amongorganizations as to specific types of rules. Organizations could list more thanone classification of rules that they anticipated managing.

Across the participants, there emerged a distinct separation of target rules intotwo groups.

One group of rules was defined as simple to complex constraint and validationrules. These are the kinds of rules that guide typical transactions through theirlife cycles, such as rules relating to totaling dollar amounts, validating acustomer, and verifying delivery on a product to a location at a particular time.These are rules that, in the past, have not been implemented in special rule


technology, but were embedded in home-grown code. These tend to be simpleand unconnected rules that validate various parts of a form, for example, or ofdata entered through a web page.

Another group of rules was defined as complex inferencing rules for decisionmaking. These are the kinds of rules that involve complicated, interrelatedjudgments based on many conditions and interim conclusions. These includedetermining a credit score or determining which students receive how muchtuition assistance. These are the kinds of rules that historically have benefitedfrom deployment in commercial or home-grown BRMS.

These different groups of rules have different characteristics: the lattervoluminous with interrelated conditions and conclusions whereas the formertend to be fewer in number, simpler, and not necessarily related to each other.Each group may be better served by technology specific to its uniquecharacteristics.

Only a few participants indicated that complex computations or formulas werethe prevalent classification of rules they sought to manage better.

13. Desired Software FunctionalityEach participating organization was asked to rank software functionalityaccording to how critical that functionality was to the success of their businessrule endeavors.

Below is a list of the functionality that was ranked as “high” by at least oneparticipating organization. They are ranked from the functionality having themost “high” votes to the one having the least number of “high” votes. Votes of“medium” or “low” priority are not included.

• Automated Rule Analysis (the ability to detect conflicting, overlapping,and incomplete rule sets): This requirement yielded the highest votes, asover 60% of the participating organizations considered automatic ruleanalysis versus manual inspection to be critical, especially whennon-technical people may be authoring rules.

• Single Generation of Executable Code (the ability to generate codefrom a rule expression to one target automation platform): 50% of theorganizations ranked this as a high priority, mostly because they hadselected one BRMS product.


• Automatic Workflow for Rule Management (the ability to manage roles,queues, and deliverables along the full rule change life cycle): It was asurprise that almost 50% of the organizations rated this as a “high”priority, yet KPI knows of no commercial offering for this specificfunctionality.

• Multiple Generation of Executable Code (the ability to generate codefrom a rule expression to more than one target automation platform):Almost 30% of participants rated this a “high” priority, indicating that theseorganizations are thinking into the future, at RMM Level 3 or above.

• Integration of Rule Authoring Software with Other Tools (the ability totrace rules and rule sets to deliverables in requirements tools andmodeling tools): Only 7% of participants ranked this requirement as“high,” although most organizations indicated that they either lacked suchtools, were not using them, or had not selected them yet.

• Update of Rules in Production (the ability for non-technical businesspeople to make rule changes directly to production systems): Only oneoutlier considered this “high.” Instead, most organizations are aiming forbusiness people to have more control over specifying the rules,determining the impact of changing the rules, and testing the rules.However, it was not usually the case that these organizations had a desirefor such people to make changes in production systems. More importantis the need for rule changes to occur quickly (faster than changes to otherkinds of requirements). However, these changes can be made bytechnical support people, as long as the changes occur correctly andquickly. In a rare instance, businesspeople have the ability to changerules, analyze them for errors, and test and simulate them for impactanalysis, but they do not want or need the capability to deploy thechanged rules in production.

14. Common Current States of Rule MaturityAt this point in the history of this ongoing survey, KPI determined, based on theanswers to the survey questions, the RMM level of each organization at thetime of the survey and their ultimate goal. These RMM levels would likelyexplain the answers to the questions and provide guidance to readers.

At the time of the survey, the participants fell into two groups regarding wherethey started in their RMM journey. One-third of the participants were starting atRMM Level 2. These are the organizations that, long ago, deployed either ahome-grown or commercial BRMS and built a support group around it. Theseorganizations had established centralized business rule engine groups, but theconnection to and participation by business people was not high. Today, these


participating organizations are looking to be better at managing thebusiness-side of the business rules and bringing the business experts closer tothe process.

Two-thirds of the participants were starting at RMM Level 0, which is where KPIfinds most organizations today. In fact, this group is growing and representsthe organizations that have not previously deployed special rule technology.Today they are interested in separating the business rules from businessprocess models, use cases, other requirements, and, perhaps, but notnecessarily, deploying rule-specific technology.

So, where did the participants want to be?

15. Common Target States of Rule MaturityAn outlier is simply moving from RMM Level 0 to 1. Level 1, delivering a solidknowledge of targeted and consistent business rules, would deliver a greatreturn on investment (ROI) for this organization.

However, most participants, 74%, are aiming for RMM Level 2. Obviously,these organizations are aiming for knowledge and agility of rules. At the timeof the survey, one of the organizations was starting at RMM Level 2 and wantedto stay there. Most of these are organizations investing in a BRMS, although afew were able to deliver agility without rule-specific technology. Also, theseorganizations are aiming for project-level rule stewardship, rather thanenterprise-wide or business-unit-wide, at this time.

About 15% of the organizations are aiming higher. Half of these are aiming forRMM Level 3, with a strong desire to institutionalize the Business RulesApproach in a centralized, common manner across various parts of theorganization, establishing a Business Rules Center of Excellence. Here, thereare established standards and a centralized group, but are mostly approachingbusiness rule projects, one-at-a-time, on a project-by-project basis.

It seems appropriate to end the survey by noting that, in an exceptional case,aspects of RMM Level 4 are not only the target, but have already beenachieved. This organization started at RMM Level 0!


Survey SummaryTable 2 summarizes the answers to the 15 questions.

Table 2: Summary of Survey Questions

Question Number Question Text Majority > 50% Minority < 50% Comments

1 Industries • insurance• mortgage

• other

2 Point of Contact for Survey

• IT • business• IT and business

3 Business Rule Champion

• IT• business

plus IT

4 Scope of Business Rules Approach

• one project • enterprise-wide Goal in most was to extend to business unit or enterprise wide after one or more projects

5 Major Motivations for the Business Rules Approach

• agility• consistency

• business control or empowerment

• Knowledge retention• legacy renewal

Knowledge retention gained popularity since the survey

6 The Need for Good Planning

• change • rule management• technology issues

7 Is BRMS Part of the Solution?

• Yes, and already selected

• not sure• yes, not selected• multiple BRMSs

8 Is BPM or Workflow Engine Part of the Solution?

• Yes, and not already selected

9 Where are Source Rules Stored?

No common response from > 50% of the participants

• MS/Excel spreadsheets

• Legacy code documentation

• BRMS• Home-grown database• Extensions to modeling

or requirements tools• nowhere

10 Process for Discovering Rules

• use cases• process models

• document mining• code mining


Lessons in the SurveyThe following are specific lessons learned through the survey questions:

1. Insurance and financial services industries, in general, have a greatinterest and often the most experience with the Business RulesApproach. Other industries (retail, manufacturing, pharmaceutical, etc.)are now adopting the Business Rules Approach today.

2. The point of contact for KPI’s survey, in most cases, is the IT function.3. The champions for the Business Rules Approach among participants

are either someone in IT or a combination of people from IT and thebusiness.

4. Most participants are aiming to manage rules one project at a time,rather than across a business unit or enterprise, so it seems thatcommon practice is to consider enterprise level business rulemanagement based on lessons learned at a project level first.

Question Number Question Text Majority > 50% Minority < 50% Comments

11 Current Sources of Rules

• people• code• documents

All equal

12 Anticipated or Actual Classifications of Rules

• simple to complex constraint and validation rules

• complex inference rules

• computation rules

13 Desired Software Functionality

• automated rule analysis

• single generation of executable code

• automatic workflow for rule management

• multiple generation of executable code

• integration of rule authoring software with other tools

• updates of rules in production

Most participants were not using an organization standard modeling tools or requirements tools

14 Common Current State of Rule Maturity

• RMM Level 0 • RMM Level 2

15 Common Target State of Rule Maturity

• RMM Level 2 • RMM Level 1• RMM Level 3• RMM Level 4

One organization achieved parts of RMM Level 4, starting at RMM Level 0

Table 2: Summary of Survey Questions (continued)


5. The most popular motivators among participants are agility andconsistency.

6. The area requiring the most attention is planning for organizational andtechnology change.

7. Most participants plan to automate rules in a BRMS and have selectedit.

8. Most participants play to also include a BPM or workflow engine, buthave not selected it.

9. There is no common source rule repository solution that emerged fromthe group, other than 30% of the participants using spreadsheets.

10. Most participants define use cases and traditional process models aspart of their business rule harvesting activities.

11. Most participants are harvesting rules from people, code, anddocuments.

12. There are two major classifications of rules among participants:constraint/edit/validation rules and complex inference rules.

13. The most desired software functionality among participants isautomated rule analysis, generation of executable code to one targetplatform, and automatic workflow for the business rule life cycle.

14. The most common starting point for participants is RMM Level 0.15. The most common target state for participants is RMM Level 2. Higher

levels of the RMM are achievable, but rare today. Achieving RMM Level3 usually requires home-grown software. Therefore, more softwareadvances are needed and expected for enabling rule management andauthoring by the business’s true business rule stewards.

Next Steps for the SurveyWe will increase the survey participants and continue to evolve the surveyquestions as long as it provides value to the Business Rule Revolution.


Reference to Another SurveyReaders may want to refer to another survey that assesses the business rulesmarketplace, whose conclusions are similar to those in this chapter. A whitepaper on that survey is “Business Rules Market Adoption Survey Results” byMichael Peters of Whitespace Consulting and it can be found athttp://www.lambert-tech.com/documents/BusinessRulesMarketAdoptionSurvey_Results_Whitespace.pdf

Another document on Best Practices is athttp://www.lambert-tech.com/documents/BusinessRulesMarketAdoption_BestPractices_Whitespace.pdf

A related presentation can be found athttp://www.lambert-tech.com/documents/210004_LambertBethune.pdf.

http://www.lambert-tech.com/documents/BusinessRulesMarketAdoptionSurve

http://www.lambert-tech.com/documents/BusinessRulesMarketAdoption_Best

http://www.lambert-tech.com/documents/210004_LambertBethune.pdf


c h a p t e r


3 Enterprise Architecture: Managing Complexity and Change

John A. Zachman

IntroductionIt is my perception that enterprise architecture presently is a grosslymisunderstood concept among management, probably for several reasons.The principal reason likely is that enterprise architecture is seen to be aninformation technology, or systems issue, not a management issue. Enterprisearchitecture tends to surface in the enterprise through the information systemscommunity, and the information systems people seem to have some skills to doenterprise architecture if any enterprise architecture is being done or is to bedone in the enterprise.

However, the origins of the concept come from Robert Anthony, “Planning andControl Systems, A Framework for Analysis”4; Jay Forrester, “IndustrialDynamics”5; Erich Helfert, “Techniques of Financial Analysis”6; Peter Drucker,“The Practice of Management”7; George Steiner, “Comprehensive ManagerialPlanning”8;and more recently, Peter Senge, “The Fifth Discipline”9 to name buta few. These works have nothing to do with information technology orinformation related issues per se. The basic concept of enterprise architectureis that it is important to understand the enterprise first, before attempting tooverlay infrastructure investments required to support the enterprise and to

4. Robert Anthony, Planning and Control Systems, A Framework for Analysis. Cambridge, MA: Harvard University Press, 1965.5. Jay Forester, Industrial Dynamics. Boston: Massachusetts Institute of Technology Press, 1961.6. Erich Helfert. Techniques of Financial Analysis. New York: Dow-Jones Irwin, 1962.7. Peter Drucker. The Practice of Management. New York: Harper & Row, 1954.8. George Steiner. Comprehensive Managerial Planning. The Planning Executives Institute, 1972.9. Peter Senge. The Fifth Discipline. New York: Doubleday, 1990.

Page 34 Chapter 3: Enterprise Architecture: Managing Complexity and Change

facilitate its on-going change, because unless engineered correctly,infrastructure (including information systems) tends to be extremely costly andresistant to change.

Reviewing Alvin Toffler’s books about change, first, “Knowledge is change…and accelerating knowledge-acquisition, fueling the great engine of technology,means accelerating change.”10 The rate of change is increasing dramaticallyand putting extreme pressure on reducing time-to-market to accommodate therapid change. Second, the Industrial Age was different from the AgriculturalAge and the Information Age is different from the Industrial Age.11 Theimplication of this is that the game has changed —dramatically. Third, if yougive everyone access to the same information at the same time, the power willshift outward in the enterprise.12 No longer will power be concentrated in twoor three people at the top who know everything, decide everything, and controleverything. In fact, if the customer (or recipient of the product or service) of theenterprise has access to the same information that the enterprise has accessto, the power will shift into the customer environment. It will become“market-driven.”

The practical implications of these observations are first, the complexity of theenterprise will continue to escalate. The moment you say, “customerrelationship management,” or “one-on-one marketing,” or “a market of one,”etc., you are signing up for orders-of-magnitude increases in complexity. Thatis, the day you have to treat each customer as an individual, rather than as agroup, a segment, or a type, you are talking about major increases incomplexity.

This chapter discusses the following:

• The changing enterprise concept• Increased complexity in the Information Age• The Zachman Framework for Enterprise Architecture• A framework metaphor• The Zachman Framework and Business Rules• Conclusion• References

10. Alvin Toffler. Future Shock. New York: Random House, 1970.11. Alvin Toffler. The Third Wave. New York: William Morrow and Company, 1980.12. Alvin Toffler. Powershift. New York: Bantam Books, 1990.


The Changing Enterprise ConceptThis is a fundamental change in the Industrial Age concept of the enterprise.In the Industrial Age, the basic idea was to get a good product or service andthen find a lot of customers to sell it to. That is, from the perspective of theenterprise, the market, the customers), were integrated. By default, thecustomer had to deal with the complexity of “integration” of the enterpriseproducts or services. In contrast, the basic idea of the Information Age is to finda good customer and then identify and provide whatever products or servicesare required to keep that customer a good customer. That is, from theperspective of the customer, the enterprise products have to be integrated. Inthe case of services, it is the enterprise itself that has to be integrated. In theInformation Age case, it is the Enterprise that has to deal with the complexity ofintegration. If the “Powershift”13 takes place (which I am sure it will take placeif you want to stay in the new, Information Age game), the burden of integrationwill transfer to the supplier. The customer wants to see the enterprise productsand/or the enterprise itself customized to the interest of the customer.

Another practicality of the changing game is reduced time-to-market. That is,there will be less and less time from the moment the enterprise receives anorder until it fulfills the order for a product or service customized for thecustomer. As the rate of change continues to escalate, the time-to-market forwhatever the enterprise produces will tend to shrink. In fact, if the rate ofchange goes to infinity, the time-to-market will go to zero. This is the casewhere the customer is unable to define the characteristics of the product orservice they have to take delivery on until the point in time that they have to takedelivery.

From an information technology perspective, the practical implication ofextreme complexity and extremely high rates of change is that the enterprisewill be unable to define the characteristics of the implementation they need totake delivery on until the point in time they need to take delivery. Therequirement will be for enterprise-wide, integrated implementations forimmediate delivery.

Increased Complexity in the Information AgeThe business-significant characteristics of the Information Age are dramaticescalation of complexity and dramatic escalation of the rate of change. Themanagement question is: how will you deal with orders-of-magnitude increases

13. Ibid.


in complexity and orders-of-magnitude increases in the rate of change? Inseven thousand years of known history, the only device humanity has come upwith so far to deal with complexity and change is architecture.

First, regarding complexity, if it (whatever “it” is) gets so complex, you can’tremember everything about it at one time, you have to learn how to describe itbefore you can create it. If somebody hadn’t figured out how to describebuildings, we would still be living in log cabins. If somebody hadn’t figured outhow to describe automobiles, we’d still be riding around on horses. Ifsomebody hadn’t figured out how to describe airplanes, we’d still be travelingin covered wagons. If somebody hadn’t figured out how to describe computers,we’d still be using an abacus or adding up columns of numbers with pencils andpaper. And so on. In the Industrial Age, we learned that there is a set ofdescriptive representations required to describe a complex industrial productincluding, among other things, drawings, functional specifications,bills-of-material, etc., that is, architecture.

Regarding change, once you create a complex product and want to change it,you start with the architecture: the drawings, the functional specifications, thebills of materials, etc. If you have no architecture and you want to changesomething (e.g. a building, airplane, computer, etc.), there are only threepossible options: 1) You can change it by trial and error and see what happens.This is the high-risk option in that you could make a rather small change andpotentially cause irreparable damage. 2) You can reverse- engineer thearchitecture, the drawings, the functional specifications, the bills of material,etc. to serve as a basis for changing it. That takes time and costs money. 3)Or, you could scrap the whole thing and start over again, building a new,changed version. The point is, architecture is the baseline for changinganything that is already in existence. If you have no architecture, you will haveto create or re-create the architecture or risk scrapping the product.

In the Industrial Age it was the industrial products that were increasing incomplexity and changing. If we, humanity, had not figured out how to describecomplex industrial products, we still would be in the Industrial Age and wewould not have Boeing 747’s, hundred-story buildings, ocean liners,supercomputers, etc. It has only been in the last fifty years or so that we havefigured out how to exploit these very sophisticated descriptive representationsof industrial products to produce custom products, mass-produced in quantitiesof one for immediate delivery. This idea of “mass-customization” is stillrelatively new even in manufacturing, however; as the Information Age wearson and customers want (or need) their products to be integrated to their uniquerequirements in very short periods of time, mass-customization will likely be therule, not an exception for industrial products and for enterprises.


In the Information Age, it is not only the industrial product that is increasing incomplexity and changing, it is the enterprise that is increasing in complexity andthe enterprise that is changing. The question for the Information Age is: whatis architecture relative to enterprises? This may well be the issue of thecentury.14

The Zachman Framework for Enterprise ArchitectureIf you (the enterprise) do not have an enterprise architecture strategy, you likelydon’t have a strategy for addressing orders-of-magnitude increases incomplexity and orders-of-magnitude increases in the rate of change. Theauthor is confident that complexity and change will be the characteristics of theInformation Age, and “the enterprises that can accommodate the concepts ofenterprise architecture are likely to be the survivors and those that don’t arelikely to be the rest.”15

I spent more than 35 years of my professional life trying to figure out whatArchitecture looks like relative to enterprises. If I have done anything of value,my contribution has been in the form of a framework, a Framework forEnterprise Architecture. The Framework for Enterprise Architecture simplydefines what enterprise architecture looks like. It is not mysterious how Ifigured this out. I went back to the Industrial Age products and tried tounderstand what Architecture was relative to industrial products, and then Isimply assigned enterprise names to the set of design artifacts that werecreated for describing anything, including enterprises.

It turns out that architecture is architecture is architecture. It doesn’t matterwhat the architecture is for: buildings, airplanes, automobiles, computers,whatever. The underlying order of the descriptive representations is the same.This is a very, very brief discussion of a very complex subject.16 In fact, I havewritten an entire book17 on this subject. For the purposes of this article, thedescriptive representations (the architecture) fall into a two-dimensionalclassification system:

14. John A. Zachman, “Enterprise Architecture: The Issue of the Century.” Database Program-ming and Design Magazine, Volume 10, number 3 (1997). 15. Ibid.16. Boeing 747’s are complex and architecture for Boeing 747’s is complex. Enterprises are even more complex than Boeing 747’s and therefore enterprise architecture is going to be a very complex subject. People tend not to want to hear that Enterprises are complex but I would be less than honest if I didn’t point this out. The whole reason for engineering anything is to make whatever you are engineering as simple as possible … but no simpler. (I think it was Ein-stein that said that.)17. John A. Zachman, The Zachman Framework: A Primer for Enterprise Engineering and Man-ufacturing.. La Cañada, CA: Zachman International, 2003. http://www.ZachmanInterna-tional.com.

http://www.ZachmanInterna-tional


The Interrogative dimension, a single abstraction of:

WHAT the product is made of: the material composition, the parts thatmust be in inventory to create the product, the bill-of-materials

HOW the product works: the transformation of raw material and energy,the functional specifications

WHERE the parts are located relative to one another: the geometry, thedrawings

WHO does what work: the operating instructions

WHEN do things happen: the machine cycles, the timing diagrams

WHY do they happen: the engineering design objectives

The audience dimension, a single audience for whom each interrogativeis framed:

SCOPE – setting the boundary, the limits of each abstraction

OWNER – the needed concepts of the end result, the requirements

DESIGNER – the systematic logic to realize the concepts, the schematics

BUILDER – the technology constructs to build the product, the blueprints

SUB-CONTRACTOR – the production tool configuration for thecomponents

OPERATOR – the end result – this is no longer architecture (that is, adescription) – it is an instance of the product, the end result

This two-dimensional classification system is typically depicted as a“framework” with the interrogatives (abstractions) appearing as the columnsand the audience perspectives appearing as the rows. Since each column(interrogative) is unique and varies independently from all the other columnsand since each row is unique and varies independently from the row above andfrom the row below, the framework, the “Zachman Framework,” is NOT simplya matrix. It is a “normalized” schema. Only one fact can go in one cell, that is,one “meta-entity” can only be classified in a single cell.18

18. For the non-technical reader, you don’t have to be intimidated by the words “schema,” “nor-malization” or “meta-entity.” The “schema” is just a two dimensional classification system that can be depicted in a matrix form, rows and columns. “Normalization” simply means that the classification system is “clean”—that is, there are no “apples and oranges” or mixtures in any cell of the matrix. And, “meta-entity” is an abstraction that you need if you want to store some-thing in a database. In the case of enterprise architecture, you will want to store the models in a database .


Although I learned about the underlying schema empirically by looking at theengineering design artifacts, the descriptive representations of Industrial Ageproducts, my interest was in enterprise architecture, so I simply assignedenterprise names to the same engineering design artifacts that were relevantfor describing airplanes, buildings, computers, anything. Figure 319 is theFramework for Enterprise Architecture, the “Zachman Framework” as itpresently is depicted.

The meta-entities and the meta-meta-entities have appeared at the bottom ofeach cell of the Framework since its inception. I have changed some of thewords since I first created the graphic around 1980, but the schema itself hasnot changed; nor will it ever change. In fact, the classification on either axis ofthe Framework has been employed by humanity unchanged for hundreds if notthousands of years. There are two reasons for my changes of some, actuallyfew, of the words in the graphic. First, our understanding of the schema in 1980was limited, and some of the words I selected did not accurately represent theclassification concepts. Second, and unfortunately, I came from the informationcommunity, and some of the words I selected came from my informationsystems vocabulary.20 This has contributed to some of the misunderstandingof enterprise architecture as an information technology issue, as opposed tothe correct understanding that it is an enterprise issue.

19. The original version of this framework is available at www.ZachmanInterna-tional.com/fwgraphic.html.20. We have been working with some linguists from SIL International for nearly five years to identify words that more accurately convey the concepts of the framework schema and to employ words that are more business-oriented than technology-oriented. In November, 2005, we published the new standard meta model for the framework at www.ZachmanInterna-tional.com. Although the new standards are available at no cost, they are distributed on a CD that contains my book, among other things. The CD must be registered to be opened.

Page 40

Chapter 3: E

nterprise Architecture: M

anaging Com

plexity and Change

Figure 3: The Framework for Enterprise Architecture (the “Zachman Framework”).


Since each cell of the Framework is unique and since it can contain only twometa- entities, the meta-entity that constitutes the focus of the cell descriptionand its relationship with itself (the other meta-entity), I call each instance of acell model a “primitive” model. The raw material for doing engineering is theengineering design artifacts for the complex product. For engineering anenterprise, the Framework cell descriptions, the primitive models, are the rawmaterial for doing enterprise engineering. In fact, I would observe, if there areno primitive models for any given enterprise, that enterprise has not beenengineered. It has simply happened.

In contrast, implementations require components from more than one cell:composite models as opposed to primitive models. A primitive model is notimplementable. A composite model is made up of components from more thanone primitive model. Implementation is manufacturing, not engineering.Primitive models are for engineering; composite models are for manufacturing.

A Framework MetaphorMaybe a useful metaphor for the Framework is the Periodic Table. It wasaround 1890 that Mendeleyev published the Periodic Table, a two-dimensionalclassification of the chemical elements of the universe. The Periodic Tableclassified all of the possible elements even though many of the elements hadnot yet been discovered. The elements themselves do not exist as elements innature. In nature, the elements only exist as compounds, that is, as compositesof more than one element. The elements of the Periodic Table are the rawmaterial for doing chemical engineering. Chemical engineering is creatingcompounds, but not manufacturing. Before Mendeleyev defined the PeriodicTable, there were chemicals (compounds), but there was no “chemistry.”Nothing was predictable or repeatable except by personal experience. Theenterprise framework implications of this analogy are that although theenterprise is made up of composite implementations, they were not likelyengineered. They were created by trial and error based on the experience ofthe implementers.

If you assume the most robust case, that there is a many-to-many relationship21

between any one meta-entity in any one cell and all the other meta-entities inthe row, as well as a many-to-many relationship between any one meta-entityand the meta-entities of the cell above and the cell below, and if you hadpopulated a data base with primitive models for some enterprise, then you

21. For those non-technical readers, a many-to-many relationship simply means that there are two different things that are related to one another but that vary independently from one another, such as employees and positions. They are different, and they are related, but they vary independently.


could create virtually any composite implementation for that enterprise simplyby binding the primitive components together. That is, you could“mass-customize” the enterprise at the click of a mouse. You could satisfy thedemand for virtually any enterprise-wide implementation at the point in time theenterprise discovered they needed that implementation.

Please remember that this is a very brief discussion of a very complex subject,and that it will likely take some period of time to accumulate some (and possiblysomeday, all) of the primitive models. However, hopefully this gives you asense of the enterprise possibility for addressing orders of magnitudeincreases in complexity and orders of magnitude increase in the rate ofchange, by engineering the enterprise (the primitive models) and assemblingthe enterprise to order (building composites) on demand.

The Zachman Framework and Business RulesAt the time I published the second IBM Systems Journal article on myFramework in 1992,22 we felt that business rules were classified in the Whycolumn (Column 6) and the System row (Row 3). In fact, I named the column6, row 3 cell “e.g. Business Rule Model.” Subsequent to that publication, wehave learned much about primitives and composites as well as about businessrules. Today, I would observe that the focus for identifying and defining thebusiness rules may well still be column 6, row 3, but the business rulesthemselves are likely complex composite constructs relating meta-entities frommore than one cell. Had we known what we know today when the GUIDEBusiness Rules Project Final Report was published in October, 199723, weprobably could have anticipated the composite nature of the business rulessimply by observing the meta-model described in the report. Clearly, therewere meta-entities that would be classified in cells other than simply column 6,row 3. Further, the row 2 Business Rules meta-model that was published in theOctober, 2000 report by the Business Rules Group in “Organizing BusinessPlans: The Standard Model for Business Rule Motivation” also includedmeta-entities that would be classified in Columns and Rows other than and inaddition to column 6, row 2. The body of knowledge in enterprise architecture,as well as in business rules, is presently exploding. There is no better time thannow to be involved in these vital enterprise issues.

22. J.F. Sowa and J.A. Zachman, "Extending and Formalizing the Framework for Information Systems Architecture,” IBM Systems Journal, vol. 31, no. 3, (1992).23. Both Barbara von Halle and I were contributors to the report GUIDE Business Rules project. Final Report. Revision 1.2. October 1997. The project likely spanned more than five years and was probably the first formal publication on the subject of Business Rules.


ConclusionI don’t think there is any question about whether an enterprise is going to doenterprise architecture or not; that is, it will not be optional if an enterpriseintends to be viable in the Information Age. The only question is when they willstart working on enterprise architecture, because there potentially is a lot ofwork to do—and at the point in time the Enterprise is going to need it, it is goingto be too late to do it! Business rules may well be a good place to start workingon it.

ReferencesAnthony, Robert. Planning and Control Systems, A Framework for Analysis.

Cambridge, MA: Harvard University Press, 1965.

Drucker, Peter. The Practice of Management. New York: Harper & Row,1954.

Forrester, Jay. Industrial Dynamics. Boston: Massachusetts Institute ofTechnology Press, 1961.

Helfert, Erich. Techniques of Financial Analysis. New York: Dow-Jones Irwin,1962.

Senge, Peter. The Fifth Discipline. New York: Doubleday, 1990.

Steiner, George. Comprehensive Managerial Planning. The PlanningExecutives Institute, 1972

Toffler, Alvin. Future Shock. New York: Random House, 1970.

Toffler, Alvin. Powershift. New York: Bantam Books, 1970.

Toffler, Alvin. The Third Wave. New York: William Morrow and Company,1970.

Zachman, John A. The Zachman Framework: A Primer for EnterpriseEngineering and Manufacturing. La Cañada, CA: Zachman International,2003. http://www.ZachmanInternational.com.

Zachman, John A. “Enterprise Architecture: The Issue of the Century.”Database Programming and Design Magazine, 3 (1997).

http://www.ZachmanInternational.com


c h a p t e r


4 The Business Architecture of Business Rules Based Enterprises

Larry Goldberg

"An architecture is a framework for the disciplined introduction ofchange." (de Marco, "On Systems Architecture",

The Atlantic Guild, Inc. 1995)

Introduction“Business rules…serve as the guidance system that influences the collectivebehavior of an organization’s people and information systems. The BusinessRules Approach is a formal way of managing and automating andorganization’s business rules so that the business behaves and evolves as itsleaders intend.”24 But, once an organization has determined to pursue theBusiness Rules Approach, what are the architectural implications of thatdecision? If the Business Rules Approach is indeed a “formal way of managingand automating” enterprise solutions, then no doubt a reference architecturefor the design of these solutions exists. Or does it?

There is little published material on the subject. In fact, what formalizedarchitecture for business rules that does exist is principally provided byBusiness Rule Management System (BRMS) vendors. As such, it is focusedon patterns appropriate to specific technology—and for the most part it focuseson technical deployment rather than the business aspects. Here we have theunfortunate, but common, specter of architecture being driven bytechnology—not an unknown phenomenon in this industry, but nevertheless anundesirable practice. Therefore, this chapter covers the following:

• Business rules in the context of business enterprise architecture• A brief discussion of the KPI RMM and its impact on architecture

24. Barbara von Halle, Business Rules Applied (New York: John Wiley & Sons), 2002

Page 46 Chapter 4: The Business Architecture of Business Rules Based Enterprises

• The rule authoring and governance environment• The rule design environment• The rule deployment environment• A brief—but important—digression from architecture• Returning to the architectural considerations in the design environment• Deployment environment• A special problem: business rules versus business process management• Conclusion

Business Rules in the Context of Business Enterprise ArchitectureTo consider suitable patterns for a business rules architecture, it is important tostart within the context of an accepted business enterprise architectureframework. The choice may be any one of the accepted models (they map wellto one another). This chapter starts with the Zachman Framework (ZFW)because of its elegance and simplicity. It is conveniently described in Figure 3of Chapter 3 by its author, John Zachman.

In this framework, the architecture of the business enterprise is fullyrepresented in a series of columns and rows.

The six columns represent the “what, how, where, who, when, and why” of theenterprise. Five rows represent the views of the enterprise, and the sixth is theactual functioning enterprise. “The perspectives or rows are very abstract ...near the top, but become progressively more ... (technical) toward the bottomuntil an implementation emerges on the last row. This implies that theperspectives can be mapped to a product development life cycle where the toprows are used early on while the bottom rows become more important duringthe latter phases …The top two rows are intensively business-oriented and canbe expressed in business-oriented vocabularies, while the bottom four rowsare in the technical domain.”25

This view of the enterprise is complete and the rows and columns remain inconstant orthogonal balance. It clearly shows the independence of businessrules (column 6, or ZFW C6) to conventional system requirements (ZFW C1,C2, and C3). It also illustrates how business rules authorship shouldappropriately be performed in rows 1, 2 and 3, (ZFW R1, R2, R3) systemdesign should take place in ZFW R4, and deployment should occur in ZFW R5and R6.

25. Larry Goldberg, “Architecture,” Systems and Software Consortium, 2005


It is important to understand that while the framework may be used at theenterprise level, it may also be recursed to lower levels of the enterprise todescribe business units, organizations, and even individual projects within thelarger enterprise, each constrained within the bounds specified at the higherlevel. This is key to understanding the opportunity of re-use of business rulesacross the enterprise as rules architectures approach the highest levels of theKPI Rule Maturity Model (RMM).

A Brief Discussion of the KPI RMM and its Impact on ArchitectureKPI’s Rule Maturity Model (KPI RMM™) is a framework that organizations useto determine and improve their ability to develop, evolve, and align businesspolicies and business rules in a rapidly-changing or highly-regulated businessenvironment. (A detailed explanation of the RMM is in Chapter 1).

The RMM is a model for organizational improvement. It is aimed at thebusiness process of managing core business policies and rules from businessinception to deployment, which may include automation of business rules insoftware. The maturity levels are based upon the quality improvements in thebusiness’ management and awareness of the business process around rulesmanagement, rather than the quality of the software. We refer to levels ofmaturity as RMM1, RMM2, RMM3 and so on.

In a real sense, the KPI RMM™ is a roadmap toward the goal of achievingrealization of the full promise of the Business Rules Approach.


An Architectural Approach to Business Rules

Figure 4: A Business Rules Model Mapped to the Zachman Framework

As indicated in the ZFW, business rules originate from and are subject tobusiness objectives and motivations, whether these are internal or external(such as regulations). From an architectural point of view, some of the keycharacteristics of rules are:

• Rules are present in many forms throughout the business. Often they arenot even recorded, but simply understood.

• There is a class of rules that are subject to a high frequency of change.The volatility of these dynamic business rules is believed to haveincreased in recent years, and is considered to be generally significantlygreater than the rate of change of business systems requirements.

• Certain rules are frequently required to be verified and validated byoutside regulatory or audit bodies, as to: – Content– Execution– Result


• Rules may be both automated in technology and manually executed —insome cases the same rules can be found in both environments.

• When rules are automated, they are often deployed in many, if not all,layers of an n-tier architecture, frequently in disparate technologies.

• When automated, business rules are expressed in completely differentterms and language from how they exist in the business domain.Frequently a single business rule will translate into many lines of code ina designed rule set of "technical" rules.

These characteristics point to a need for separation of rules authoringenvironments from the design and the deployment environments. Theauthoring is essentially a business activity, while the design is technologyconstrained and focused on the implementation of those rules within one ormore target technologies.

Happily, this is consistent with the Zachman Framework. Consider the threelayers of architecture in the Business Rules Approach, and discuss theirrelationship to the Zachman Framework:

The Rule Authoring and Governance EnvironmentThis is analogous to the first three rows of the Zachman framework, where wecapture:

• business goals and their motivations (row 1, Contextual), • business rules (row 2, Conceptual), and• authored rules in a comprehensive rule model (row 3, Logical).

This implies the relationship of the business strategy and other business-basedconstraints to their related business rules. It occurs in such a way that the ruleswill immediately be highlighted when the prescribed business motivationschange.

The authoring environment provides the tools for the gathering (also referred toas harvesting) of rules from their sources. This may be a bottom-up process todiscover the rules that are in place in existing systems or practices, or it maybe a top-down process deriving the rules from policies or new businessdirections.

The sources may include rule mining artifacts (via tools and manual methods),interviews, document examinations, and similar discovery items.


This environment is independent of the design and deployment environment,because it is an activity that is business-focused and must necessarily beavailable to the business. Ultimately (at the higher levels of RMM), theauthoring of rules should be managed and led by the business.

The primary tools used in this environment include rule-mining orlegacy-understanding tools, business and process modeling tools, and mostimportantly, a Source Rule Repository (SRR) which serves as the central storeof and access to the business rules, their models and glossary for the businessaudience.

The most important characteristic of a SRR is its ability to be independent ofand agnostic to the systems deploying those rules, and to their design andarchitecture. Depending on the level of maturity required, the SRR shouldprovide features that permit comprehensive business management functionsto be performed on the business rules. The extent of functionality is driven bythe target state of KPI RMM™ desired. Figure 5 is a starting point for correlatingRMM levels and ZFW rows to corresponding SRR capabilities.

Figure 5: Source Rule Repository – high level requirements matrix

RMM 1 RMM 2 RMM 3 RMM 4 RMM 5

ZFW R2: Resources to be Managed

Strategy, Objectives and Policy Documents





ZFW R2: Functionality

Trace to R3 Author, Trace to R3

Author, Trace to R3, Govern

Author, Trace to R3, Govern, Measure, Budget

Author, Trace to R3, Govern, Measure, Budget, Forecast


Natural Language Business Rules

Natural Language and Formal Business Rules, Glossary





Access, Search and Report

Author, Access, search and Report, Test,Trace to R2 and R4

Author, Access, Search and Report, Test, Trace to R2 and R4, Govern

Author, Access, Search and Report, Trace to R2 and R4, Govern, Measure

Author, Access, Search and Report, Trace to R2 and R4, Govern, Measure, Predict


DesignedRule Set

Designed Rule Set Designed Rule Set Designed Rule Set


Trace to R3 Author and Trace to R3

Author, Test and Trace to R3

Author, Test, Measure and Trace to R3


This authoring environment, at its highest form of evolution, should provide theenterprise’s leaders with the controls of the "guidance system" promised by theBusiness Rules Approach. It should properly integrate with the modeling toolsused in the enterprise in data and process management, while at the same timebe robust and complete in its Business Rules capabilities.

The Rule Design EnvironmentFrom the structured rule, and from the rule models contained in the authoringenvironment, the design environment is used to implement a system modelconstrained to the defined deployment environment. Here the rule is expressedin its technical expression, or the "technical rule." This can approximate code,or in the most evolved of rules engines, may bear a close resemblance to thestructured rule. The design environment is by definition constrained bytechnology. A difficulty in the Business Rules Approach is that frequently thetechnology constraint is pre-existing. While this is not an unusual state in manysystems development environments, it can be a particularly taxing problem forsystems that conform to the Business Rules Approach.

The Rule Deployment EnvironmentThese are actual instituted technical rules, in a form that may be consumed byrules engines and other execution environments. The importance of thisenvironment turns on maintaining traceable links with accurate versioning fromthe source rules to the executable rules.

A Brief—But Important—Digression from ArchitectureA few words are needed about some practical issues (for architects, thistouches on dreaded issues of methodology) , even in this theoreticalconversation about architecture. This digression is warranted by the frequencywith which the high-risk situation described below is encountered, even inorganizations with strong architecture groups.

This undesirable but common situation is where the technology constraints inthe Design Environment are set by an organization’s choice of a BusinessRules Engine (BRE) or a BRMS.

There are two traps present in this situation.


The First Trap is that the architectural approach to business rule developmentis dictated by the development patterns practiced by the technology vendor.

“Best Practice” becomes “Vendor Practice,” in which in most cases the rulesauthoring process is limited to the gathering of rules entered directly into theBRMS tool, and for only those rules best supported by that tool. Most vendorstake pride in and differentiate their BRMS products by their development tools,many of which completely bypass best rules authoring practices that connectto the business audience to achieve rapid development cycles.

Notwithstanding vendor claims, insufficient business rules management isperformed in these tools as they exist today. Typically the rules entered into thesystem are already highly formalized or are even analogous to direct code. Thefocus, in the past, of the BRMS vendors has been the pursuit of rapiddevelopment offered by the terse, declarative, atomic rule statement. While thisadvantage is real and significant, it has unfortunately led to the very rapiddevelopment of systems that once in service have hidden the business rulesas fully—if not more completely—than traditional COBOL systems.

A good example is a recent decision by a Fortune 100 company to replace amajor—and successful—order processing system developed over many yearson a BRMS platform with an expensive ERP system. The principal reason?“We don’t know what the rules in the system are.” The point here is that themere use of a BRMS platform may provide technical agility, but there is noguarantee that its use will provide any more business agility than exists in aprocedurally coded environment.

So the practice of only following vendor development patterns mayunfortunately lead to the loss of some or all of the benefits of a Business RulesApproach, including, but not limited to:

• Loss of access by the business to the rules.• Loss of traceability of the rules to their business objectives and sources. • Inability to deploy the rules to other or multiple technologies.

The Second Trap occurs when the mandated BRMS is found to be poorlymatched to the type of rules being used in a particular project or system. Thisleads to the nightmare scenario of failed projects, budget overruns, andunhappy customers. Many examples of this mismatch abound. Because thereis frequently no separation of authoring environment from deployment, oncethe technology is deployed it is difficult, time-consuming and expensive totransform to another technology.


Similar, and even greater, difficulties occur where the business rulestechnology constraints are set by the requirement that the rules be executed bythe rules engines embedded into a selected business process managementtool. Here the difficulties are that in large part these tools have very limitedfunction rule capability, and lack even the limited rules management facilitiesprovided by the BRMS systems.

In contrast, best practice in the design environment is to set the technologyconstraints only when the types of rules, quantity of rules, and the appropriateuse of rules and appropriate patterns of development are well-understood.Because of this, it is advisable to complete a scoping exercise (or even morepreferably, a pilot exercise) in the authoring environment that provides a goodsample of rules and a relatively complete rules model before defining andsetting the desired technology constraints in the design environment.

Returning to the Architectural Considerations in the Design EnvironmentA wide range of patterns are available to architects in the design environment.BRMSs derive from two primary roots:

Knowledge engineering, which gave rise to expert systems. These haveevolved over time and with advances such as the Rete algorithm into BRMSsthat have advanced inference capabilities. These engines are ideally used insupport of decisions where large quantities of rules are executed againstrelatively small amounts of data. Classically these are called “inferenceengines,” whose strengths lie primarily in backward chaining algorithms. Theirmethod of reaching a conclusion is to:

• Examine data to determine which rules reference that data. • Test the conditions of the rules that reference this data to determine

whether this requires additional pieces of data • Determine which additional rules reference the additional data• And so on until the chain is complete, at which point the engine is then

responsible for determining the order in which the rules should correctlyexecuted, and a conclusion is reached

The advantage of this approach is that the programmer is free to createdeclarative rules without considering in advance the sequence in which therules may be used.


An example of this may be a group of rules defining customer status. When thecustomer name is submitted to the engine, and the engine has all availablecustomer data and is requested to find the customer’s status, it can be reliedupon to gather from the stack of all rules the appropriate customer rules andresolve the customer status based upon the available customer data.

These engines are considered most appropriate for decision intensivesystems, typified by insurance underwriting, credit assessment, and similarapplications.

Process engineering, which evolved with the development of the Data Baseengine, allows the separation of data from process and the definition of objects.Ultimately this led to the separation of rules from the code (as the code was inturn separated from data), and the development of BRMSs that areevent-driven. In these engines an event (such as change in state of data)triggers the execution of rules. These engines are typically used for largequantities of data being processed against constraint and calculation rules,with relatively little inference being required. They are necessarilyforward-chaining engines: they follow the chain of triggers of a sequence ofrules until the chain is exhausted. These sequences (and their branches) haveto be defined by the programmer, and the goal of the chain known in advance.They are very apt in transaction processing environments, where a series ofconstraints are applied to data as it is processed.

These rules tend to be focused on data constraints and transactions, leadingto a 'fit' to applications that have intensive, large-scale business transactions attheir core.

Which is the best engine ? While each type of engine can more or lessperform the services of the other, there is no question that performance andfunction will be executed dramatically better by the appropriate engine:

“While it is possible to emulate an event-driven system using inferencemethods and vice versa, the key question of efficiency must be examined. Inassessing the performance of BRMSs, the sensitivity to both the number ofrules and the amount of data must be considered. Inference-driven enginesscale well as the number of rules increases; however, performance ofRete-based engines degrades rapidly as data volume increases. Event-drivenengines scale linearly, both with regard to the amount of data and with regardto the number of rules triggered by an event.”26

26. Segal, Gil. "Business Rules for Business Transactions," Sapiens White Paper, 2005


As the business uses of rules engines evolves, developments are occurringthat are beginning to blur the distinction between these engines. Traditionalevent-driven engine vendors are adding inference engine capabilities to theirplatforms, as well as sequential processing (i.e. a "by-pass" of the Retealgorithm) to emulate event-based processing.

In both cases, rules engines have to be carefully assessed as to performancein any given environment, as their processing characteristics can varydramatically. A major insurance company fell into a typical trap when it chose arules engine for a strategic initiative, only to discover well into the project thatthe engine had very poor performance in computation rules—and that theseconstituted a large portion of the proposed application! The result of this errorwas the abandonment of almost half of the project, and over a year of lost timein deployment.

In the enterprise it is possible—and for higher levels of the KPI RMM™,appropriate—to provide an architecture where a generalized rules service isdefined for all types of rules, each being served by the most appropriatetechnology. On the other hand, not all rules are best supported byloosely-coupled services. For example, a rules service would probably not beappropriate for large scale data transformation. In these circumstancesspecialized rules engines may be necessary and desirable. It is important toprovide a place in the architecture for this specialization, while at the same timepreserving the traceability from the rules authoring and governanceenvironment to all the systems incorporated in the design.

Deployment EnvironmentThe deployment environment for rules-based systems are many and varied,and many business rules within a system are appropriate for manualimplementation.

By definition, rules are embedded in almost all programs, routines, interfaces,databases and other elements of systems. These rules may be purelysystem-related. Those that are of interest in a business rules architecture arethose that implement business rules.

The taxing problem is that the rules within legacy systems are generally burieddeeply in code, some even spread across different physical layers of a system.Deployed rules that represent a business rule in the SRR must be appropriatelyrecognized in the architecture and provided with the facility to be analyzed,traced, and versioned to the business rule in the SRR.


The appropriate means of deploying rules in an n-tier environment may beinformed by considering Figure 6, which draws liberally upon a diagramprovided by Versata, Inc.

Figure 6: Patterns of Deployment of Business Rules

Figure 6 illustrates a relationship of decision rules to their dynamic, distributedcharacteristics, while transaction and data constraint rules tend to becentralized, and more static in their nature. It is easy to envisage a "rulesservice" based on a Business Rules deployment facility to provide for processand decision rules in the upper tiers of an n-tier architecture, while embeddinga centralized set of transactional and data constraint rules in the data accesstiers.

The concepts in Figure 6 can also be helpful when approaching problems suchas rules embedded in commercial applications. These can be categorized inthe same fashion, and thus referenced by tools or processes in the appropriatelayers of the architecture.

A Special Problem: Business Rules versus Business Process ManagementA particular issue that needs to be dealt with is the role of business rulesvis-à-vis business process management. There abounds in many quarters themisguided notion that business rules are an encapsulated component ofbusiness process management. Too often, many enterprise architectures


represent business rules within the larger container of the business processbubble. And then of course, there is the fact that many business process,workflow, and content management engines incorporate "business rules" thatare programmable by the user. Since architecture is frequently driven bytechnology, the deployment of this technology leads to business rules beingburied again, this time into the process engines.

All of this is unnecessary. The correct architectural approach can lead to animprovement in business process management implementations whilemaintaining a separation between process and business rules. Figure 4 showsa business rules model with a natural connection points between businessrules in Column 6 and business process in Column 2. These points are, in themain:

• Business Process to Decision to Business Rule Set. It clearly shows theconnecting point in Figure 4, while a more detailed illustration of therelationship is illustrated in Figure 7.

• Business Rule Glossary mapped to the Business Process Object Model,again shown in Figure 4.

By separating the components in the architecture at those points, thearchitecture enables business rules to be changed independently of processand vice versa. This preserves all the advantages of both business process andbusiness rules management, significantly improving business agility.

Figure 7: Separating Business Rules From Process Using Decisions


ConclusionFor an enterprise that has made a commitment to pursue the Business RulesApproach, there is a significant reduction in risk and concomitant increase inreward to be had, by first defining needs using the KPI RMM™, and thenbuilding a business architecture to support those needs. The architectureshould reflect the need to place the business firmly in control of business rules,and the greater the maturity that the enterprise needs to achieve, the greaterthe role of the business in managing the rules.


Part IIThe Business Side of Business Rules

Aimed specifically at the business audience (but appropriate also fortechnical audiences), this section examines the crucial relationship ofbusiness rules to business processes and elevates the business policymaker to rule author. The four chapters cover the integration of businessrules to a business engineering approach (Chapter 5), benefits achievedin combining business process modeling with business rules at a stategovernment organization (Chapter 6), the dynamics of iterating processmodeling and business rules (Chapter 7), and a major corporation'sground-breaking rule management software for its policy makers(Chapter 8).

Again, in their own words, below are quotes selected by each author toprovide the reader with insights into each chapter:

“The business rules movement is catalyzing the desire of organizationsto move towards a business engineering approach where the businessspecifications are no longer requirements that support the developmentof IT design. Rather, they are the business configuration that is expectedto be loaded into the IT solution.”

Chapter 5, Neal McWhorter

Page 60 Part II: The Business Side of Business Rules

“Business users are directly involved in the business requirementsidentification and verification much earlier in the development process.The implementation of this tool [at Oregon Public Employee RetirementSystems] allowed us to consolidate business rule responsibilities from IT(QA) systems staff to the primary business users after appropriatetraining.”

Chapter 6, Larry Ward and Jordan Masanga

“What is perhaps surprising is that the impact of business rules on theseother model views and on their quality may be as significant as theachievement of clearly specified business rules. What proved mosteffective…was not a top-down, process-to-rules approach, but one thatiterated between both perspectives.”

Chapter 7, Art Moore and Michael Beck

“This chapter discusses our journey into more sophisticated andinnovative software to empower the rule authors:

• A rule inquiry application to enable access to and inspection of rules• A rule maintenance application to hide the idiosyncrasies of the rules engine (and

allow for changing the rules engine)• A rule analysis application to ensure integrity of new and changed rules• A rule application emulator so rule authors can see the rules in action (simulated

with data) prior to actual deployment in the target rules engine.”

Chapter 8, John Semmel

c h a p t e r


5 Business Engineering and the Role of Business Rules

Neal McWhorter

A Definition of Business EngineeringThe service industries, banking, insurance, and accounting, among others,have had a long-standing culture of separation between business work andwork on tools to support the business. This separation came about naturallyenough, since most of these industries existed in some form or the other priorto automation playing a significant role in their operations. But the technologyas a tool approach is a business practice whose time has come and gone.Nowadays, technology is integrated into these businesses and what are beingoffered are technology-based services. Yet despite this huge change, mostorganizations have yet to address the internal divide within their organizationsthat separates business from technology. What is needed is an integratedapproach that obliterates the old divide and brings the business back into directcontrol of the development of these technology-based products and services.We call this approach business engineering.

Business engineering is a holistic approach to business design that starts withthe premise that automation solution design is product design. This is a bigdeparture from most approaches that assume that automation solution designis engineering the supporting infrastructure to operate the business. What is itabout the changes of the recent years that drives this shift in approach? Thefundamental shift in approach derives from a shift in ownership of knowledge.Previously, people owned the knowledge, and they used tools to assist them.But since the tools were just an internal aid in performing the business, theknowledge that controlled a business’s operations remained fundamentally inthe hands of people. With the pervasive automation of businesses and theexplosion of technology-based services as products in their own right, the

Page 62 Chapter 5: Business Engineering and the Role of Business Rules

balance has shifted. Now the knowledge is embedded in the automationsolution itself. And because much of the business operates without any humanjudgments being made, there isn’t any going back.

The remainder of this chapter covers:

• Three ways to represent knowledge behind business engineering• The importance of capturing decisions in business engineering• Business decisioning• Incorporating business level specifications with automation specifications• The gap in business entities today• The gap in business processes today• The Business Rule Revolution• Back to business decisions• Summary

Three Ways to Represent Knowledge Behind Business EngineeringThe knowledge that we are engineering to support our business is representedin one of three ways: as business entities, business processes, or businessrules. There is no simple explanation for where to draw the boundary amongthese three ways of capturing business knowledge. Each involves a trade-offbetween comprehensibility and ease of change. Business entities representbusiness knowledge that we believe is relatively fixed. We also believe that bymaking the concepts fixed we lose little in flexibility and reduce the complexityof the problem when they are represented as entities. Business processesdefine the possible paths along which business work can be performed, as wellas the actual business work itself. The type of structured approach used inbusiness process analysis produces specifications that make the possiblepaths readily understandable while obscuring the policies that drive thosechoices. In the cases of business entities and business processes, changes toeither are much more visible than would be a rule-driven description of thesame change, because the rules implied within each are implicit within thesepatterns.

Adding business rules to the mix has a dramatic impact on those practices. Itallows the added ability to formalize the more fluid business judgments that arecentral to business agility. To understand the full extent of this impact, it'simportant to understand the limitations of current techniques.


The Importance of Capturing Decisions in Business EngineeringAs it’s practiced today, most business engineering begins with and remainsfocused on business process analysis. The emphasis on business processesis driven by a focus on metrics that capture the operational characteristics ofthe process through measures such as: cost per unit of work performed,process execution time, and defect rates. There is nothing wrong with thesemetrics per se, but the operational excellence they focus on isn’t the wholestory. What’s missing is an approach to systematically examine and manage allthe decisions that underlie a process’s execution and to control the rates offlows through the various paths defined by the business processes. You canthink of these decisions as the valves and gates in a factory that control thework flowing down each path and at which rates. More simply we can say thatbusiness rules implement the decisions that support the business policieswhich guide the business work under specified circumstances.

In most current approaches to capturing business rules, the rules are relegatedto details captured about decision points within a business process. Forexample, in a fulfillment process we might capture a decision point thatdetermines that all the items in an order must be in inventory before any itemsare pulled for an order. But if we stop for a moment and examine this decision,we can see that what we are really asking for is a decision about the orderwhich, if it is made, will allow the fulfillment process to continue down the paththat leads to pulling items ordered from inventory. That is, there is a decision inthe business process about orders that examines a judgment about the orderand which has its own (implied) definition and existence and which is thencalled into play at appropriate points in relevant processes. That judgment isan important piece of our business engineering that is seldom explicitlyacknowledged. The lack of formalization of business judgments means thatwhen a business domain expert goes to examine how a policy was engineeredinto the business, it is difficult to tell where to begin. After all, policies often applyacross many business processes. So how would one locate all the businessprocesses where the policy is implemented?

Capturing and managing business judgments is the area that exposes thegreatest weaknesses in our current approach to business engineering anddelivers perhaps the greatest opportunity for business improvement. Mostapproaches simply fail to acknowledge a formal way of capturing businessjudgments and relating them to business processes, business entities,business metrics, and eventually to underlying business policies and rules.How can this be? Process analysis is typically focused on conceptual design ofprocesses rather than operational design. That means that organizations donot expect that their business process specifications are in fact the exact


specifications that are being executed. This type of approach works tolerablywell if the focus of the exercise is on engineering the individual activities beingdone within the business process to minimize the number of them, arrangetheir order to minimize bottlenecks, reduce the cost of executing them, andsupport monitoring them for quality. Basically, if the intent is to engineer asolution that is effective in handling thehigh-volume-straight-through-processing type of interactions, then this type ofapproach to business engineering can be very effective. However, if the intentis to deal with the much smaller percentage of cases that follow some kind ofexception path, then this type of approach is woefully inadequate.

But in the current business environment, where visibility into the internals of anorganization’s processes is a key competitive advantage, can we afford to onlyengineer for the normal cases? After all, the exception paths are the paths thatallow an organization to adapt to customers’ needs and that deserve specialbusiness attention. Even more important, exception paths provideopportunities to interact with customers in a situation where they can have anunexpected positive experience—a situation which is the key to achievingcustomer loyalty. Something is missing from our traditional business processanalysis approaches, that prevents our business analysis from being able tohandle these exception paths and thereby become the real operationaldefinition of how these business processes behave. Once again, the answer isbusiness rules or more properly business decisioning.

Business DecisioningBusiness decisioning is the discipline of taking business information andapplying particular tactics to it, so that new information is produced thatembodies some kind of human judgment. There are a variety of ways of doingthis, including mathematical approaches such as optimization and constraintsolving for dealing with situations calling for finding a “best solution,” as well asfuzzy logic and other kinds of probabilistic reasoning focusing on finding themost likely solution. But most business reasoning is of a simpler kind, whichinvolves reaching a conclusion, even if the decision is not so straight-forward.This is the kind of reasoning that is the focus of the business rules movement.The recognition of this is what is behind the recent emergence of businessrules as a distinct aspect of business engineering in its own right.

The emergence of decisioning and business rules as a formalism, then, is anatural business maturity progression. That is, once the business defines andmanages the “normal paths” through critical business processes, the nextevolutionary step is to seek to leverage the exception paths for businessadvantage.


Incorporating Business Level Specifications with Automation SpecificationsWe talked at the beginning about the importance of organizations seeingautomation solution design as an integral part of product design. To achievethis, we have to be able to incorporate a business level specification within theautomation specifications. In particular, this means we need to stop creatingbusiness process and business entity models that have no correspondingelement in the delivered automation solution. While other industries havestruggled with this problem, many of them have a physical metaphor which theycan reproduce in their automation solutions to act as this bridge. This allowsbusiness domain experts to continue to write specifications in terms of thosephysical elements, even though they may no longer exist.

In the service industries, things are a little bit different because existingbusiness work and existing business specifications have seldom been explicitlyformulated into an executable framework. Domain experts don’t have aphysical metaphor to use as the de facto way of structuring how their businessneeds are expressed in the automation solution. That means that we have toconstruct a metaphor for our business experts, as well as adapt it for direct useto configure the operation of our automation solutions. Because we can’texpect to succeed by creating a completely foreign metaphor, we arecompelled to take existing concepts that these business experts are familiarwith and weave them into a coherent executable framework. This frameworkneeds to be able to represent a specification that could be executed as it isdocumented, but which also could be mapped onto a more sophisticatedimplementation. We can think of this last step as designing a factory toefficiently produce our product.

To understand this, let’s take a traffic light system as an example. Originallythese systems were complex to configure. Traffic lights had physical switchesin them that controlled the sequencing of lights and the intervals between them.Timers were used to determine when to send a signal to a light to initiate thetransition to a stop or go state. Gradually the physical location and evenexistence of these elements became less and less relevant, because complextraffic management systems created abstractions for these components insoftware. But for the individuals configuring these systems, the establishedconcepts of switches and timers were how they still conceptualized what theywere doing. Because of this, traffic management systems today provideconcepts that are familiar to those experts who configure these systems. Bymaking it possible to configure these systems using a specification written inthe domain experts' own terms, these systems have made it possible forcompletely new traffic management solutions to be designed entirely by thetraffic management experts. In addition, the new automated traffic


management systems made it possible for the traffic management experts todesign much more complex systems that they could within the limitations of theold physical component systems.

In the area of business engineering, there are also existing concepts that arepart of the vernacular of business engineering. We can adopt these into ourvocabulary of concepts to form the basis for how business domain experts cango about specifying business solutions. These concepts include: businessprocesses, business entities, business rules, and business events. But tyingthese together into an executable specification requires relating them in a waythat is not carried out by most practitioners today.

At first blush, it seems that current practices for defining concepts and theirrelationships is an area that is already in line with our needs. Existing modelingtechniques for enterprise conceptual data modeling and for enterprisebusiness entity models provide a defined way for us to identify concepts, therelationships among them, and characteristics of those concepts. However,traditional business analytic techniques don’t begin with the premise that a setof business-defined concepts will become the basis for defining the executingbusiness logic of an automatable specification. This means that today’sbusiness analytic techniques fail to recognize that the IT implementation ofknowledge is essential to a business understanding of the knowledge. But,ironically, the IT implementation of that knowledge is exactly theimplementation that the business is truly running with. While the ITimplementation is polluted with technical considerations that the business doesnot want or need to be exposed to, the lack of a clear separation between ITengineering concepts and business concepts means that we don’t have anabstraction available that represents the real knowledge model the businessoperates against with the implementation details removed. It is this separationof business and engineering concepts that John Zachman addresses in hisFramework of Enterprise Information Architecture (See Chapter 3 from JohnZachman for insights into the Zachman Framework).

The Gap in Business Entities TodayConsider the customer entity. Organizations usually have multiple systems inwhich the concept of a customer is represented. These systems range fromCRM and ERP systems to in-house product support systems. What do we dowhen we have multiple customer concepts across these systems? Typically,we have one of two choices: abstract a single concept of customer for businessspecification purposes, or deal with them as unique concepts, unrelated toeach other. What we don’t typically do is create a series of abstract conceptsthat support the way the business actually uses the multiple customer


concepts. Let’s say that we have what we believe is the same customer, in bothan ERP solution and an in-house marketing system. In fact, we might find that99% of the customer instances are virtually identical. Are these two differentsystems supporting a single concept? If so, this is a technical issue, not abusiness issue. But what if the reason that some of the marketing entries aredifferent is because the marketing department has found that for some specificcustomers, using certain internal organizational names is a much moreeffective way of getting material routed to the right people. At this point, we’veidentified two related but different concepts. By leaving this gap, we build ashaky foundation on top of which to build our business engineeringspecification.

The Gap in Business Processes TodayOur current practices for defining business processes also have similarproblems. In fact, some of the problems in this area are a direct result of theissues we have just discussed in the business entity engineering area. After all,business process definitions exist primarily to show the paths along whichbusiness work can be performed. The business work that is being performedon these paths is manipulation of business entities. So if our existing businessentity model is not an accurate representation of the entities that we haveavailable to work on, then it becomes impossible for us to accurately define thework. But additional issues exist that are particular to the business processanalysis area itself. In particular, business processes are frequently modeled aslarge monolithic definitions that, when compared to how work is actually donewithin an organization, turn out to be only approximations of what is reallyhappening. This gap means that the definitions being developed aren’t reallyspecifications that could be used to actually configure the process definitionsthat an organization is run by.

In the case of business processes, the reason for this gap is a bit morecomplex. One of the primary areas where business process definitions divergefrom reality is when dealing with exceptions; in this case, exceptional flows.While it’s easy to think conceptually of processes as being a set of sequentialactions that follow defined branches based upon control points, this is typicallya simplification of what really happens within organizations. The key fallacy isthat the way that an activity within a process triggers the activity that follows itis no more complex than the completion of that first activity. This is particularlytrue when the activities that we’re talking about involve some kind of humanintervention. For example, let’s say we document an approval process ashaving a “Submit Request” activity followed by a “Determine Disposition”activity. Let’s assume that the “Determine Disposition” activity involves aperson examining the submitted request and making a judgment about whether


or not to approve it. Does the person making this judgment actually start doingthis as soon as the request is submitted? Obviously, this wouldn’t be anaccurate representation of how things really happen.

Alternatively, we could claim that “Determine Disposition” is really anabstraction for a work queue. But this approach is also problematic. If we treatthis activity as a work queue, then we need to define a related process thatdescribes how approval is granted. We don’t want to include this process in ourgeneral business process because we are really agnostic about how thishappens. And, in fact, it’s quite possible that there are multiple approvalprocesses that exist (e.g. supervisor and operations level approval processes),any one of which is sufficient to generate the approval within a core process wemight call “Handle Requests.” This is in fact a very typical process patternmade use of by organizations. What we are seeing here is an example of afamily of interrelated processes. Each of these processes triggers somethingin the other process, but they aren’t part of each other. For example, thesupervisor approval process might both allow the “Handle Request” process toproceed and cause the process for getting operational approval to withdraw thework from that role’s work queue, since the supervisor has already approved it.

Beyond these oversimplifications of process flows, there is another majorlimitation to current business process analysis techniques. This other limitationinvolves the process- centric nature of this kind of work. While process-centricanalysis is a powerful technique for bringing together all the interested partiesand making sure they align to the same goals, it does obscure the role ofbusiness policy. Take, for example, the decision that all purchases over $1,000must be pre-approved by a supervisor-level position. Because there are manydifferent business processes that support creating a purchase request, it wouldbe very difficult to change this policy and have assurance that the revised policywould be applied to all relevant processes. That’s because, without a BusinessRules Approach, there is no traceability from the policy to its implementationacross the business enterprise. In a purely process-centric point of view, thereisn’t the concept of a judgment which has an existence independent of anyparticular process. So when we go to change what appears to be a singlepolicy, we instead have to locate and modify a series of control points withinany number of business processes.


The Business Rule RevolutionThe weaknesses that we’ve identified in both business entity and businessprocess specification are issues that have existed for some time. This hasbeen possible because there has not been a strong movement towards anintegrated business engineering approach that provides a metaphor forbusiness experts and that can also be used to configure the automatedsolution. This is where the Business Rule Revolution comes into play.

The Business Rule Revolution is driven by forces relevant to both businessentity and business process analysis. However, the focus from the businessrules side is not only on the conceptual understanding of the businessspecification. Rather, business rules are being driven by the realization oforganizations that one of the major impediments to change is that theirbusiness domain experts can’t directly control the business operations bymanaging and evolving its policies and rules appropriately. In other words, thebusiness rules movement is catalyzing the desire of organizations to movetowards a business engineering approach where the business specificationsare no longer requirements that support the development of IT design. Rather,they are the business configuration that is expected to be loaded into the ITsolution. Business rules’ interdependency with both business entities andbusiness processes means that, for rules to be directly maintained by businessdomain experts, the entire supporting foundation upon which they are built orwith which they interact must also be executionally complete.

One of the key ways in which business rules cause a business specification tobe an executionally complete specification is via their interaction with businessentities and business processes. Business rules need a vocabulary to allow thecreators of those rules to express the rules in both a language that is natural tothem as well as one that has rigorous semantics. That means that thevocabulary for rules is derived from the business entity model, business ruleglossary model, or fact model. This vocabulary can also be derived from thebusiness rules themselves, because business rules define new pieces ofknowledge that are beyond what is captured by business entity models. Itdoesn’t take much of a leap to see that if business rules are maintained directlyby business domain experts, and that business rules are to be directlyexecutable, then the new kind of business model (comprised of businessprocesses, business rules, and a model of business terms) must itself be anaccurate representation of the available business concepts.

Business rules play a major role in helping drive business processspecifications toward a level of formality that can produce executionallycomplete specifications. A business rules approach can also help addressanother weakness of most business process specifications, the role of


business events. Business events have a number of different sources.External sources are common and are standardized in some industries throughstandards such as ACORD and SWIFT. But not all events are standardized.Some events are specific to an organization’s design of their internal processesand are direct outcomes of these business process designs. We saw anexample of this in our earlier discussion of the “Handle Request” process andhow it was related to the “Operational Approval” and “Supervisory Approval”process via business events. Yet another way that business events can begenerated is using business rules.

Business rules can be used to define that a business situation has occurred. Acommon example is the use of a business rule to detect that a business policyhas been violated. For example, let’s say that an organization has a policy thatall orders over $1,000,000 should be assigned to a dedicated sales agent. Thisis something that might be done as part of taking the order, but if this processinvolves a manual decision about staffing, it may not always be able to be doneautomatically. If we define a rule that captures this condition, we can detect thatthe situation “Large Order Placed without Assigned Sales Agent” has occurred.We can indicate to business processes that this has occurred by making it abusiness event. By making it a business event we decouple the businessprocesses from these policy enforcement opportunities. This happens becausethe rules don’t need to know who cares about the event. The rules simplydetermine the conditions under which a specific situation of business interestoccurs. On the business process side, the “Assign Dedicated Sales Agent”process doesn’t know the rules that determine why the event occurs. Theprocess simply knows that appropriate conditions were concluded to be true,hence, the appropriate process should be initiated.

But it’s also possible that we have other processes that potentially areinterested in this event, such as a marketing process (because customersplacing an initial large order are potentially growth customers) or a “SalesForce Allocation” process (needing to respond to the more general need torevaluate the allocation of individuals to accounts). By separating out thedetection of the situation into rules that determine an event, we allow changesto business processes to occur much more rapidly, because the events arebusiness specification elements whose definition is not specific to anyparticular business process.


Back to Business DecisionsBusiness rules have an even more central role to play in creating morerigorous, but agile, business engineering specifications. That role is in defininghow business judgments support the creation of decisions. These judgmentsare the missing element of most business engineering efforts. Very much likebusiness events, business judgments have a separate existence apart from thecontext of any particular business process. In fact, much of the vocabulary thatwe use when we discuss business engineering is centered on these businessjudgments. For example, we talk about orders being approved for a premiumcustomer if their account is in good standing. In this case, someone being apremium customer and having an account in good standing may be consideredtwo business judgments, each of which is determined by its own set ofunderlying detailed business rules. Why are they business judgments?Because these are stand-alone business concepts that are directlymanipulated by business domain experts. This makes them essential tobecome part of the metaphor we are building for these experts to manipulate.In addition, by giving this business judgment existence independent of anyparticular business process we allow for the possibility that there may be manyprocesses that care about whether a customer has an account in goodstanding. Typical examples would be processes in marketing, sales, and billing.By identifying these processes as all using the same business judgment, weenable the business to make policy-related changes to these businessjudgments without impacting the business processes. After all, the businessprocesses don’t really need to know why an account is in good standing. Allthey care about is that the appropriate decision controls the paths chosen in aprocess. So if a business decides to change the policies in a way that doesn’tchange the business work being done then all that needs to be done is tochange the rules that support this business judgment, and all processes thatrefer to this judgment will immediately reflect this change. For example, if thecompany wants to increase the percentage of orders automatically approvedfor premium customers in good standing, tweaking of the rules that underly theapproval judgement will be all that is required.

This idea of identifying business judgments has a much broader impact than itinitially appears. After all, traditionally business judgments have beenexamined in the past strictly in terms of how they control business processesand therefore they usually don’t have a high degree of reuse across multiplebusiness processes. But business judgments typically aren’t monolithic. Mostbusiness judgments are built upon a series of intermediate businessjudgments. So in our previous example, it is quite possible that our judgmentsthat a customer is a premium customer is built out of a set of intermediatejudgments such as: the customer has a valid volume purchase contract inplace, the customer bought more than $500,000 in goods or services in the


past year, or because a manager has directly authorized that the customer willget premium customer benefits. Any one of these could be sufficient to supportthe higher level business judgment that a customer is a premium customer.However, these same intermediate judgments may be used to build up othertop-level business judgments that business processes will examine. Forexample, the judgment that a customer has a valid volume purchasing contractin place could play a role in billing because this volume purchasing agreementmay require a yearly contract renewal to be maintained, as well as a periodcredit evaluation. These higher-level decisions probably aren’t of interest to thesales process though even though they probably are to the accountmanagement processes.

In fact what we typically find is that most business specifications contain a lotof information about business judgments, without a formal way of fitting thejudgments into the business specification process. By capturing the businessjudgments as legitimate elements of the business specification and usingbusiness rules to round out the judgments, we get a highly integrated businessspecification. The business processes now have the judgments and eventsavailable to them that they need to control their flow, because pure businessprocesses are about sequence, not about decisioning logic. The rulesunderlying the business judgments make use of the vocabulary derived fromthe entity model (or rule-related vocabulary model). And the business eventsand business judgments themselves expand the vocabulary to allow thebusiness to refer to these derived concepts in a structured way that isolates theimpact of changes to reflect natural business boundaries. This last idea ispossibly the most important. By making business decisions and eventscorrespond to real-world business concepts, the impact of making changes tothe business specification should correspond to the business domain experts’own expectations of the impact, because the concepts directly correspond totheir own way of thinking about the problem.


SummaryThe integrated business specification approach outlined here runs counter tomany existing organizational boundaries in several ways.

1. It focuses on empowering business experts to be able to create newbusiness products directly in many cases, without requiring muchinvolvement of IT engineering. The approach does this by shifting theparadigm from one where the business develops requirements to betranslated into operational specifications into one where IT engineeringdelivers a framework that presents the business concepts, decisions,and supporting rule pieces (conditions and conclusions) as realelements that a business specification can work with.

2. Direct support for business concepts within the implementationframework allows a business specification to become a configurationthat is loaded into the solution. This gives the business direct control ofthe operational behavior of the solution.

3. To achieve this, the business specifications must be executionallycomplete. And in order to achieve that, we need more rigor in the waywe perform business entity and business process specification andintegration with the Business Rules Approach.

4. None of this is to diminish the role of IT engineering. A businessengineering approach allows IT resources to focus on IT engineeringrather than on business specification translation. Giving business directcontrol over the operational specifications is a paradigm shift that is themost promising path to increasing the rate of innovation in a market thatincreasingly is innovation driven.


c h a p t e r


6 A BPM-Driven Approach to Business Rules

Larry Ward and Jordan Masanga

About OPERSThe Oregon Public Employee Retirement System (OPERS) began its arduousbut never-ending trip using the Business Rules Approach in 1999 under a largeIT-driven reengineering project. With minimum in-house business rulesknowledge, but an absolute directive, we jumped on the wagon—and it seemedas if it was bouncing and careening through the ruts being carved in the OregonTrail.

OPERS's first steps were to identify staff roles and create a business rulesdevelopment infrastructure, in which business rules were identified andorganized for development within systems. With insufficient budget and time,we had to base business rule development on a low-technology/low-costapproach.

During the next three years, for every three steps forward, we seemed to taketwo steps backward. Due to pressures of a highly visible reengineering project,an active state legislature, and critical court decisions, OPERS executives wereunable to dedicate consistent support to the development of business rules.The resulting “priority of the week” directly impacted staff ability to developbusiness rules in the optimum manner and timeframe. Fortunately, OPERS hada small, but determined, business rules team that recognized both theimportance of, and need for, a single repository for authoring and managingbusiness rules and a business process management plan. The remainder ofthis chapter covers:

• Background• Business drivers for OPERS’s business rules• Establishing a business rules group and related tools

Page 76 Chapter 6: A BPM-Driven Approach to Business Rules

• IT-driven approach versus business and BPM-driven approach• The business-driven project• Summary

BackgroundOPERS provides state, local, and higher education agencies with multiplepension, deferred compensation, and retiree health insurance programs. Theoriginal plan is a defined benefit plan; the new plan includes both a definedbenefit plan and a defined contribution plan. Additionally, we administer adeferred compensation plan, retiree health insurance, and long-term careinsurance.

Business Drivers for OPERS’s Business RulesThere are many business drivers for OPERS to justify using the BusinessRules Approach. These drivers include regulatory requirements, litigationconcerns, audit concerns, and the need for changes in rules.

Let’s start with federal and state statutes, regulations, administrative rules, andcase law from court rulings. The primary business driver is the statutoryrequirement that the OPERS retirement plans continue to meet IRSrequirements to be qualified plans, while a secondary driver is customersupport to the members, retirees, and employers who participate in OPERSplans.

Most OPERS business drivers are related to our retirement plans' beingcontained in and based upon state statutes, with detailed administrative rulesthat correspond to the statutes. The Oregon Legislature is in session everyother two years for a nine-month session. Historically, OPERS is affected bynew legislation that occurs during these sessions. These changes impactbusiness rules and processes that may or may not have been fullyimplemented before the latest legislative session starts or ends.

Litigation is another major business driver. Court rulings for the last fifteenyears have driven major changes to how OPERS plans were administered, andin 2003 they drove the legislative creation of an adjunct second plan. Courtrulings always create changes to business rules and processes—someretroactively.


Audits are a business driver. OPERS activities are routinely audited by externalstate regulatory agencies and functions. Audit findings have the potential tochange business practices, business requirements, and business rules and toimpact current and planned IT projects.

Changes occur rapidly at OPERS and have cascading impact on theenterprise. Agility is key to responding to ever-changing business demands,necessitating business-driven projects with centralized management ofbusiness and system requirements. Therefore, taking control of requirements,including business rules, stakeholder needs, use cases, requirementspecifications, and operational processes and procedures was our first priority.However, due to budgetary constraints, a commercial business rules enginewas not an option. Instead, OPERS extended existing use of the IBM RationalRequisitePro® requirements and use case management tool to developseparate databases within a single repository. As a result, traceability betweenmultiple requirement types allows OPERS to manage business change withgreater agility and quality.

Establishing a Business Rules Group and Related ToolsThe OPERS Quality Assurance Manager is organizationally aligned under theInformation Systems Division and has the role of technology development andquality assurance (QA). The responsibility for developing business rules wasoriginally coordinated by QA (1999—2004), but was realigned to a businessunit in 2005. The Business Process Management (BPM) methodology iscurrently championed by QA, but will also evolve to a business unit responsiblefor processes.

The Rational Unified Process (RUP) methodology has been the basis for ourIT projects since 1998. The RUP methodology has four phases: Inception,Elaboration, Construction, and Transition. Using RUP, OPERS appliesincremental development between the phases. IBM Rational RequisitePro® isthe IT tool set the agency has available for development projects. We selectedit as the database and repository for business rule requirements.

Senior staff changes, cancellation of the reengineering project, and theresulting scramble to keep using the processes and tools started in thecancelled reengineering project eventually led us to research the BusinessProcess Management (BPM) approach/methodology. Determining howOPERS could implement this shift/change in development methods andbusiness organizational approach became a major question and discussion.


Key QA staff read Howard Smith and Peter Fingar's Business ProcessManagement (BPM): The Third Wave and Andrew Spanyi's Business ProcessManagement is a Team Sport: Play it to Win!, then brainstormed ways to usethis approach and methodology, initially for IT projects and eventually for otheractivities and workload within the agency.

Legislative approval of a major systems conversion project for OPERS in 2004provided a vehicle that let us begin the change process from IT-driven tobusiness-driven projects and contracts. This major conversion project is anaddition to a project that is implementing a legislatively dictated new retirementplan that is adjunct to, but not totally separate from, the existing retirement plan.The system architecture for the new program uses a new server-based tool set.

IT-Driven Approach versus Business and BPM-Driven ApproachA small team of business and IT managers applied lessons learned in theprevious project to the contract requirements for the conversion project. Thecontract requirements identified the use of a Business Process Management(BPM) development methodology. The initial project implementing a new planstructure required renewed executive sponsorship of business rules, whichre-energized our critical business rule development process. Both projectsrequired business rules to be available early in the development process andtraceable to the various business and development requirements. Movingbusiness rule development and maintenance to the first RUP phase ofInception allowed increased quality, mitigation of risks, and accurate resultswhen the system developers started doing their development work during theRUP Elaboration and Construction phases. Another benefit would be thelikelihood that the project schedule could be maintained, due to a reducedquantity of rework resulting from inaccurate or unidentified requirements.

We have found that the classic IT-driven approach is applied to individual ITprojects. It evolves from technical staff guiding a process of fact-finding frommeetings and notes, and proceeds to requirement and business ruledevelopment in the later stages of RUP Elaboration and Construction Phases.Business rules and information captured in one project may or may not beshared or integrated with other or future projects.

The business and BPM-driven approach we use leverages industrybest-practice standards. This method strongly supports structured approachesin business rules, requirements, design, implementation, and testing.


Figure 8 illustrates our view and comparison of the development approachesfrom a business user and developer viewpoint.

Figure 8: Project Approach Comparisons

Remember the bouncing and careening through the ruts worn in the OregonTrail and the “priority of the week” issues? Well, the wagons are still sportingthe unsprung axels and no springs for the seats! However, in applyingBPM-driven methodology, we have been working hard to design a system ofshock absorbers, springs, and a wagon more suited to the travelers' (businessusers) needs than what the builders (IT developers) thought was needed for thewagon.


Lean and agile BPM is having positive effects on the latest OPERS systemconversion project. Business users are directly involved in the businessrequirements identification and verification much earlier in the developmentprocess. The end goals are to increase business and systems agility andcreate technical solutions to support business processes. Examples are:business process models; business rules; business process metrics; businessprocedures; stakeholder needs; supplemental specifications; use cases, usecase specifications, and use case models. Figure 9 compares the differencesin gathering requirements between a typical IT-driven approach project and abusiness and BPM-driven project.

Figure 9: Project Approach Changes in Requirements Gathering


When we analyzed and compared the two approaches, it became evident thatthere are several distinct key differences. Figure 10 identifies these keydifferences as an overlay to the Figure 9 comparison of the two approaches.

Figure 10: Process Approach Structure Comparison

Our analysis found the IT-driven fact-finding methodology is based on a lessstructured, less formal development approach. Generally, there are fewstandards used in discovering business expectations. Analysis of business andQA experiences revealed that it can be hard to tell when IT-driven projects arereally complete. The processes of and artifacts resulting from developmentactivity are difficult for business users or QA to review or verify, because theretend to be no clearly defined requirements or measurement points. Businessrules and requirements are typically developed later in the IT-driven approach.

Analysis of the business and BPM-driven methodology convinced us that it isthe model to use. It is based on a more structured/formal approach thatleverages industry best-practice standards, to enable better review processesand tools for business users and QA. The software tools available for BPM aidverification and completeness. BPM strongly supports structured approachesin business rules, requirements, design, implementation, and testing. The toolsalso provide traceability, linkage of models, use cases, business rules,requirements, and test cases. BPM methodology also provides long-termusefulness in training, process improvement, and risk management.


Figure 11 illustrates the difference in workload distribution of businessinvolvement between the two project approaches by overlaying the IT-drivenapproach with the business and BPM-driven approach.

Figure 11: Project Approach Comparison

In Figure 11, the IT-driven approach resembles a whale. It shows that criticallyimportant business user involvement occurs much later in the project andusually poses a much greater risk to the project than the business andBPM-driven approach, due to poorly defined requirements and business rules.Design changes in the later stages/phases tend to affect testing activities andthe project schedule, and to be more costly than those in earlier stages/phases.

The business and BPM-driven approach resembles a two-hump camel.Figure 11 depicts much earlier business user involvement in a project. As aresult, requirements are much better defined and there are fewer late designchanges during testing and implementation, less rework, and fewer defects.Early business involvement also allows for developing more accurate businessprocess models, business rules, and detailed use cases that create betterrequirements input. Early involvement of system testers with this process andthe business users allows for more accurate testing results.


Our business processes have changed due to this migration from IT-driven toBPM-driven development methods. Figure 12 identifies the major differences.

Figure 12: Business Process Changes

Old Method Process Driven

• IT Driven• Modeling for system implementation• Few metrics designed into system• Stakeholder needs captured but not traced• System & Organization in functional silos• Manual BR database update

• Business Driven• Modeling for process improvement• Metrics built-into

system design• Stakeholder needs captured and traced• Processes modeled

across functions in end-to-end process across organization

• Automated BR database update


The Business-Driven ProjectOur Business Rules Project began in 1999. The business-driven project beganin early 2005. We were constrained to use our existing software tools. Ourobjectives in using Rational RequisitePro® were to develop process, businessrule, and requirement database repositories, and to associate those databases(traceability) to maintain versioned business rule and process information.Business rules are captured in RequisitePro, while the Microsoft Worddocuments are maintained and versioned in a Rational ClearCase® repository.RequisitePro is also used to capture elements, stakeholder needs, use cases,and requirements. Figure 13 shows the resulting matrix of traceabilitiesbetween the different databases.

Figure 13: RequisitePro® Requirement Type Traceability Matrix


The on-going and evolving Business Rules Project has faced many issues:management challenges, database maintenance process, knowledge of toolcapabilities, business rule availability to end-users, too much work and too littletime, and both major and minor development projects requiring accurate andrapid development of rules. Through all of these, we gained the necessaryexpertise, and both the business rule process and QA acceptance test processhave been continually improved. Figure 14 depicts our current RequisitePro®databases.

Figure 14: RequisitePro® Database Repositories Diagram

The manual maintenance of the business rule portion of the databases andrepositories was very labor-intensive. OPERS had to find a more viablemaintenance process and align process responsibilities to automate thedatabase maintenance process. This resulted in a project we titled


RequisitePro® Database Repository Maintenance Process Improvement. Toachieve the process improvement goal, we developed a front-end program andprocess that automated the manual updates to multiple business rulesdatabase repositories, named Business Rules Transaction Application (BRTA).The BRTA tool incorporates a business rule process workflow fromidentification through approval and QA reviews to automated updates to theappropriate repositories. The final piece of the workflow makes the currentapproved version of business rules available for use by business users.

The implementation of this tool allowed us to consolidate business ruleresponsibilities from IT (QA) systems staff to the primary business users afterappropriate training. The primary user is our Business Rules Writing Team. QAis a secondary user. The BRTA tool allows independent QA reviews ofbusiness rules. This process and tool ensures multiple databases andrepositories agree at any point in time. Figure 15 shows the success of thisprocess improvement project.

Figure 15: RequisitePro® Database Repository Maintenance Process Improvements

Activity Manual Process Automated Process

QA Business Rule Documents 3 to 20 hours weekly 1 to 2 hours weekly

Copy Data into Requisite Pro® 5 to 20 hours weekly 0

Copy Business Rule Word Documents to ClearCase®

3 to 10 hours weekly 0

Update Business Rulessite on Intranet

10 to 30 weekly 0

Approved Rules Available to Users 2 to 3 weeks 3 to 5 days

Databases Concurrent & Accurate Low to Medium High


SummaryDevelopment of business rules and the repository affected how OPERSdevelops and maintains software. Application of BPM has allowed us toimplement a business-driven project process. OPERS projects are nowcentered on early development of: business process models; inputs/outputs,steps, and workflows; stakeholder needs; requirements; and identifying rolesand responsibilities. Developing business rules that support business processmodels has been shifted to the earliest stage/phase of a project. We can nowcreate a business and system requirements traceability matrix. This allowsOPERS to drive requirements through implementation and changemanagement. The QA and User Acceptance test plans and testing results aremore accurate and responsive to any late changes due to an early identificationof requirements and business rules.

What did we learn about business rules and BPM as we traveled along thisbumpy and very heavily-rutted road?

• A dedicated team of business users with experience and industryknowledge is essential.

• Unwavering executive support is absolutely necessary.• A Business Rules Engine (BRE) would have made much of the effort more

efficient.• A BRE would allow simulation of proposed changes to better identify

issues and risks.• Business users and IT staff need a business rules repository.• Business cases must be planned and developed for the toolsets required.• Contractors should be required to use BRE for all systems development.• BPM and associated toolsets is a very good methodology to use in today’s

marketplace• While a toolset may eventually be made to work, it may be inefficient.

What does the future potentially hold for us as we continue our journey towardfurther efficiency, responsiveness, and maintainable automated support of thebusiness users needs through business rules and business processmanagement? In no specific order:

• Elevate QA to be an organizationally independent direct report to theExecutive Director or Deputy Director.

• Expand efforts for continuous process improvement throughout theagency.

• Implement a Business Process Management System (BPMS) toolset.


• Implement a BRE that allows rule simulation.• Allow read-only BRE access to secure OPERS partners, such as

legislative analysts or employers, to assess impact or potential impacts ofrule changes on the system or their local systems workload.

• Transition business rules from Rational RequisitePro® to a BPMS with aBRE component.

• Executive support for a Business Process Office organization directreport to the Deputy Director.

• Develop knowledgeable (experienced), trained, and dedicated staff asBusiness Process Owners (not super-subject matter experts).

• Implement the FileNet automated workflow toolset to enhance andprovide controls, tracking, and metrics for the process of moving fromend-to-end “things” through a process.

• Implement an automated workflow to route business rules through thedevelopment and approval process, to further save staff time.

Suggested References for the Reader to Explore Further:

• BPM White Papers and Round Tables. http://www.BPMInstitute.org.• Smith, Howard, and Peter Fingar. Business Process Management (BPM):

The Third Wave. (Tampa: Meghan-Kiffer Press), 2003.• Spanyi, Andrew. Business Process Management is a Team Sport: Play it

to Win! (Tampa: Anclote Press), 2003.

http://www.BPMInstitute.org

c h a p t e r


7 Modeling the Business: Improving Process Models through Business Rules

Art Moore and Michael Beck

IntroductionBusiness rules, as a distinct focus of interest in the business systems model,had humble beginnings. In the 1980’s business rules became a subject ofdiscussion in the data management community. To many at that time and inthat context, the phrase “business rules” simply meant the referential integrityrules to be applied to data. It soon expanded to the broader context of rulesabout what were valid states of data, such as “All preferred customers musthave an account balance of at least $100,000.” In fact, today some rulesoftware takes this “data-centric” approach to defining and managing rules.

As these technologies have matured along with those originating out of artificialintelligence roots, and as the demand for system agility has continued to grow,business rules have begun to assume a more prominent role in businesssystems architecture and systems development. The basic idea is thatbusiness rules should be specified and implemented so as to make themreadily accessible and independently changeable as needed, in a context thatis as business-friendly as possible. Interesting issues of governance,consistency and traceability start to surface when embarking on this path, butthe fundamental concept is a compelling one.

In conceiving and designing business systems, then, when do you begin tothink about business rules? How exactly do they integrate with the othercomponent parts of a business system specification? Fairly neat and satisfyingarguments have been made for independent treatment of business rulesthroughout the systems life cycle, from early visioning through development.While drawing on such theory, we have, through research and a series ofprojects over the last several years, sought to identify what works in actualpractice. These projects looked at real world business problems while also

Page 90 Chapter 7: Modeling the Business: Improving Process Models through Business Rules

examining how best to integrate business rules specification into the systemlife cycle. A major objective was to improve the clarity and completeness ofdelivered business specifications through formal treatment of business rules,but to do so as efficiently as possible, without adding prohibitive cost and time.

Not surprisingly, our experience shows that being successful at separating andmanaging business rules requires that we understand them in context.Business rule specification does not happen in isolation but as part of acomplete business model, integrated with the other business system viewssuch as process, data, organization and location. What is perhaps surprisingis that the impact of business rules on these other model views and on theirquality may be as significant as the achievement of clearly specified businessrules. The subject of this chapter is how business rules are found to integratewith the rest of the business model, particularly process, data, testing andrequirements statements, and the impact on these areas. Therefore, thischapter covers:

• The impact of business rules on the process model• The impact of business rules on the data model• Business rules and business system requirements• Business rules and testing• Summary

The Impact of Business Rules on the Process ModelPossibly the most common perspective today among systems practitioners isthat attention to rules comes at the end of business analysis, while moving intodesign and development. This viewpoint more or less reflects traditionalpractice. Business analysts are most familiar with process modeling of oneform or another. For them, and for many business stakeholders as well, this isthe most natural way to visualize and communicate about what the business“is.” Thus business rules are viewed as simply an adjunct or further detailingof process specifications. As it turns out, this approach is more likely to carryforward arbitrary procedural components of both the current business processand rules, repeating them inappropriately in the future state.

Business rules should expose the basic business intent in a way that is asindependent of the procedural mechanics of implementation as possible. Wewant to state that any customer having an account balance greater than$10,000 is a preferred customer. We would not, to give an extreme example,want the “rule” to be stated as “Look on the Account Profile Sheet. If the


amount in box 6 is greater than $10,000, then put a check in box 10.” Thissimple point becomes significant in considering how process and rule analysisshould interact.

Consider the following hypothetical example:

A company wants to institute a process for reviewing claims automatically,to lower overhead cost by streamlining processing and minimizing thenumber of investigations that need to be done. They also want to be ableto review this process and the rules around it to see if results can beimproved, see what’s working and what’s not. Starting with businessprocess modeling, they came up with the model in Figure 16.

Figure 16: Business Process Model for Automated Claim Evaluation

This initial modeling of the envisioned process, while perhaps not toodifficult, is also not the simplest in the world to follow; but let’s walkthrough it. Basically, after authenticating the claim, they estimate the costof the claim. If the estimated cost is high enough, then investigation byan agent is the only option. Below a certain point, the plan is to do someanalysis-based evaluation. This begins by estimating the validity of theclaim, based on a number of factors. If the probability of the claim beingvalid is above a certain threshold, they will pay it without further analysis.Below that level, however, they will take into account the calculatedcustomer value (primarily a factor of claim history, modified by totalrevenue from client). If customer value is above a certain point, they willagain simply pay the claim, provided it is above a certain estimatedvalidity threshold. Otherwise the claim still needs to go to investigation.They will never automatically deny a claim.


When trying to identify the rules in the context of this model, and integratethem with the process flow, the rules come out looking something like this:– If estimated claim value is at or above some X then investigation is required

– If estimated claim value is below some X then claim validity estimation is required

… and so on.

But are these really the fundamental rules? If we step back and ask whatis being determined here, we see that the overall purpose of a number ofthese processes, acting together, is to determine what treatment to applyto a claim as shown in Figure 17.

Figure 17: Processes for Determining Claim Treatment

Specifically, we see that claim treatment is a factor of

Estimated cost of claim

Estimated claim validity

Customer value

Putting these in decision table format suddenly exposes the real underlyingbusiness rules. Looking forward, it also provides the basis for investigatingwhich of these permutations is causing the most claims to be paid out, and soon. It also allows us to view possible other permutations that might be tested.


Finally should we decide to add another factor, our process model may notchange at all. We will simply add the factor to our decision table (which reallyrepresents a set of rules, each row being a rule) and which is shown in Table 3.

Finally the process model is simplified to the essence of what is beingaccomplished from a business perspective, shown in Figure 18.

Figure 18: Simplified Claim Evaluation Process Flow

What is this telling us? It’s saying that all the “steps” associated withdetermining claim treatment are pure information gathering and computing.There is no human activity such as “investigate” going on here, or change ofactors in different locations; at least none that are really of business interest.As a result, we can easily express this whole section of “process” with rules ina declarative decision format.

Table 3: Decision Table Format for Underlying Business Rules

Factors Result

Estimated Cost of Claim

Estimated Claim Validity

Customer Value Claim Treatment

Above threshold -- -- Investigate

Not above threshold Very high -- Pay claim

Not above threshold Intermediate High Pay claim

Not above threshold Intermediate Low Investigate

Etc.


It may be that there are additional rules associated with figuring out each of thecontributing factors:

Estimated cost of claim

Estimated claim validityCustomer value

But again, if there is no real work flow associated with these, then rather thanburn up business stakeholders’ time modeling “flow” with regard to all this, wecan display the dependency of claim treatment on these other rules, with adependency diagram shown in Figure 19. In the same fashion, we wouldinvestigate these “sub-decisions” and determine in each case whether anymodeling of “flow” was really required or of business interest.

Figure 19: Claim Treatment Determination Rule Dependencies

In system design, depending on the approach and technology being applied,perhaps flow among these various computations and decisions will have to beoptimized and orchestrated. But that is really a design problem, not a businessanalysis problem. The simplified model exposes the essential businessprocesses and the true, underlying business rules. It also makes the modelmore amenable to results measurement and adjustment, simple by adjustingrules.

In one real life example, a strictly hierarchical approach to process modelingwas applied initially, with business rules placed at the bottom of the hierarchyand specified last. Qualitatively, the models were found to be overcomplicatedand hard to navigate and understand. As a test, the same approach describedabove was applied to these models, after the fact, with business rules or rulesets integrated wherever appropriate in the business process model. The


result was an over-50% reduction in the number of individual modelcomponents (e.g. processes and decision gateways) while increasing clarityfrom both a business and designer perspective.

What proved most effective, then, was not a top-down, process-to-rulesapproach, but one that iterated between both perspectives. While a fulldescription of the approach is beyond the scope of this chapter, the essence ofit was this: whenever a decision point—evaluation, computation, etc.—wasencountered at any level in process analysis, a switch was made from a“process” to a “declarative” approach. That is, we asked “What factors areinvolved in making this decision? What else do I need to know in order to makethis determination?” without regard to the mechanical process flow involved. Inaddition, we asked “Why do I need to know this?” to help determine whetherthe question being asked was itself just a component of a larger decision thatwas currently buried in the process flow. Asking this question also helps affirmor drive out the business motivation behind any rule or set of rules, so thattraceability can be maintained and the impact of future changes in thatbusiness motivation can be rapidly assessed.

Asking these questions exposes the underlying business decisions andassociated rules, which in turn affects the process model. The result is aniterative approach, going back and forth between process and rules, to uncoverthe optimum business model. This approach, when actually tested, producedsimpler, clearer process models, exposed the essential business processes,and uncovered rules that more closely reflected the real rules of the business(as opposed to procedural “rules” associated with the details of a particularcurrent state process implementation). As a result, these models also reflecteda cleaner separation between the business model and design, clearly definingthe former while minimally constraining the latter.

It’s reasonable to suggest that what we’ve described here is simply goodprocess modeling, and we would not dispute that. The difference is that byapplying a rules perspective we were able to turn “good process modeling” intoan objective, repeatable technique, one that uncovered the essential businessprocesses while at the same time identifying the actual business rules andimproving overall clarity of the business model. This was demonstratedrepeatedly with experienced process modelers. This technique led to clearer,simpler processes and underlying business rules that were missed before itsapplication. Furthermore, it helped expose procedural arbitraries and currentstate biases in the models.

Establishing these results and this technique also helped answer anotherquestion: Does this “rule enhanced” approach just apply in certaincircumstances, or for certain kinds of systems or implementations? A


commonly encountered view is that a business rules focus and business rulemethods are only relevant when you’re deploying rule engine technology, orwhen the business area is “dense” with volatile rules. While theseconsiderations may help prioritize targets for implementing improvedtechniques, our experience demonstrated that creating explicit business rulework products and integrating their specification with process analysis usingthe described iterative technique produced clearer and more completebusiness models, irrespective of the business areas being considered or thetechnology being deployed.

The Impact of Business Rules on the Data ModelA pre-requisite for managing a portfolio of rules for precision, clarity,consistency, completeness, and reuse is a standard set of defined terms forexpressing the business concepts that are used to compose the rules. In theabsence of consistent terminology, none of these desired qualities for rules canbe assured.

Moreover, as soon as the number of terms grows beyond a handful, andrelationships between terms become numerous, subtle or intricate, some sortof modeling approach becomes necessary to precisely identify, grasp andvalidate all these relationships as an integrated whole.

In the business rule community, this has become known as a “fact model,”expressing the “facts,” or relationships among terms. Regardless of name, it isessentially a model of business information, expressed in business terms.

Traceability It is not within the scope or intent of this chapter to talk at length about factmodeling in relation to business rules. What we do want to discuss briefly ishow this model of information integrates with and impacts the data perspectiveof the business model. If you are familiar with this perspective, you know thatyou can have conceptual data models at the higher business level, logical datamodels at the logical system design level, and physical data models at theimplementation level. There may also be an application object or class model,in some cases in lieu of the data model. Good practice requires traceabilityamong these models, whether or not this is always done in practice.

The obvious question that comes to mind, and that needed to be addressed,is: How do we manage yet another view of information, and how does itintegrate with all these other views? Have we just created a traceabilitynightmare? If you are serious about improving your specification, and


management and reuse of business rules, you will eventually have to answerthis question, especially if you are dealing with large scale systemsdevelopment as we were.

As mentioned before, we were driven by pragmatics. Data traceability wasalready a problem. Introducing yet another view of information and informationtraceability requirements, besides the confusion it might generate, wouldsimply not have been feasible. The solution was to consider the businessinformation model (we’ll use that term, since it emphasizes that this businessview of information was needed, not just for the rules but to integrate with theprocess model as well), as an extension and detailing of the Conceptual DataModel. This meant the Conceptual Data Model became not simply a high levelpartitioning of data concepts for the purposes of deriving a database strategy,but a complete view of business information, from a business perspective.

In this way, the business information model—or detailed Conceptual DataModel—fit directly into the hierarchy of data analysis. It also highlighted thatthe business needs to understand its information in detail, not just within thecontext of the logical design of a particular system. The logical data model, orapplication model would then derive from and need to fully support the detailedbusiness information model. As a practical point in implementing thisapproach, since a logical data model already existed, the business informationmodel borrowed from and used this model as a starting point whereverpossible, but departed from it where modeling abstraction, introduced fordesign purposes, did not support a full representation of the business.

The business information model, then, was not “traceable” to the ConceptualData Model. It was the Conceptual Data Model, expressed in detail. This detailhad formerly been missing in the business view of data.

It left another problem, however. The business rules expressed in terms of thebusiness information model needed to be designed using terminology of theapplication design model, whether that was in terms of an application classmodel or a physical database design. It’s not hard to see that when you throwin the logical data model, we’re still talking about a lot of potential traceabilities,and that this problem of data traceability from business to design has existedall along, irrespective of rules.


Our conclusions were these:

• Depending on the application environment, whatever model is used asthe basis of application design, whether an object model or physicaldatabase design, needs to be mapped to the business information model(if an object model is used, it would then have to map at some point to thephysical database layer).

• The logical or application model must demonstrate fidelity to the businessinformation model through some mapping.

• The physical database design needs to be traceable to any logical datamodel.

Out of the possible choices, these were considered the key traceabilities.Thus, defining the integration of business rules with the data perspective of thebusiness model had driven us to clarify the entire mapping of data between thebusiness model and design.

Business Rulesand

Improvements inData Analysis

For terms representing key business concepts, such as order, where manypossible “states” are potentially involved, such as incomplete, submitted,shipped, overdue, etc., an examination of these states and conditions fortransitioning from one to the other is a technique sometimes applied to ensureterms or “objects” with complex or “interesting” behavior are completelyunderstood and fully analyzed. This “state transition” analysis is commonlyassociated with the data or class model. Exactly how state transition diagramsfit integrate with the business model as a whole has been less evident.

With the inclusion of business rules as modeling artifacts on a par with data andprocess, as shown in Figure 20, the role and positioning of state transitionanalysis in the overall business model became much clearer. State transitionanalysis acts as a technique to expose further business rules, or act as aquality check on the business rules identified, in terms of completeness,correctness and consistency. The results can in turn affect the process modelthrough the exposure of additional business rules. Thus, state transitionanalysis can be viewed as a business rule technique applied to data, similar tothe “decision analysis” technique applied to process, and business rulesbecame more firmly placed as the final “glue” between data and process.


Figure 20: Interdependency of Process Rules and Data

Business Rulesand Data Earlierin the Life Cycle

In areas where rules play predominant roles, such as customer profiling, orproduct/service eligibility and configuration, we found that taking thisstate-transition-oriented data/rule perspective very early in the life cycle can bequite effective. Looking at key entities such as customers, products andservices, as a first action independent of process, examination, and states theyassume, as described above, can be used to derive the first set of high levelprocesses. This approach can help to partition and attack the complexityinvolved, and break the business out of its current state view of processes.From the identified states and rules, the essential process flow can be derived.

In some rule-intensive business areas, analysis began with a survey of existingsystems from the perspective of key data concepts and associated rules, as aneffective tool for identifying areas of overlap and for evaluating opportunity anddifficulty based on an assessment of rule complexity and volume. In someprojects, issues of rule consistency and underlying policy have acted as thefundamental business drivers, and were addressed first.

The Impact ofBusiness Rules

on the Data Model– Summary

Clearly business rules are closely integrated with the data view of a system,since business rules depend on a set of precisely defined and consistent set ofterms. But integrating business rules into the business model also enhancedthe data perspective itself by:

• Identifying and filling a gap in the data perspective by clarifying theconceptual data model as a complete, detailed view of businessinformation

• Clarifying the traceability requirements from one information view toanother

• Precisely positioning state-transition analysis and its value in thespecification of the business model

• Further illuminating and organizing the relationship of process to data,through the “glue” of rules


Business Rules and Business System RequirementsIn an ideal world, a complete set of requirements would be available at thecommencement of a project. To achieve this objective, analysis would need tobe carried out to a depth consistent with detailed logical design for all of therequirements to be fully defined. In our experience, at least for a large andcomplex business system, a project is developed in stages, e.g. conceptualdesign, logical design, and physical design. In this situation, requirements aredeveloped and refined parallel to each phase. It is within this context that wewill examine the relationship between business rules and requirements in thisarticle.

While some people believe that business rules and business systemrequirements are the same, it is safer to assume that they are not, based onthe definitions shown in Table 4.

The reason this distinction is important is that if business rules andrequirements are the same, then the implication is that for every rule there mustbe an equivalent requirement. In a large and complex system, we could havethousands of requirements. This is an unnecessary situation since, as we willshow later, a single requirement can refer to many rules, as long as they arefunctionally related. What is clear, then, is that rules and requirements areclosely related through the business model described earlier in this chapter. Tounderstand the relationship, we must first define what we mean by businesssystem requirements.

Table 4: Differences Between Business Rules and Business System Requirements

Business Rules Business System Requirements

A business rule is a statement consisting of business terms and connecting facts that specifies business behavior, e.g. Rule 1. If the Estimated cost of claim is not above the threshold, estimated claim validity is intermediate, and customer value is high, then pay claim; else investigate claim.

Rule 2. etc for whole customer treatment rule set

The active life of a business rule is dependent on the life of the policy or procedure that contains it.

A business system requirement is a statement of what we want the business system to perform, e.g. The system shall determine customer claim treatment in accordance with the claim treatment rule set.

Requirements statements are required as a basis for contractual language (what we want the developer to achieve), and are a key input to the testing process used to demonstrate that the contract has been fulfilled. The active life of a business system requirement is dependent on the life of the development contract.


Because specific business systems differ tremendously in scope, use ofmethodology, and the application of technology, it is necessary to definerequirements using certain categories. A review of the many books written onbusiness system requirements reveals that there is no common agreement onwhat these categories should be. We will adopt our own categories for thepurposes of this article, as shown in Table 5. Our interest in this article is infunctional requirements only.

So what is the relationship between business rules and requirements? It is awell-documented fact that a high percentage of the failures of businesssystems to meet the needs of the business community is directly attributable topoorly stated up-front requirements. The lack of specificity and correctness ofthe requirements is typically due to insufficient time being allocated to theirdevelopment, and to their expression in a textual format, which in turn leads toambiguity of understanding and interpretation. The other major probleminherent in requirements expressed in this way is that it is almost impossible forthe business user to be able to certify at the beginning of the project, whenrequirements are developed, that they are correct and complete. Fortunatelywe can solve all of these problems through the use of a well-defined businessmodel and its associated business rules.

Figure 21 shows a portion of the process model, illustrated by a process flowdiagram, and its associated business rules. This model, when fully articulated,tells us everything we want to know about the business behavior that we wantthe business system to automate. We no longer have to struggle to specify the

Table 5: Categories of Business System Requirements

Functional Non Functional

A functional requirement specifies direct user observable attributes or behaviors—also known as “outputs” of the software application—usually through output devices. It can also include manual procedures not carried by the system.

A non-functional requirement specifies application attributes or behaviors that are not directly observable by the user.

Examples of requirements included in this category are:

• Process• Business performance• Organization• Location• Business Information

Examples of requirements included in this category are:

• Data• Application• Technology• Security• Usability• Testability


requirement through complex text, but can develop a simple requirementstatement which references the detailed content of the business model. Therequirements are now complete, consistent, unambiguous, and easilyunderstood by both business users and system developers.

Figure 21: Requirements Made Complete by Reference to the Business Model

The lesson learned from this approach is that time spent up front in developingthe business model and by reference the functional requirements is time andmoney saved at the back end when traditionally most of the system “problems”are uncovered during testing.

Business Rules and TestingTo demonstrate that the business system fully meets the stated businesssystem functional and non-functional requirements, the developer and theclient conduct a series of system acceptance tests. For the purposes of thisarticle, we are interested in the testing of functional requirements that havebeen derived from the business model, as previously described. A good test isone that has a clear outcome, from which we can determine passing or failureof the test. The business rules and associated process model artifactscontained in business model provide the basis for effective testing.


Figure 22 is a process flow diagram which depicts the various paths that abusiness user can take through the process in achieving the possible businessoutcomes. For testing purposes we have highlighted one of the possible paths.

Figure 22: Path Through the Process Model of a Single Business Scenario.

Since the model contains the business rules appropriate to the selected path,we can determine the outcome by providing appropriate input values for all ofthe rules that will be executed along the path. As shown in Table 6, we candevelop a business scenario that describes a specific instance of businessbehavior that we wish to demonstrate during testing. By including the inputvalues, we can determine the expected outcome. The scenarios can then beused as the basis for specific test scripts used in the testing process.

Table 6: Business Scenarios and Testing

Scenario Terms Evaluated

A customer submits a claim for payment for which we know the following to be true:

Estimated cost of claim is not above threshold;

estimated claim validity is intermediate,and

customer value is high.

Once authenticated, the claim is submitted to the claim treatment process for evaluation, using the claim treatment determination rule set. The above conditions are established and, as a result, the claim treatment process concludes that the claim should be paid.

Terms values evaluated are:

• Estimated cost of claim = Not above threshold

• Estimated claim validity = Intermediate• Customer value = High • Claim treatment = Pay Claim


The above represents a small slice of a scenario. In real life, the completescenario would show all relevant values for the initiating event, the submittedclaim, and for each process and decision point through the process thread, theinputs and expected outputs. But it at least demonstrates the concept.

Our project experience has shown that the advantage of this approach, whichis based on the information contained in the business model, is that we candevelop the scenarios early in the development process (no later than logicaldesign), giving the test team valuable input on the number and complexity oftests they will be required to perform. The second advantage is that thescenarios and subsequent test scripts based on the content of the businessmodel are readily understood by the business users, which has the benefit ofremoving ambiguity from the testing and acceptance process.

SummaryIn our investigation of business rules, our original objective was to “simply”improve the organization’s ability to clearly identify, separate out, manage itsmany rules, and add corresponding precision and completeness to associatedsystem specifications. This improvement in specificity and clarity was takenmore or less as a given, though our piloting efforts proved it out as well. Whatwas less well understood and appreciated when we began was the positiveimpact that the insertion of separate business rule work products andtechniques would have on the business model as a whole. The jury is in now,as we have described above, and we can say with some certainty thatincorporating a formal approach to business rules in the business systemsmodel:

• Improves the clarity and simplicity of business process models, and helpsto expose the essential business processes and to avoid modelingarbitrary procedural details

• Helps complete and organize the data perspective of the model,determine the importance of standard terminology from a business (notdatabase) perspective, and the key information traceabilities required.

• In adding the necessary detail to the process model, enables the creationof test scenarios and cases, partitioned and described in a way that thebusiness can understand and validate and that can be traced toimplementation level test scripts

• Clarifies the relationship of business modeling and textual requirementsspecification, and enables the effective integration of these two views toform a complete specification of any business system


This is good news, and probably represents a validation of one finalobservation: Business rules were always there in our business and/or oursystem models and requirements statements. They may not have beenseparated out or completely stated, but they were there someplace, otherwisethey would not, for the most part, have been implemented at all (a nod to rogueprogramming). It makes sense that if business rules do represent a specific,essential component of a holistic business model, then bringing more order andrigor to that component would further clarify and organize the rest of the modeland its parts, and this is exactly what we have discovered to be the case.


c h a p t e r


8 Better Rules Through Innovative Rule-Authoring Software

John Semmel

IntroductionSometimes it starts with a directive from upper management. It may begin instate or federal legislative bodies. Other times it’s just a matter of commonsense. Whatever the source of the business rule, it has to be assimilated bythe business people responsible for collecting and enforcing such rules, thenstored in a repository, where it will be available for use in driving businessprocesses and associated automated applications. The translation frombusiness knowledge in someone’s head to an automatable form (such as rowsand columns in a database) is often the weakest link in the chain. It is this linkthat is fortified by rule-authoring software. The more innovative the software,the more fortified this link becomes.

This chapter tells of our journey to deliver to non-technical, business-orientedrule authors, such as underwriters, the complex task of authoring businessrules ready for automation. Not only did we deliver rule-authoring software, butwe also gave these authors an entire toolset, by which they can ensure thattheir rules are accurate, logical, and interact well within the application theysupport. The chapter covers:

• Background• Laying the foundation: the concepts and complexity behind the rules • The learning curve and dealing with rule errors• More and better software solutions• The rule wizard• Wizards are us• Application emulation

Page 108 Chapter 8: Better Rules Through Innovative Rule-Authoring Software

• Ongoing efforts• Timeline• Conclusions and summary

BackgroundOur Medical Insurance Quotation Application is designed to allow its usersmaximum flexibility in configuring cost-sharing levels, usage limitations,deductibles, and so on. At the same time, this application must prevent theunderwriters from selling product configurations that make no business sense.An example of a configuration that may make little sense is allowing a $40co-pay amount for a primary care physician, and a co-pay amount of only $5for a medical specialist. The application must also prevent underwriters fromsetting benefit levels that are not approved in given jurisdictions. Thesesituations (nonsensical and restricted-product configurations) must all beaddressed by our Medical Benefit Selection aspect of the application. Foragility, we store all of the rules that drive Medical Benefit Selection in adatabase, rather than hard-code them in program code. But, this is just thebeginning of delivering agility. We wanted to extend the agility deep into therule authoring, rule analysis, and rule simulation aspects of managing theMedical Benefit Selection, and to deliver these functionalities to thenon-technical, business-oriented rule authors. According to the Rule MaturityModel (RMM), this goal is innovative, whereby such functionality representscharacteristics of an organization at Level 3 of the RMM.

The amount of medical benefit selection data we collect is staggering. A singlequote option may include in excess of 1,400 individual data values. Each ofthese values must either be selected during the quoting process or set byexecuting a rule.

The number of circumstances that determine what business rules are executedduring medical benefit selection is also dizzying:

1. Different basic plan types have their own rules.2. The states all regulate what we may and may not sell.3. We offer greater flexibility to plan sponsors who are self-insured, relative

to what we offer those that we insure directly.4. There are different rules, depending on the size of the group we are

insuring.5. The rules for new business are sometimes different from those for

renewals.


All together, we have ten of these factors that can influence the rules thatshould be executed in each case.

When we started this project, we had a data model and a rules engine. Ourproject team had standard database query tools and Microsoft Visual Basic.Only a few team members knew how to use these tools, as most memberswere from the business side of the company, not from IT.

On the other hand, we were limited only by what the data model and the rulesengine could support. It was like being in a large, bare room with many cansof different-colored paints and lots of brushes, except that none of us had everdone any painting before. There were bound to be some clashes and somedrips along the way.

Laying the Foundation: The Concepts and Complexity Behind the Rules We first needed to understand the business concepts that sit behind the rules,such as plans, benefits, characteristics, and values. Our medical plans consistof benefits, such as Inpatient Hospitalization, which in turn consist ofcharacteristics such as Co-pay Amount or Coinsurance Amount. Our plansdefine the bounds and increments of the values for the various characteristics.So a Physician Office Visit Co-pay Amount may assume values between $0and $60 in five-dollar increments, for instance. The plans contain all possiblevalues for all characteristics for all components in the plan. As a result, our planwith the 1,400 characteristics contains nearly 16,000 individual values.

As we designed and populated the database to hold the plan contents, weneeded a means of verifying that the content was correct. Therefore, our firstrule tool was an inquiry application. Since our plan and product data ishierarchical in nature, the inquiry tool makes heavy use of the MicrosoftWindows tree view control to expose that hierarchy to the business-oriented,non-technical user. With this tool, the people who know what the plans shouldcontain are able to inspect the plans, and to request that values be added andremoved as necessary, all with no knowledge of SQL or the structure of thedatabase. Nevertheless, the task of maintaining this data was very much amanual operation in the beginning, making it time-consuming and potentiallyerror-prone.


While we were building plans, we were also making up the rules we would needto drive medical benefit selection. We discovered we needed four basic typesof rules to fit our specific business requirements:

1. Limiting Rules: These restrict the domain of a characteristic.2. Setting Rules: A subset of limiting rules, these restrict the domain of a

characteristic to a single value.3. Default Rules: These determine the values that show up in the

drop-down lists before anything is selected. They are importantbecause, if appropriate defaults are set, the person composing thequote may have much less work to do.

4. Non-display Rules: If the quoter can’t change a value, there’s no reasonto clutter the page with it. Non-display rules tell the quoting applicationnot to display the characteristic.

We now have more than thirty variations on these four rule types.

Some of these rules are driven strictly by circumstances. For example, In NewJersey, a Physician Office Visit Co-pay Amount may have certain regulatedrestrictions. Other rules are driven by a combination of circumstances andother selected plan values. An example in New Jersey is that a Routine AdultPhysical Exam Co-pay Amount defaults to Physician Office Visit Co-payAmount. In some rule types, the result value may be driven by two or morecontrol values in addition to circumstances. We have situations where as manyas thirty characteristics determine the value of the result in a single rule.

On top of everything else, we decided that we needed to specify a precedenceamong the execution of rules based on circumstances. So for instance,state-specific rules on a given characteristic need to prevent non-state-specificrules from being executed. In this way, a generic list of co-insurance valuesthat may apply to most states can be overridden by a list that applies to a givenstate.

Added to the daunting complexity of this rule scheme are two pressures. First,we were under pressure to get the rules authored as soon as possible.Second, the application to implement the rules was months from being usable.To extend the painting analogy, we had to apply our paint under a strictdeadline, and the room was dark.


The Learning Curve and Dealing With Rule ErrorsOur first efforts at storing rules were about what you’d expect under thecircumstances. The process occurred roughly as depicted in Figure 23.

Figure 23: Original Business Rule Process

We had business people who understood the business rules—but notnecessarily the rule types and interactions. These people were writing the rulesin basic English sentence form. These rule authors would then pass theserules to a team of semi-technical consultants who would encode this form of therules into spreadsheets, formatted like our database tables. Then thespreadsheets were given to data technicians who used various utilities to loadthe rules into the database. By the time the data, representing the translatedrules, was stored, it was rife with errors. These errors resulted from thefollowing:

1. The original English rules were sometimes incorrect or inconsistent.2. The semi-technical consultants’ interpretations of the English rules were

not always correct.3. There were technical failures loading the data.


All this led to missing data, invalid values and inconsequential data. Without away to analyze the quality of the rules, let alone test them, we measured ourprogress by counting the number of rules we had produced compared to thenumber we estimated we needed. When we finally had an application thatexercised the rules, we began to see how poor the quality of our rule data was.In the early days of testing, the poor quality of the rules was masked by the poorquality of the application itself. But, eventually, we needed to better understandthe poor quality of the rules.

Because of the nature of rules, we discovered that we had more than justordinary data problems. Individual rules are simple. But rule interactions canbe quite complex. We found numerous rule conflicts where one rule would limita characteristic’s domain, say, to 1, 2 and 3 and another rule being executed atthe same time would limit the same characteristic’s domain to 4, 5 and 6. This,of course, is a conflict, and our application would create a null domain whichcaused a difficult-to-debug runtime error in our rules engine. We also foundproblems related to rules that unintentionally blocked other rules, due toprecedence conflicts, and loads of duplicate rules.

Compounding these various problems was the time lag between when the rulewas authored by the business-oriented, non-technical rule author in Englishand when it actually got deployed in the application. At the worst point, thiscould take weeks, as there were several manual steps involved. By the timethe rule was deployed, the rule authors scarcely remembered what they hadwritten.

And so, as a first defense, we developed error reports. These started out asad hoc queries that could detect problems across the rule base as individualproblems were discovered. But as more and more problems came to light, andas we began to understand the data (and rules) better, the reports becameincreasingly complex.

The first runs of our error reports produced overwhelming spreadsheets listingthousands of rule errors. We ran reports on a nightly basis, and the ruleauthors spent all day fixing the errors. Even so, no one knew at this timewhether the fixed rules were correct, or even if they made business sensebased on these reports. We were simply able to catch integrity issues andcertain logical errors.

Our next task was to develop the ability to automatically generate a rule failuremessage. Some of our rules can’t be “violated.” Non-display and default rulesare examples. A value either displays or it doesn’t; the user can’t place an


invalid value into a field that’s invisible. However, some rules can be violated.When such a violation occurs, the user is given a message describing the ruleand the opportunity to change the offending value to something appropriate.

When we started authoring rules, these failure messages were coded by therule authors themselves. We discovered that it was useful (for documentationpurposes) to store the error message with the rule for all rule types, whether ornot the application users would ever see it. There were some problems with thisapproach, however.

1. No two authors wrote failure messages the same way.2. Some authors used inscrutable codes and abbreviations in the

messages.3. There was no way to ensure that what the error message actually

represented what the rule did.4. When an author changed the rule, there was no way to enforce that the

message was changed to match the revised rule.5. Writing the failure message was often the most time-consuming step in

writing the rule.

We discovered that we could write code to read the rule data and generatefailure messages from it. This gave us perfectly consistent, complete andaccurate messages, and saved a great deal of the rule authors’ time. Theauthors quickly warmed to this approach.

More and Better Software SolutionsThe remainder of this chapter discusses our journey into more sophisticatedand innovative software to empower the rule authors. These additionalsoftware pieces consist of:

• A rule inquiry application to enable access to and inspection of rules• A rule maintenance application to hide the idiosyncrasies of the rules

engine (and allow for changing the rules engine)• A rule analysis application to ensure integrity of new and changed rules• A rule application emulator so rule authors can see the rules in action

(simulated with data) prior to actual deployment in the target rules engine


Our business rule process evolved roughly into that depicted in Figure 24.

Figure 24: More Advanced Business Rule Process

The Rule WizardAfter some months of writing rules, our rule authors became more comfortablewith the jargon that we created around rules and product and plan data. Theybegan to better understand the rule types and rule interactions. It was time forus to cut out the middlemen, as it were: the people who translated the Englishrules to spreadsheets and those who translated spreadsheets to rows on thedatabase.

We knew for a long time that we needed a good data-entry application to solvemany of our problems. But for most of that time we were missing twoingredients:

1. The deep knowledge of our rule data structures and rule authoringbusiness processes necessary to design such an application.

2. The resources to build and test the application.


Finally, we had advanced to the point of being ready to undertake thisdevelopment effort. Rule-loading had become routine, and as a result, lesstime-consuming. So we diverted rule-loading time (and not a small amount ofwhat might have been free time) to this development effort.

The inquiry application mentioned above came into play here. It had startedout as a simple plan data viewer, but had gradually become more and morecomplex, exposing most of the static data in our database, including rules. Itprovided two methods for searching for rules:

1. Drilling down on a hierarchical tree view from product to component tocharacteristic in order to expose the rules on that characteristic.

2. Ad hoc parameter-based search for rules by rule control and result andby the circumstances under which the rules are executed.

Thus, it was logical to base the rule maintenance application on the inquiryapplication. Once you found a rule, you could open it up, look at it, and changeit, if necessary. Opening a rule is like opening any document under MicrosoftWindows. The maintenance application we designed followed the model wehad built around writing our business rules.

Our rules engine was, and is, a versatile piece of software. It would have beenpossible to have encoded rules directly into this engine. These rules wouldhave looked like discrete conditional statements, rules at their lowest level, orlike rule assembler code. But this task would have been highly technical andpainstaking, a job most of the business-oriented, non-technical rule authorswould have been hard-pressed to undertake.

So, even before we created a rule maintenance facility, we built two layersbetween these rule authors and the rules engine. This is a database in whichto store a relational representation of the rule data, and an interface programthat translated the rules from the database into the language of the target rulesengine. This worked well for two reasons:

1. It allowed us to model rules our own way (in the eyes of thebusiness-oriented authors), letting the interface program mediate thedifference between the way the authors viewed rules and the way therules engine wants and needs to view them.

2. If we ever wanted to change to a different rules engine (or add a differentone to our technology set), we’d still have our logical rule data encodedin our database.


And so, we developed another tool, our Rule Wizard, as a third layer betweenthe rule authors and the rules engine. It hides many of the details of the datamodel used to store the rules, and otherwise facilitating the storage of validrules.

The first task for a rule author is to establish the kind of rule to author. The kindof rule determines how the Rule Wizard operates, because each rule type hasits own unique data requirements. The Rule Wizard includes a decision treethat takes the rule author through a series of questions and answers todetermine what type of rule to use in a given instance.

The second task for the rule author is to specify circumstances under which therule is to be executed. Some of these circumstances also determine what otherrule specifications might be required or optional in the given rule.

Our Rule Wizard has access to the plan data regulated by the rules. So if theauthor is specifying valid values for a Specialist Co-pay Amount for a givenplan, the author can select from only the co-pay values assigned to theSpecialist in that plan. This makes almost impossible the kinds of mistakes thatwere frequent in early rule loading.

Before a rule is stored, the Rule Wizard analyzes the quality and integrity of therule:

1. A full referential integrity check on the rule performs edits that would beimpractical to do screen-to-screen interactively, and includes edits thatcan only be performed once the rule is fully coded.

2. A check for rule conflicts detects those circumstances for which thecurrent rule, along with another existing rule, will create an emptydomain.

3. A duplicate rule check prevents exact rule duplicates from being stored.4. A blocking rule check detects rules that will block the current rule, and

for rules the current rule will block.5. There is automatic generation of a failure message for the rule.

The delivery of the Rule Wizard not only resulted in a huge advancement inenabling the rule authors to write rules, but the rule authors could now easilyaddress rule quality and integrity, all without much technical support. They canfind their rules, open them, inspect them and change them. They could do sosafely, knowing that quality issues among the rules would be detectedautomatically. New rules were now very easy to write. And, best of all, it wasdifficult to create an invalid rule.


Wizards Are UsFollowing the success of the Rule Wizard, we developed other datamaintenance and validation tools along the same lines that worked againstother static data tables in our database. All of these applets hang from thesame tree, the inquiry tool we started out with in the beginning. We now havenine of these maintenance components. The Rule Wizard is by far the mostcomplex of them.

Application EmulationBut there was still a major problem. Once the rule was written, it had to beloaded into the rules engine. Then the rules engine had to be deployed on aserver before the authors could see their rules in action. This could take a fewdays. Then, if there was a problem with the rules, the authors had no meansfor diagnosing the problem. Developers familiar with the rules engine wouldhave to dig into the problem and tell the authors the rules that were in conflict.Then once the rules were fixed, it took a few more days before they could beretested.

This is a huge problem for two reasons. First, it was highly inefficient to let adefect get so far along in the process without being addressed. Second, therule authors were not easily learning the craft of authoring rules becausefeedback was so slow.

Entering an entire quote is a time-consuming process consisting of severalsteps other than medical benefit selection. And, as stated, the applicationprovided no diagnostics on rules that were of any use to the authors. So wenext wrote and delivered an Application Emulator that isolated medical benefitselection and provided feedback on the rules that were being executed as theemulator ran. This emulator could load newly written rules in a local copy of therules engine database, so the authors didn’t have to wait for the nightly loadbefore they could test. Now the rule authors could see both what the end userswould see as well as all of the rules driving the application.

But, this still wasn’t perfect. At first, the emulator had no means of displayingthe non-display characteristics, so the authors had no means of knowing whatwas going on behind the scenes for these characteristics. The emulator is nota particularly fast application. And while it reliably shows how rules will beexecuted in the application, it doesn’t provide any additional logical support,such as flagging duplicate rules, or indicating when a default value is not in thevalid domain set for a characteristic. Neither of these conditions causeproblems in the application, but they are both logical inconsistencies thatshould be addressed.


Ongoing EffortsFrom the very beginning, our quotation application has been a moving target.The healthcare industry is changing rapidly: HMOs are on their way out; HSAsare on their way in. This has meant racing to develop the base quotationapplication while trying to keep up with a barrage of new business requirementsthat were unknown when development started. For our rules environment, thishas required a high degree of flexibility.

1. We have added new rule types on several occasions. More than a thirdof our 34 rule types were invented after we started writing rules. Thenewer rule types have tended to be more complex in nature than someof the early types.

2. We have changed our notion of rule precedence on a couple ofoccasions.

3. When we started, each rule had only one set of circumstances underwhich it would be executed, although those sets might be very complex.Now we allow for the definition of multiple groupings of circumstancesunder which each rule will be executed.

4. We’ve created rule cloning facilities so that rule authors can createwhole categories of rules without having to enter them individually.

As far as we’ve come with authoring tools, it isn’t far enough. Our ApplicationEmulator is not integrated with our Rule Wizard, so the authors have to go fromone application to the other to enter and test their rules. Testing can be agrueling process as there are an astronomical number of possible sets ofcircumstances, each set having its own mix of rules.

We are also still grappling with the rule set migration issue. When we buildrules into our rules engine, we do so for entire plans at once. This means thatall the rules must be written and working at the same time. What we’d like tobe able to do is to include rules in the rules engine selectively, so that we canhold some rules in development status while other rules get moved along toproduction. This is a rule author issue to an extent, as the authors must be theones to manage which rules go and which do not for a given rules engine build.

This issue is being addressed with a migration facility that has been developed,but is not yet in use.


TimelineIn retrospect, parts of this process came together quickly. At the time it washappening, it seemed endless. It’s instructive to look back at how this projectprogressed.

• 4th Quarter 2002: – Defined product and plan data

• 2nd Quarter 2003: – Started product and plan data load– Defined rules– Started rules load– Improved inquiry tool (ongoing)

• 3rd Quarter 2003: – Continued product load – Continued rules load– Rules engine/UI in final development– Application is due at the end of July!

• 3rd Quarter 2003: – Integrity and conflict reports

• 4th Quarter 2003: – Duplicate reports– Failure message generation – Rule Wizard development begins

• 1st Quarter 2004: – Rule Wizard deployed– Dental plans implemented (not many rules)

• 2nd Quarter 2004: – Product, Plan and other Wizards deployed– First Medical Flex Plan Pilot implemented!

• 3rd Quarter 2004: – Rule Emulator deployed

• 1st Quarter 2005: – Planning begins for a migration facility

• 2nd Quarter 2005 through 4th Quarter 2005– Upgrades to Rule Wizard and other data maintenance tools– Upgrades to Rule Emulator– More Medical Plans in production

• 1st Quarter 2006– Migration facility deployed– Start of migration to VB.NET


Conclusions and SummaryWe now have nearly 100,000 rules sitting in our database, guiding MedicalBenefits Selection, all managed by the true rule authors.

But our odyssey into rule authoring is by no means over. In our end vision,rules will be even easier to enter than they are now. Our testing software willautomatically examine a rule as it will be executed in all possiblecircumstances, and will ferret out all conflicts and inconsistencies between thecurrent rule and others in the rule database. It may even offer to mediate theseconflicts and inconsistencies.

Rule deployment will be improved too. It still takes an overnight job to get anewly authored rule into the rules engine for use by our application in adevelopment environment. It can still take weeks to reach production, which isfine for certain kinds of projects, but not for problem fixes. Some of ourbusiness partners are very forward thinking on this, and are demanding theability to get rules into production overnight.

I’ll close with a list of the insights I’ve gained in working through the process ofsupporting a rules-based application.

1. The people with the deep business knowledge are the best people toauthor the rules, even rules targeted for automation. The process oftranslating their rules through intermediaries leads to mistakes andmisinterpretations.

2. You can’t go any faster than you can go, even with tools. If you are anorganization new to business rules, allow time for rule authors to learntheir new trade and use their new tools. There will be stages of reworkas the rule authors and related tools evolve in their maturity. Deliverprototypes along the way.

3. The rules may never be perfect, but refinements and improvements area part of the ongoing process. This is a sign of great success. In somecases, conflicts encountered in rule authoring spring from conflictsinherent in the business process, conflicts that were not apparent (orwere at least undocumented) until the process was deconstructed andloaded into a logical system.

4. There is something to be said for starting with a manual approach toloading rules into a database. Rule authors need to understand whatrules are, what their pieces are (such as plans, characteristics, values),and what the process consists of when moving from conceiving of a rule,determining its type, determining its execution circumstances, andvalidating its integrity. There’s nothing to systematize until you have amanual system that is defined and understood.


5. Rules are no good if you can’t find them. They might as well be buriedin code if they are buried in a database.

6. The shorter the time between when the rule is written and when the ruleis tested with other rules in the target environment, the more immediatethe feedback to the rule authors, the faster they learn their trade, andthe fewer mistakes they make in rule set-up. Back in the day whenprograms had to be punched onto cards and run in batches, it was veryhard to learn how to write and test code. Now, a line of code can bewritten one moment, and tested in debug mode the next. This is alsothe ideal kind of environment for developing rules.

7. Individual rules are simple, but interactions between rules are complexand numerous. Tools are required to explore these interactions.

8. When rule systems become as complex as program code, you needseparate but equal parallel environments in which to develop each. Thecode must be tested against a known good copy of the rules, and therules must be tested against a known good copy of the code, or itbecomes very difficult to find the source of problems.

9. The rule authors are the most important people in the equation. Thismeans finding the right people and giving them the proper training andIT support.

It should be fun to be a rule author, in the same way that it’s fun to do crosswordpuzzles or to play chess. Each business requirement is a logical problem tosolve using the innovative rule authoring software. What makes this workdrudgery is not the logical analysis involved, but the tediousness of the work inencoding and testing the solution to a given business requirement. While ruleauthoring software will never compete with video games for entertainmentvalue, it should strive to give the authors satisfaction in their work by allowingthem to go from concept to realization as smoothly and as rewardingly aspossible.



Part IIIThe Technology Side of Business Rules

For the more technical audience, this section explores the role of rulearchitecture and rule architects, and delivering rules in state-of-the-arttechnology. It covers insights into the role of the rule architect on asystems development project (Chapters 9 and 10), delivering businessrules at an enterprise level (Chapter 11), achieving advanced rulematurity with BRMS technology at a major corporation (Chapter 12), howbusiness rule management leads to an enterprise policy hub (Chapter13), and a current option in rule management software that is not tied toa particular BRMS (Chapter 14).

Again, in their own words, each author selects quotes to provide thereader with insights into each chapter:

“Organizing thousands of rules, even hundreds of rules, is a challengingtask. The people, the process, and the tool are three key factors for thesuccess of the task, just as with accomplishing any other challengingtask. Therefore, this chapter covers: role of the rule architect,relationship of the rule architect to other architects, BPMS and BRMS,how best to write a rule, and how to express and organize rules in sets.”

Chapter 9, Gene Weng

Page 124 Part III: The Technology Side of Business Rules

“In today's growing global market where American companies areoutsourcing their key services and components, it is urgent for thetechnology and business operation managers to understand the risksinvolved in offshore outsourcing. The core of a business is its businessrules, which need to be protected from deliberate or accidental misuse.A well-defined business rules methodology, focused on business goalsand objectives, addresses most of the concerns.”

Chapter 10, May Abraham

“While the promise of BRMS is alluring, realizing the benefits requiresmore than finding rules and integrating a business rule engine….As[business rule] applications proliferate, it will be necessary to providestewardship and governance to support intelligent and consistent use ofthe technology. This is particularly true for those organizations that wishto truly embrace the Business Rules Approach and support multiplebusiness-driven projects, both individually and at an enterprise level.”

Chapter 11, Brian Stucky

“The ongoing ability to modify the business rules used to deliver resultsto the customers is a significant competitive advantage for Equifax.Once customers are exposed to the capabilities the rule-driven systemoffers, they gain a world of new opportunities.”

Chapter 12, Linda Nieporent


“The greatest ROI becomes possible when automating and improvingoperational decisions across the enterprise…the conversion of insightinto action through embedding executable rules and models directly intothe decision services used by applications. These models might bepredictive scorecards, decision trees, neural nets or rules derived fromgenetic algorithms. This is where the future lies, bringing true businessintelligence to operational decision-making… One of the greatadvantages to an enterprise policy hub is that it adds value to and workswith core technology trends, not against them.”

Chapter 13, James Taylor

“For the knowledge part [of RMM Level 2], the source rule repositoryneeds to store rules, at least in business-friendly form, with terms andrule clauses and grouped by decisions. But for the agility part, thesource rule repository must enable fast rule changes. Fast rule changesare possible to the technical rules in the BRMS, but the impact of thosechanges on the business requires metadata and traceability at businessfingertips.”


Page 126 Part III: The Technology Side of Business Rules

c h a p t e r


9 The Role of the Rule Architect in Organizing Thousands of Rules

Gene Weng

IntroductionOrganizing thousands of rules, even hundreds of rules, is a challenging task.The people, the process, and the tool are three key factors for the success ofthe task, just as with accomplishing any other challenging task. Therefore, thischapter covers:

• Introducing the role of the rule architect• Architecture: General• Architecture: Rule-specific• Relationship of the rule architect to other architects• BPMS and BRMS• How best to write a rule• How to express rules in sets• How to organize rule sets• Summary• Suggested topics to explore further• References

Introducing the Role of the Rule ArchitectFirst, a rule architect role should be established in the team; second, a rulearchitecture document should be one of the deliverables in the wholedevelopment process, and third, proper tools should be chosen for designingand documenting the rule architecture. The Business Rules Approach can beviewed as an application of the divide-and-conquer technique. By separating

Page 128 Chapter 9: The Role of the Rule Architect in Organizing Thousands of Rules

decision logic from application logic, business rules help reduce the complexityof any enterprise information system. However, a rule-based system can stillbe very complicated if there are hundreds or thousands of rules, even thoughan individual rule looks very simple. Without well-designed rule architecture,the overall decision rationale will be hard to understand and manage. Thesystem will be hard to maintain. Integration with the rest of the system is alsonon-trivial. Well-designed rule architecture will help the overall system to meetthese challenges.

Architecture: GeneralSoftware architecture as a concept came out in the 1960’s, but has increasedin popularity since the early 1990’s, due to the greatly increased complexity oflarge software systems. The Wikipedia article “Software Architecture” providesa short but comprehensive introduction.27

Software architecture can be viewed from different perspectives: asrepresentation, as process and as design. In this chapter, I’ll focus on thedesign aspect.

System architecture, infrastructure architecture, application architecture, anddata architecture are typical architectures in enterprise information systems.Rule architecture is another member of the family if a Business RulesApproach is applied.

Goal, requirement, constraint and assumption are major concepts associatedwith architecture. From the design perspective, goals are a set of objectives forthe architecture to achieve. Requirements must be satisfied by the architecturedesign; they can be functional and non-functional. Functional requirements arebusiness-specific. Non-functional requirements include performance,fault-tolerance, backward compatibility, forward compatibility, scalability,extensibility, reliability, maintainability, availability, serviceability, and usability.In many cases, architecture design is constrained by a certain number offactors, such as existing legacy systems. These constraints limit designchoices. Architectural assumptions further exclude other options.

From the design perspective, an architect’s task is to come up with anarchitecture specification based on goals, requirements, assumptions andconstraints. Unfortunately, in many cases, there is no optimal solution.Optimizing one aspect will have a negative impact on another aspect. For

27. Wikipedia.org, Software Architecture, http://en.wikipedia.org/wiki/Software_architecture

http://en.wikipedia.org/wiki/Software_architecture


example, a complex algorithm may be used to optimize performance. But themaintainability may be more difficult due to the complexity of the algorithm.Therefore, an architect carries out an architectural trade-off analysis.

The following steps serve as the guidance for the process of designing anarchitecture.

1. Define quality aspects, such as performance, maintainability etc.2. Prioritize quality aspects. Which aspect has more weight? It will help

make a decision when conflicts exist.3. Come up with different design options. Always try to think of

alternatives. No alternative means no choice. 4. Determine which design to use.

Architecture: Rule-SpecificAlthough the discussion on general architecture also applies to rulearchitecture, rule architecture has its own specific characteristics. Article 9 ofThe Business Rules Manifesto indicates business rules are “Of, By, and ForBusiness People, Not IT People.”28 Rule architecture should be businessfriendly.

One of the advantages of a Business Rules Approach is its simplicity. Thissimplicity allows your business rule applications to achieve two important goalsthat traditional applications are not able to: simplicity and agility.

Code base vs.Rule Base

The code base (e.g., SQL, VB, C/C++, Java, COBOL, etc.) in traditionalapplications is not easy to understand, even by technical developers. On theother hand, a rule base (i.e., a set of atomic executable rules) is much morecomprehensible. With a rule base, developers will not only understand theresults of a decision (driven by rules), but also the reasons for the results (i.e.,the conditions of the related rules).

28. Business Rules Group, The Business Rules Manifesto, Article 9. http://www.businessrules-group.org/brmanifesto.htm

http://www.businessrules-group


SystemExecution

Performance vs.System

DevelopmentPerformance

In many cases, response time is an important performance requirement forsystem execution. But the system development performance, i.e. the time fordeveloping a new system and for making changes to the existing system, isbecoming more and more important. Business rates of change cannot toleratelong system changes anymore. An easy-to-understand, straightforward designis often a better choice. Therefore, a rule architect not only needs to besensitive to system execution performance, but should also pay equal, if notmore, attention to the system development performance.

BusinessIntuitive vs.

System Thinking

Any software system, including a rule-based system, is a formalization, orabstraction of the real world. The Business Rules Approach allows businessanalysts and business rule analysts to participate in the entire process ofsystem development. Though in many cases business intuition may suggesta viable system design, business intuition should not replace critical systemdesign thinking and good software engineering principles.

Relationship of the Rule Architect to Other ArchitectsThe rule architect should work with other architects to define interfaces so thatrules interact with the rest of the system. The following is a list ofconsiderations in design.

1. Coupling withthe rest of the

system

Rule services can be embedded, tightly coupled, or loosely coupled. Forexample, a rule service can be a Java object called by another Java object(embedded). Rule service can be a Java Session Bean called by a Java client(tightly-coupled), or it can be invoked as a web service through messaging(loosely-coupled).

2. Rule servicegranularity

A rule architect must work with application architects or business processarchitects to agree upon the granularity of the rule services. One end of thespectrum is that each rule set is a rule service. The other end is all rule setsare organized by a rule flow and the rule flow provides rule services.Application developers who use rule services get maximum flexibility in the firstcase. But it brings challenges to rule developers: it’s harder to enforce policyconsistency. By contrast, the second case gives application developersminimum flexibility but makes it easier for rule developers to enforce policyconsistency. In most cases, the desired design will fall between the twoextremes.


3. API Intensivevs. Scenario

Intensive

In many cases, rule services are coarse-grained. That means that there are notmany APIs (Application Programming Interface) for rule services. However,rule services are likely to be scenario-intensive. For example, if a rule setevaluates 8 variables, then it has 256 different scenarios in the simplest case:every variable only takes true and false. A rule architect could use keyscenarios to communicate with the service users. A key scenario consists ofprimary variables and corresponding primary values that are most significant tothe business. For example, to determine a reasonable coverage amount for alife insurance policy, a set of rules could use a number of variables such ascoverage amount, age of insured, is the insured a smoker, etc. A sample keyscenario might be a coverage amount of one million dollars for a 40-year-oldperson with certain characteristics.

4. Data Model A data model specifies the data within the domain that rules need to reference.Rule base systems work best with certain kinds of data model or databasedesigns than others. For example, object and XML are two major approachesfor specifying data in hierarchical fashion. The rule architect needs tounderstand that, from a rule perspective, a flatter hierarchy (that is, fewerlevels) is usually better than a deeper one (that is, lots of levels). Navigating adeep hierarchy may necessitate multiple nested loops. Thus, the logic of therules becomes difficult to understand and to maintain. A rule architect shouldcommunicate strong preferences in data structures to the data architects asearly as possible.

BPMS and BRMSRecently, both BPMS (Business Process Management Systems) and BRMS(Business Rule Management Systems) are increasingly interesting toenterprise information system developers.

Three Scenariosfor BPMS and

BRMS

Consider three scenarios for a target system: only process-intensive, onlydecision- intensive, both process- and decision-intensive.

If the system is process-intensive only, (i.e. it does not have many rules), thena BPMS product may suffice, because most BPMS products provide somesupport for rules. However, BPMS vendors usually provide very limited supportfor rules, compared with rules support provided by BRMS software.

If the target system is decision-intensive only, (i.e. it does not have complexprocess flows), then a BRMS product may suffice. Most BRMS productssupport the concept of rule flows, which are needed for complex decisions.


Also, rule flows can be used to implement process flows. However, mostBRMS products only provide limited process flow support, compared withprocess flow support provided by BPMS software.

The most interesting and challenging case, naturally, is the third scenario: bothprocess- and decision-intensive. In this case, it’s still possible to deploy BPMSsoftware only, or BRMS software only. The problem with using BPMS softwareonly is that the rules are not separated from the process; hence, the processflows will be represented in a much more complicated way. The resultingprocess flows are hard to understand and manage. The problem with usingBRMS software only includes its limited support of the process flowmanagement.

Some vendors provide integrated software for both of business processmanagement and business rule management. Most vendors only provide onesolution. However, many BPMS vendors have established strategicpartnerships with BRMS vendors, and vice versa. These partnerships allowyou to integrate the specific strengths of BPMS software and BRMS software,although you need to assess the corresponding technology integration issues.

Regardless of your underlying software selection, a rule architect must workwith the process architect to clearly define the relationship between rulearchitecture and process architecture.

The RuleArchitect in a

BPMSEnvironment

BPMS and the representation of business processes are gaining popularity asthe logical view for system integration, especially in the service-orientedsystems. On the other hand, BRMS is never designed to be used as anintegration platform. From a system perspective, BRMS is seen as the platformneeding to be integrated. This does not mean that the rule architect should nothave a global view of the system. Instead, rule architects should work withbusiness process architects or application architects closely to enforcebusiness policy consistency across processes.


How Best to Write a RuleA rule architect should also provide guidance to rule developers on the bestway to express rules, in much the same way that data architects provideguidance on the best way to express data access requests using SQL(Structured Query Language). In both cases, some expressions that aresemantically equivalent will perform better than others.

For example, rule developers should typically avoid mixing “AND” and “OR” ina rule condition because doing so makes the rule harder to understand, andtherefore harder to maintain. A better approach is to reduce such a rule to aset of ORs.

For example, following this guideline, the rule below

if A and

(B or (C and D))then E

can be restated as

if (A and B) or

(A and C and D)then E


How to Express Rules in SetsRule statements, decision tables, and decision trees are metaphors, or popularways to organize and represent a rule set. Decision tables and decision treesprovide natural graphical view of rules. Readers can find more informationabout decision tables on http://en.wikipedia.org/wiki/Decision_table29

and decision trees on http://en.wikipedia.org/wiki/Decision_Tree.30

The following diagrams are also from Wikipedia:

Figure 25: Sample Decision Table

29. Wikipedia.org, Decision Table, http://en.wikipedia.org/wiki/Decision_table30. Wikipedia.com, “Decision Tree,”

http://en.wikipedia.org/wiki/Decision_Tree.9

http://en.wikipedia.org/wiki/Decision_table29


http://en.wikipedia.org/wiki/Decision_table



Figure 26: Sample Decision Tree

Decision tables (Figure 25) and decision trees (Figure 26) not only make rulecreation and modification easier, but also help human beings understand rules,and discover gaps in the rule set logic. Data mining algorithms and statisticalmodeling tools sometimes serve as sources of business rules, facilitated by thefact that decision trees are often the output of data mining algorithms andstatistical modeling tools. Due to the benefits as described above, always tryto consider organizing rules into a decision table or decision tree.

Unfortunately, not all BRMS products support these metaphors (decisiontables, decision trees), especially in the rule-base reporting functionality. Evenwhen these metaphors are supported, many BRMS product automaticallytranslate rules in these forms into regular rule statements when rules are savedinto the rule base or executed. In such cases, representing rules as decisiontables and decision tree in the design document is still beneficial.


How to Organize Rule SetsA rule architect should organize rules into sets based on a well-consideredmeaningful theme. This theme could be result-oriented (e.g., includes all rulesthat determine the value of a single variable), or condition-oriented (e.g.,includes all rules that determine the values of many variables but have thesame/similar condition), or business-specific grouping (e.g., by business line).

As an example, a result-oriented rule set may contain only rules that determinewhether a customer is qualified for a discount. This is the most common wayto organize rules into well-defined rule sets.

A condition-oriented rule set may contain rules having “order amount” in all oftheir conditions. In such a rule set, order amount is used as a major factor todetermine multiple outputs: eligibility of rebate, discount percentage andeligibility of free shipping etc.

The size of the rule set is another important consideration for design. Thoughthere is no upper bound for the rule set size, a rule set with more than 25 rulesis typically less manageable.

Rule SetDependency

Diagram

Individual rules are easy to change. The hard part is to make sure the changedoes not cause undesirable or unexpected side effects, due to the dependencyamong rules. Therefore, it is critical for a rule architect to draw diagrams of ruleset dependency.

Definition: Rule set B depends on rule set A if

1. Rule set A sets the value of a variable X and rule set B uses the variableX in its condition, as shown in Figure 27 or

2. Both rule sets A and B set the value for same variable X, as shown inFigure 28.

Figure 27: Rule Set A Sets the Value of X and Rule Set B Uses It


Figure 28: Rule Sets A and B Set the Value for X

An overall diagram of rule set dependency can be drawn based on thedefinitions above.

The overall rule set dependency diagram is different from the rule flow diagram.The rule flow design should follow the constraints defined in the diagram of therule set dependency. Theoretically, many rule flows are possible, given a ruledependency diagram, unless the diagram is linear. Therefore, ruledependency diagram can highlight more flexibility to rule flow/business processdesign.

Aggregate RulesBased on Change

Likelihood

If maintainability and time-to-market are high priorities, one way to achievethese design goals is to reduce the number of rule sets that need to change. Inmany cases, not every rule is equal in the sense of future change. Some rulesare more stable than others.

Figure 29:


Figure 29 shows that three rule sets, A, B and C, contain rules which havevariable X in their conditions or outcomes. If the variable X is not stable, i.e.,change requests related to X are frequent, then an alternative design couldreduce the number of rule set changes. One alternative design has 4 rule sets:D, A-D, B-D, C-D, where rule set D is the intersections of A and B and C. Inthis way, one rule set change is needed instead of three.

Summary of the ChapterThis chapter serves as an introduction to rule architecture and the importantrole of the rule architect. Rule architecture is a special case of the softwareapplication architecture. Therefore general principles of the softwareapplication architecture also apply to rule architecture. Rule architecture shouldbe business-friendly, meaning that it should help the business betterunderstand, manage, maintain and update decision logic. From a systemperspective, the rule architect should leverage strength of the Business RulesApproach: simplicity and agility.

Important guidelines from this chapter for the reader are:

• The rule architect is a critical role on a rule-based systems developmentteam.

• The rule architect should be closer to the business thinking than othertypes of architects.

• The rule architect should be concerned with system development andmaintenance performance, not just system execution performance.

• The rule architect is a key player in influencing important architecturaldecisions, including the coupling and granularity of rule services, optimaldata structure design, selection of BPMS and BRMS products, writingrules, organizing rule sets, and representing rule sets.

This chapter is not a rule architecture methodology. Instead, it provides a fewexamples to rule architects as inspiration in their architectural thinking.


Suggested Topics to Explore Further1. Architectural challenges when moving to upper levels of the Rule

Maturity Model.2. Architectural impact of emerging standards such as the semantics of

business vocabulary and business rules specification (SBVR).

ReferencesBusiness Rules Group, The Business Rules Manifesto, Article 9.http://www.businessrulesgroup.org/brmanifesto.htm

Wikipedia.com, “Decision Table,”http://en.wikipedia.org/wiki/Decision_table

Wikipedia.com, “Decision Tree,”http://en.wikipedia.org/wiki/Decision_Tree

Wikipedia.com, “Software Architecture,”http://en.wikipedia.org/wiki/Software_architecture

Wikipedia.com, “Software Architecture,”http://en.wikipedia.org/wiki/Software_architecture

http://www.businessrulesgroup.org/brmanifesto.htm

http://en.wikipedia.org/wiki/Decision_table

http://en.wikipedia.org/wiki/Decision_Tree




c h a p t e r


10 Building a Business Rules Architecture that Will Stand the Test of Time

May Abraham

The Climate of Today’s Global Market Requires a Business Rules Architecture In today’s growing global market where American companies are outsourcingtheir key services and components, it is urgent for the technology and businessoperation managers to understand the risks involved in offshore outsourcing.The article, "Managing the Risks of Offshore IT Outsourcing,”31 written bySteven R. Pozzi, senior vice president of Chubb & Son and chief underwritingofficer for Chubb Commercial Insurance is an eye opener. Pozzi writes thatcompanies that outsource information technology (IT) functions may facelawsuits if they don't take steps to protect non-public personal information. "Ifan employee of the contracting firm steals or misuses confidential or personalinformation that causes a violation of U.S. privacy regulations, the U.S.-basedclient would be the likely target of any lawsuits," he writes. "Outsourcingcontractors must meet U.S. and foreign mandates relating to privacy legislationand public disclosure laws, such as the Sarbanes-Oxley Act."

The question is: how can companies manage the risk when most of yourbusiness components are maintained and developed in overseas places likeIndia, China, and Eastern Europe?

In recent years, business rules and related service components have beengaining visibility and importance, both in the business and informationtechnology world. Experience proves that the abstraction and isolation of thebusiness logic from other parts of the system enables business areas to codify,maintain and manage rules as a reusable component of the application

31. Pozzi, Steven R., “Managing the Risks of Offshore IT Outsourcing,” computer-world.com/action/article.do?command=printArticleBasic&articleId=9000673

Page 142 Chapter 10: Building a Business Rules Architecture that Will Stand the Test of Time

environment. A Business Rules Approach helps mitigate the risk and helpsbuild technology services and business products with better service quality andsecurity. The core of a business is its business rules, which need to beprotected from deliberate or accidental misuse. A well-defined business rulesmethodology, focused on business goals and objectives, addresses most ofthe concerns. This Business Rules Approach needs to be driven by thecompany’s operations managers, and supported by a structured methodologyaimed at managing their core business knowledge. From this Business RulesApproach should emerge an appropriate business rules architecture for theorganization. This chapter covers:

• Delivering product strategy through business rules• What is business rules architecture?• Process, rules, objects and how they work together• How to identify a rule vs. non-rule• Guidelines for the business rule acquisition phase• Where and how to find business rules• Business rule analysis guidelines• Business rule implementation guidelines• Guidelines for defining an enterprise business rules architecture• Business rule design guidelines• Roles and responsibilities of individuals involved in business rules

architecture• The business process and rules architect• The business rules technical analyst• Systems integration engineer• The controversy of who owns the business rules• Summary

Delivering Product Strategy Through Business RulesAn appropriate business rules architecture can prove critical today in meetinga company’s marketing strategy, for example, enabling the introduction of newproducts faster and in a cost-effective way.

For instance, an insurance company can model the underwriting process andfacilitate the implementation of newly defined insurance products usingbusiness rules. After all, such a product is a way of packaging coverages,benefits, limitations, exclusions and cost in a way that meets a market need.


Each component of a product has its own rules, and these rules vary from stateto state. An appropriate business rules architecture can lay the foundation forproduct structure for various lines of businesses and allow for the dynamicconfiguration of new products. Business rules can serve as the building blocksfor various business components. Once these basic components and theirassociated rules are in place, they can be packaged in various configurationsto form new products within a given product line.

Business Rule Management Systems (BRMS) assist organizations inimplementing business rules services. Used appropriately, a BRMS allows abusiness user to better understand and, sometimes manage a subset of thebusiness rules, and perform sophisticated rule-related tasks. The latter mayinclude conducting “what if” analysis and regression testing before a product isreleased. These systems also support the prototyping of business scenarios,through rules, before the actual system is built. These techniques can be veryuseful for the business managers in their strategic planning efforts.

What is Business Rules Architecture?Loosely speaking, business rules architecture is the foundation by which anorganization will manage its business rules. This involves building a businessrules architecture that makes sure the business rules support businessobjectives and goals and can change on demand, as needed. For the purposeof this chapter, business rules architecture is the business rule foundationestablished by a business rules architect so that the collection of rules, at anytime, is well-understood and performs appropriately. If sufficient considerationis not given to the business rules architecture, the business rules can be indanger of being lost to the business, inconsistent, or perform poorly in targettechnology. So, it is important to understand the scope of the business rulesarchitecture and to define its pieces before beginning the business ruleacquisition. For enterprise-wide rules, a proper business rules architecture iseven more important. Aspects of the business rules architecture are:

• Identification of target rule sets (even before you know the rules!) andhierachical relationship among them, if appropriate

• Depiction of rule flow among related rule sets• Naming conventions for rules, terms, and rule sets• Templates for how to instantiate (express instances of a kind of rule) so

that different rule analysts express the similar rules in the same way• An understanding of which kinds of rules are implemented in which kinds

of technology


Process, Rules, Objects and How They Work Together Business rules are statements that define or constrain some aspect of abusiness process. They govern the way a business process is performed, andimplement the business or regulatory procedures and policies. Business rulesdynamically determine the outcome of a decision-making process, anddescribe the structure and relationships among business concepts.

Business rules are different from business objects, though both exist within anapplication. Business objects represent business entities (e.g., customers,products, etc.). Business rules implement the policies and practices of anorganization, and control the ways that business objects perform businessfunctions. Without business rules, business objects would have a hard-codedvalue for business credit, for example. Using business rules, the system can“reason” a value based on complex and timely criteria. These criteria and rulesmay vary from one customer to another or, in time, can often be changed in linewith business policy changes. Some examples where business rules applyare:

• Whether to increase customer credit• Whether to offer a customer a new product • Whether to create a new product• Determine exceptions within a process• Determine applicant ineligibility• Determine eligibility for special product features.

Analysis of a business operation always starts with articulating the businessprocess. The process has a flow (a workflow), and within the workflow arediscrete steps. Throughout the process there are business rules. Whether therules are about how work must be processed, where work must go, or who isqualified to process work, business rules are key to the process. Businessrules guide the process toward acceptable outcomes or to exceptions needingspecial attention.

How to Identify Rules vs. Non-rulesFollowing the Business Rules Approach, business and systems requirementsshould not contain buried rules. Instead, the rules should be separated, butconnected to other kinds of requirements. Harvesting of rules may include


careful study of all versions of the business requirements documents and thesystems requirement documents, in addition to discussions with the businessexperts.

What is Considered a Business Rule?Any statement that enforces relationships among data, enforces the collectionof valid data required to perform a business sub-process, or monitors thecorrect execution of a business sub-process is a candidate business rule.

The natural language itself can give clues about which statements might bebusiness rules. Often, statements that contain the following words can indicatebusiness rules:

Action words:

ASSESS, DIAGNOSE, COMPARE, EVALUATE, DECIDE, VALIDATE,DETERMINE, VERIFY.

More clues:

ALL, NEVER, ALWAYS, NONE, ONLY, ALTHOUGH, SHOULD, CAN, SOME,EVERY, UNLESS, EXCEPT, UNTIL

IF, IMPLIES, MAY, MUST, WHOEVER, WHENEVER, WITH/WITHOUT.

What is Not Considered a Business Rule?Statements that do not fit into the above categories are not likely to representbusiness rules, such as steps in business sub-processes that are alwaysperformed in the same way, tasks that don’t require “business knowledge” toperform, and system actions that can be programmed procedurally. Also,statements that are typically not business rules include procedural algorithms,database searches, and business or system events.

Guidelines for the Business Rule Acquisition PhaseThe business rule acquisition phase is the most time-consuming, but it is a veryimportant part of a business rules project. An experienced business rulesanalyst using a structured methodology seeks quality rules and traces them to


the business goals and objectives. The job of documenting businessprocesses at a detailed level will naturally expose the parts of the process inwhich rules are used.

Where and How to Find the Business RulesThe business rule analyst seeks a variety of knowledgeable rule sources suchas human experts, policy and procedures documents, data models, objectmodels, training guidelines, legacy code, and regulatory guidelines.

During the business rules acquisition phase, the business rule analyst extractsthe rule statements (expressed in natural business language) and associatesthem to a specific part of the business process. In the business rule analysisphase, the analyst transforms these rule statements into more structured anddetailed condition-action statements, as defined by the business rule architect.Often, a single rule statement will yield many condition-action statements. Therule design phase further transforms these statements into highly structuredexecutable rules.

Business Rule Analysis GuidelinesThe business rule analyst may find it helpful to group rules into sets; first, tohelp business people understand the rules in context, and second, to assistdevelopers in determining how the business rules are best implemented andused in applications. Ideas for useful rule groupings are below.

1. Presentation rule sets, such as:Data collection: Identify missing required information.

Simple field edits: Verify user input based on data available in memory.

Complex field edits: Verify user input based on data available in memoryand related data in permanent storage; determine which related dataneeds to be accessed.

2. Business process rule sets, such as:Attribute testing: Determine valid and required attributes for businessprocedures, policies and guidelines.

Threshold testing: Compare data values to high and low thresholds.

3. Algorithmic rule sets, such as:Reference data: Table values represented as individual rules.

Calculations: Complex computations and algorithms.


Business Rule Implementation GuidelinesThe implementation decision for business rules should focus on how the rulesare to be used and who is going to use them. Otherwise, the business rulesmay be lost and mismanaged if this decision is not made appropriately.

Today’s applications have a choice of implementing business rules in manyways, including in a BRMS, BPMS (business process management system),business objects, databases, software packages, or custom-developed code.

Determining whether a group of rules should be represented in a database ora rule base is often not easy to decide. The following guidelines might helpdevelopers make this decision:

If more than about 10 repetitive rules are required to validate the storing ofinformation, the valid values may be easier to maintain if placed in an externaldatabase table. For example, if there is a relationship between each state andcertain features of a product, it may be better to represent those relationshipsas a database table. If some rules involve testing data against thresholds, itmay be better to represent the thresholds in a set of rules in a rule base.

Guidelines for Defining an Enterprise Business Rules ArchitectureIt takes an experienced business rules architect to structure the business rulesin a way the business user understands. The business rules architecturefocuses on the business goals and objectives rather than the technology goalsand objectives. A well-defined business rules architecture communicates thebusiness strategies to the IT resourses.

Guiding Principles for Defining an Enterprise Business Rules ArchitectureThe following guidelines may assist a business rule architect in thedevelopment of a business rules architecture:

• Capture an expression of the business rules that is understandable,maintainable, and usable to the business user.

• Formalize and organize the business rules and rule sets (rule bases) in alogical structure, and make that structure available to the businesscommunity enterprise wide, and to the business analyst who will populatethem.


• Follow standard naming conventions for business rules and businessterms.

• Architect rule bases to minimize performance bottlenecks.• Define the implementation strategies and tools as a joint effort between

the business rules architect and technology architect. • Select technology and tools that best support the rules behind the

business problem, and allow business users to handle their coreknowledge to make better decisions, where possible.

• Use a structured methodology and establish metrics for measuring thequality of the business process and rules.

Business Rules Design GuidelinesBelow are tips for the rule architects and rule analysts for designing rule bases

• Design rule flow to follow the related use case sequence or to navigatebusiness product conditions.

• Use rule flow to sequence the maintenance and testing of rule sets. • Define a structure to group and package the rules into smaller rule sets

for optimum performance.• Parameterize rules coupled with database tables for repetitive table and

value set processing.• Structure decision tables to keep the business rules concise, and ensure

outer conditions do not result in significant duplication of data to avoidperformance penalties.

• Organize rules to allow expansion and specialization by businessfunctions like insurance products.

• Focus first on core rules to set the default standard for similar rules.Specialized rules will then become customized instances of the corerules, such as by state and industry class.

• Include for all rules the effective date, and manage versions of rule setsfor various effective time periods.


Roles and Responsibilities of Individuals Involved in Business Rules ArchitectureThis section provides an idea of the type of technical roles needed for abusiness rules project and how they interact with other project teams.

For organizations aiming for delivering enterprise business rules applications(RMM Level 3), consider establishing a Business Rules Center ofExcellence. A Business Rules Center of Excellence plays a key role inpromoting and establishing the Business Rules Approach and projectconcepts. This center can oversee all business rules projects and helpcoordinate and collaborate with technology teams and business groups. Tohead the group, a business rules project champion who has the experience inmultiple projects and has captured the best practices is of great value.

The following are the technical roles and responsibilities needed for businessrules projects.

1. Business Rules Architect 2. Business Rule Analyst3. Systems Integration Engineer

The Business Rules ArchitectThe Business Rules Architect is a new role that combines knowledge ofprocess and rules and business object model. The role of a Business RulesArchitect is to define the rule architecture, including rule object model and ruleflow for the business rules component under development. This role isresponsible for grouping related and segregating unrelated requirements,conceptualization of the business rule base architecture, and many otherarchitecture/design-related tasks. To perform this function, the Business RuleArchitect interacts heavily with the business analysts acting as domain expertsin the business requirements for the application under development.

The design responsibilities of the Business Rules Architect include, but are notlimited to, the following:

• Lead a series of business requirements analysis sessions, in concert withthe business analyst, through which the business requirements for thesoftware application under development are to be identified.

• Design and architect a business rule solution for the implementation ofthose business requirements, which includes definition of rule sets andrule templates.


• Design and specify implementation architectures for all business ruleswithin the software application under development.

• Supervise and direct the development of business rules and/or rule basesthat implement the business requirements described above.

The Business Rules Architect must have competence and experience inobject-oriented analysis (OOA), modeling, and all other aspects of the analysisand design of an application's object models. He/she must be able to designa business object model that is intuitive to business analysts, yet effectivelyrepresents the business data and processes of the application.

Business Rules AnalystThe Business Rules Analyst’s core competency is in the domain of thebusiness policies to be represented in the business rules of the application.This role is responsible for extracting, documenting, and analyzing all businessrules for an application. This position can be filled by a competent BusinessAnalyst who has been formally trained in harvesting and analyzing businessrules and business rule management technologies. This role works with theBusiness Process and Rules Architect and Systems Integration Engineerduring the requirements and design phases. This can sometimes be combinedwith a heads-down development role with an additional focus on generating thetechnical rules for the application under development. This role may also beresponsible for rules implementation and testing. The direction today,however, is often to separate the analysis role from the technical developmentrole.

Systems Integration EngineerThis individual is responsible for contributing to, and implementing, all of thedesigns specified by the Business Rules Architect. These responsibilitiesinclude implementing all interfaces to rules-based components, the businessobject model, and infrastructure components of the business rule bases.


The Controversy of Who Owns the Business RulesTo be politically correct, the corporation or government agency itself legallyowns the business rules that guide it. The question here is who, within theorganization, is empowered to steward those rules through their changes onbehalf of the legal organization.

There is always confusion in organizations as to who should have such powerover business rules (and business processes and business data). However, ina business-driven methodology for business rules, a company’s operationsmanagement drives the business rules projects. The operations managementstewards rule changes because the business rules are focused on theobjectives and the goals set by the business.

Unfortunately, more often than not, the stewarding business operations areadoes not have the organizational structure or resources to accommodate thebusiness process and rule analysis functions. In such cases, IT resources doso. Even so, the senior business executives and operations managers need toreview their current organizational structure and position themselves tomanage and steward the core business knowledge from a high level.

A well-trained business rules analyst who is a domain expert may beappropriate to steward the business rules and business process on aproject-by-project basis on behalf of the true business stewards.

SummaryThe success of a business rules project is based on a comprehensiveunderstanding of the business. The interrelationship of the business goals,objectives, metrics, organization structure, business processes, and decisionsis crucial knowledge to many business initiatives. Business rules are simplyanother aspect of business knowledge that now emerges as needing greaterintegration and attention, and to be available to the business community.

A better understanding of the business rules and business requirements alsohelps the technical communities develop better systems requirements andprevent scope creep.

Using a structured methodology helps define metrics for the quality of thebusiness rules and business process. Also, it reinforces the traceability ofbusiness rules to the business goals and objectives.


The most important points in this chapter are:

• Business rules should no longer be buried in business and systemsrequirements.

• The business rule acquisition phase is important, and is usually led by abusiness rule analyst.

• An enterprise business rules architecture is structured by a businessrules architect, who establishes standards for and organization of rulesets, while also assisting with technology selection.

• Business rules can be implemented in various ways, usually determinedby a business rule architect or analyst.

• A Business Rules Center of Excellence is helpful in establishing andpromoting a standard Business Rules Approach and technology.

• Proper stewardship of business rules belongs with the businessmanagement, but is often facilitated by IT analysts, due to a shortage ofbusiness resources.

c h a p t e r


11 Positioning the Enterprise for Business Rules: People, Processes, and Organization

Brian Stucky

The use of Business Rule Management Systems (BRMS) is growing at a rapidrate. Industry analysts predict a significant increase in the quantity of businessprocesses and applications built with the Business Rules Approach. As theseapplications proliferate, it will be essential to provide stewardship andgovernance to support intelligent and consistent use of the technology. This isparticularly true for those organizations that wish to embrace the BusinessRules Approach and support multiple business-driven projects, bothindividually and at an enterprise level.

While the promise of BRMS is alluring, realizing the benefits requires more thanfinding rules and integrating a business rule engine. The people responsiblefor managing rules, the processes required to ensure safe and consistentapplication and management of rules, and the organization that desires toutilize rules as a true corporate asset must all be positioned correctly.

Modern BRMS promise collaboration as a means to allow business andtechnical resources to communicate more easily. BRMS vendors often suggestthat business users will be able to take over many of the tasks previouslydedicated to technical resources. While the vendors now offer tools that bringthese promises closer to fruition, we are on the cusp of a business rulerevolution where a new resource—the business rule analyst—will play a criticalrole in the enterprise.

These same business rule analysts will be responsible for rule stewardship. Inthe simplest sense, stewardship deals with the standards and processesrequired to guide, monitor, and control business rules and all supportingmaterial through their life cycle. Specific roles and associated capabilities mustbe designed to ensure business rule correctness, consistency, and traceability.Pulling these roles together necessitates a new level of collaboration amongresources at many levels.

Page 154 Chapter 11: Positioning the Enterprise for Business Rules: People, Processes, and Organization

Finally, at the enterprise level, we need governance processes that emphasizethe consistency and quality of rules when viewed as a true corporateasset—how they are positioned to enable reuse across the enterprise. Thisgovernance must guarantee that activities surrounding business rules duringtheir life cycle are tied closely to the standards and operational models thatalready exist within an organization.

This chapter delineates the critical points across these three areas—people,process, and organization—that must be considered when an enterprisewishes to move to the Business Rules Approach. Therefore, the chaptercovers:

• The call for business rules• The starting point for business rules in the enterprise• People: The collaborative organization• Process: Stewardship for the tactical organization• Organization: Governance for the strategic organization• Summary• Key points

The Call for Business RulesThe benefits that are realized by moving to the Business Rules Approach havebeen discussed frequently. The notion of an agile enterprise, capable of rapidchange and continuous improvement of services, is appealing on many levels.The ability to handle rapid change facilitates both a quick reaction to dynamicmarket conditions and proactive launching of programs to achieve or maintaina competitive edge. However, this move to a zero time-to-market is only the tipof the iceberg in terms of the potential benefits brought by business rules.

Implicit benefits will be realized by the mere act of going through the rigor ofknowing all the rules and creating a complete and accurate list of them. Thisalone can pay huge dividends for an organization. The same rules often existin multiple places, are managed independently, and are frequently notsynchronized. This exercise of rule harvesting, elicitation, documentation, andanalysis is a critical step towards enabling consistency across systems in theenterprise.

More explicit benefits are possible because BRMS software has become moresophisticated. Facilities exist now so that business analysts can beempowered to write, manage and deploy business rules with little to notechnical intervention. With this capability, an enterprise is able to support a


true business-driven need for change. Now the individuals who havetraditionally been responsible for understanding the business can bring theirexpertise directly into production systems.

Ultimately we would like to view business rules as a true corporate asset—avaluable resource, accessible to all, that may be viewed as a common form ofcommunication. This truly collaborative platform can then be the springboardto a wealth of opportunities:

• Faster time-to-market• Simulation of various scenarios before implementation• Flexible and responsive reaction to customer needs• Increased ability to meet compliance and regulatory demands

The advantages of the Business Rules Approach are overwhelming. Softwareavailable to implement a BRMS has made tremendous gains over the lastdecade. Success stories are becoming more frequent. However, if nothingelse, this chapter should be viewed as a cautionary tale. Despite this greatpromise, the full advantages of business rules will not be reached simply bypurchasing software and setting about the task of finding the rules. There area number of areas that must be clearly understood and carefully consideredwhen attempting to bring rules to the enterprise.

The Starting Point for Business Rules in the EnterpriseAny discussion of preparing for rules must begin with the most important assetof an organization: the people. BRMS software is touted as the ultimate inenabling collaboration and providing a common platform through which allresources (business, technical, and management) may communicate.However, the need for people with a new set of skills is often overlooked.Finding, articulating, documenting, analyzing, implementing, testing,managing, and deploying rules necessitates people who are a little ofeverything—business analyst, technician, and manager. Only with theseindividuals in place will an enterprise become a truly collaborative organization.

Stewardship of rules is a topic of increasing interest but the term is still usedsomewhat broadly. It can best be viewed as the responsibility for taking goodcare of resources entrusted to one—the concept of “responsible caretaking.”What does this mean for business rules? It should mean the creation of atechnical, business, and management environment that can truly embracerules as a means to support rapid solution development and maintenance.


These encompass the tools and processes that must be in place so that anenterprise can safely, consistently, and accurately move towards anenvironment capable of rapid and immediate change. Only with theseprocesses in place for projects employing business rules will the truly tacticalorganization be enabled.

The final piece of the positioning puzzle is the idea of business rulegovernance. At this level, we move up from the tactical project viewpoint to thegoverning view of the enterprise. Governance defines the model to ensureoptimal reuse of services and enforcement of corporate policies. Ultimatelythese policies determine the long-term strategy and direction of anorganization. Many organizations do not have the necessary infrastructure inplace to support this need as it is best driven via a Center of Excellence orsimilar entity, variously called a Technology Center of Excellence or BusinessRules Center of Excellence. Only with this overseeing body in place can thetruly strategic enterprise be realized.

People: The Collaborative OrganizationOrganizations have traditionally cultivated a huge chasm between technicaland business resources. Often, the only form of communication between thetwo is requirements, and they are rarely in a form that is desired by both sides.With the modern BRMS offering a vehicle through which both business andtechnical analysts can communicate, we must consider whether eitherresource alone is sufficient. The ideal new resource would simply combinetechnical and business expertise. While this individual does not need to bedeeply technically oriented, he or she should be able to codify policy andexpress it logically in the forms of rules. While not strictly a business analyst,he or she must have a solid foundation in the business domain and be able tograsp business concepts. Business skills are more important, especially as theconstantly evolving and improving BRMS provides more of the necessarytechnical features. However, the mix of business and technical skills is stillcritically important to attain long-term business rule management success.

It is fairly easy to look at an individual placed in the new role of a business ruleanalyst and determine whether or not he or she is up to the task. It is not soeasy to describe a set of characteristics that will guarantee selecting the rightcandidate. As the adoption of business rules spreads, we will likely see morespecialized individuals trained and well-versed in the art of business rules. Fornow, consider the traits that would suggest someone has the potential to fill thisrole.


The business rule analyst will be responsible for handling rules throughout thebusiness rule life cycle. This means the business rule analyst will identify,harvest, document, analyze, implement, test, manage, and deploy rules.Consequently, he or she must first and foremost have a strong business ordomain background. This is probably more important than having a deeptechnical skill set. If an organization’s policy cannot be correctly interpreted,then implementation via business rules will not provide benefits. Technicalskills are most important in terms of logical analysis—taking policy andexpressing it formally so the correct decisions can be reached. A business ruleanalyst must have strong communication skills, as he or she and the BRMS willactually serve as the collaboration platform that brings business, technical andmanagement resources together. Finally, the business rule analyst must beable to pay close attention to small details while keeping the big picture in mind.Small enhancements that may seem to bring about a performance or clarityimprovement are of little value if they result in losing sight of the primary goals.

Process: Stewardship for the Tactical OrganizationThe enterprise that is able to approach zero time-to-market with business ruleswill have done so by acknowledging the need to create processes to enablestewardship. The areas discussed in this section are not presented as a howbut rather as a what. These are the areas that must each be explored andconsidered. The final look and feel of each may vary from organization toorganization, but they must be addressed in some fashion.

Development with business rules is inherently an iterative process. As simpleas that statement may seem, it can cause difficulties when this does not complywith the traditional means of development at an organization. However, it iscritical to acknowledge this characteristic and adapt accordingly. Rules willmove continually through a process of discovery, analysis, implementation,testing, and validation or deployment. Moving through this cycle with a rule orrule set will invariably result in restarting the process for other rules. Thishappens both through initial development and ultimately in a maintenancemode.

Like other software, business rules have a life cycle that usually varies from oneorganization to another. Defining and maintaining rules with respect to this lifecycle is critically important. Business rule analyst roles may be created thatpertain to various stages in the life cycle. Security may differ across differentpoints in the life cycle. The life cycle can be created with respect to the stateof a rule (draft, integrated testing, user acceptance testing, and deployment) ora path very specific to the domain in which they are created.


Rapid change and deployment via business rules is certainly powerful.However, this can place a huge burden on an organization’s changemanagement processes if frequent rule changes are not handled properly.Although speed is clearly a tremendous benefit, it is imperative to strike abalance between speed and control. Fast change that is uncontrolled andpotentially sloppy can result in extremely dire consequences. In large part, howthis is handled will depend on the enterprise architecture paths that are alreadyin place. Rules may be viewed as either code (they influence the logic ofprogram processing), or data (they are often persisted in a database and canbe viewed as the data required by a business rule engine). It is important foran organization to decide whether to manage rules as code or as data, simplybecause the change management processes for code tends not to be the sameas that for data. Regardless of the path, processes for versioning, metadata,persistence, deployment, security and testing must all be established.

Testing is sometimes overlooked in terms of its criticality in the business ruleprocess. If rules are to be deployed rapidly, and if business rule analysts areto make these changes, it becomes even more important to establish completetesting procedures to maintain the integrity of the ultimate production system.At a high level, testing should allow managers and business rule analysts toensure that rules being created or modified are, in fact, consistent with thepolicy they represent. We can view testing at four different levels:

• Syntactic: to ensure a well-formed rule that is readable by the system(most software has this level of testing already built in)

• Semantic: to ensure a specific rule behaves as desired• End-to-end: to ensure the rule still functions properly when viewed in the

larger context of a rule set or rule service• Simulation: to analyze the results of a policy change and predict the

impact on business.

While testing is a common and well-understood process for the technician, thisis not necessarily the case for the business or business rule analyst. Thefacilities created must be intuitive and comprehensive, and may includeregression test suites, measures of expected results, and tools that can assistin the analysis and understanding of errors that are detected.


Organization: Governance for the Strategic OrganizationAdoption of business rules over the past decade was often limited to individualprojects within an organization. In many cases, other areas of the samecompany ventured down the business rule road and ended up with acompletely different methodology for applying business rules—and in somecases with a different, potentially duplicated BRMS! However, the latestgeneration of software has been constructed with the enterprise view in mind.Consequently, more organizations are taking a global view when consideringbusiness rules. This can be extremely useful when addressing business rulegovernance.

Rule governance refers to the standards and processes needed to guide andmonitor business rules and all relevant artifacts through their life cycle. It ishere that we can begin to consider rules as a true corporate asset as they willbe integrated within the standards and operational models that already exist inan organization, and can then be partitioned to enable reuse across theenterprise.

Rule governance, especially across automated systems, can best beadministered by the creation of a Technology Center of Excellence. This samemodel may be used for various technology approaches (e.g., business processmanagement or business intelligence). The idea is the same: to providetechnology governance in alignment with the strategic direction of theenterprise. Although the title seems to focus on technology, these groups in thenew enterprise must increase business involvement to align technologycapabilities with the strategic direction of the business. This group must be thefocal point that serves as a clearinghouse for information that links people,processes, and the technology itself. Ultimately this group should encourageadoption and intelligent use of the technology.

A Business Rules Center of Excellence must clearly be a cross-disciplinarygroup that embraces both technology and business viewpoints. Perhaps noother technology purports to bring these two sides together as closely asbusiness rules. To that end, both sides must provide input to support intelligentand consistent use across the enterprise. A charter for this group might includethe following:

• Define the appropriate use of rules technology: when and where it shouldbe used

• Understand and articulate the business value of a rule implementation• Define rule conventions, standards, and best practices


• Understand and encourage rule reuse• Provide outreach and communication, internal and external

The group may be staffed in a variety of ways, but should include executivelevel sponsors representing both business and technical interests, a grouplead, leads from various areas including operations, architecture, staffing, andchange management, and diverse members from across the enterprise. Fillingseveral key roles can make the group more successful. The Advocate shouldbe an executive with high visibility in the enterprise. Ideally, this executive willbe from a business area or other non-technical division. The Evangelist shouldbe the group lead that becomes the face of business rules within theorganization. This person will be primarily responsible for outreach andcommunication to spread the word of business rules as often as possible. TheScientist is usually someone who serves as an enterprise architect and canguarantee adherence to corporate standards and guidelines as business rulesare integrated. The Visionary will continually look ahead for new methods,domains, and applications where the technology may be applied. Finally, nogroup is successful without enthusiastic members that both provide importantinput to the group and become disciples to take the message across theenterprise.

SummaryThe adoption of BRMS is rapidly becoming a core component of the advancedenterprise. The technology is well beyond the early adopter phase at this pointand is close to becoming a standard component in the corporate technologyinfrastructure. As the technology, methodology and software continues tomature, the case for enterprise adoption grows even stronger. The decision tomove to the Business Rules Approach will no longer be made by technologistson a project, but instead by executives desirous of fully utilizing business rulesas a true corporate asset. This is, after all, what the Business Rule Revolutionis truly about.

The great promise of business rules does not come without potential pitfalls.The wise enterprise will analyze and develop a solid foundation of people,processes, and organization in order to become the collaborative, tactical andstrategic, that can be realized with the integration of business rules.


Key Points

• BRMSs are becoming more mainstream.• Business rules are key to creating an agile enterprise.• Simply deciding to embrace business rules and purchasing business rule

management software is not enough to guarantee success.• New resource types and people skills are necessary to create a truly

collaborative environment.• Processes must be established for business rule stewardship to enable a

tactical enterprise.• The organization must create governance for business rules to facilitate

the strategic enterprise.


c h a p t e r


12 Achieving Rule Maturity for Competitive Advantage — A Case Study of Equifax

Linda Nieporent

IntroductionEquifax is a 107-year old global information solutions company that adoptedthe Business Rules Approach long before it was called “the Business RulesApproach.” This industry leader implemented business policies in code beforethe Rete algorithm was designed by Charles Forgy, and separated outbusiness policies into requirements documents well before the Business RulesGroup formulated standards around business rules and their relationship withsystems. Today, Equifax enables and secures global commerce through thedata and services it provides for companies spanning a wide range ofindustries, including financial services, retail, healthcare,telecommunications/utilities, brokerage, insurance and government.

The systems that Equifax has built to support its core business depend heavilyon business rules that enforce business policies. Equifax products aredesigned to help customers make informed decisions using the data it gathersand manages. Some of those decisions are internally driven by Equifaxpolicies, but many are dictated by external customers. A given customer makesa request to Equifax for a credit report and for decisions on a set of questions,based on criteria set by the client. For decades, Equifax has separated outbusiness rules from other aspects of its systems, both in requirements and inimplementation, to help manage the complexity of the number of rules and thedistributed nature of rule ownership. Initially, this was done on mainframe andmid-range systems in which Equifax managed rule separation by modularizingcode. The next generation was Decision Power, a client/server system in whichEquifax incorporated a home-grown rule engine, which did not allow businessuser authoring of rules.

Page 164 Chapter 12: Achieving Rule Maturity for Competitive Advantage — A Case Study of Equifax

The most recent advance is Equifax InterConnect, a credit decisioning platformbased on a J2EE architecture and ILOG’s JRules business rule managementsystem (BRMS). InterConnect is a hosted service that Equifax customersaccess to view, modify, test and deploy the business rules that help themdetermine when to offer credit, how much credit to offer and which credit risksto avoid.

With InterConnect, Equifax is further recognizing the benefits of a businessrules approach and business rules technology. InterConnect was inspired byincreasing demands from customers for better support for their complex andfrequently changing business rules. Customers were interested in viewing andchanging their own rules as needed. In addition, customers needed the abilityto manage change by introducing governance processes and ensuring thatrule authors understand the business implications of rule changes.

This chapter discusses the following:

• A recent history of business rules at Equifax• Why did Equifax select ILOG JRules?

• How is JRules helping Equifax?• How have customer experiences like Equifax’s influenced ILOG to

enhance JRules?• Lessons learned• What do Equifax customers think?• Looking ahead—InterConnect and JRules 6• Summary• References

A Recent History of Business Rules at EquifaxThe business of credit has changed significantly over the last 20 to 30 years.Until the late 1980’s, the credit reporting business was all about gathering datato build a credit history on consumers based on their payment history andinformation on loans, credit card accounts and other financial obligations. Theuse of this data was left to the judgment of individuals at banks, departmentstores and other businesses to determine the credit risk of a consumer. Theevolution of credit scoring in the mid- to late 1980’s shifted the emphasis fromraw data on a credit report to an integrated interpretation of the data. Scoringprovides an overall understanding of the individual’s credit worthiness andtakes into account, among other factors, the relative weight placed uponvarious aspects of the report.


Even with the introduction of scoring, utilization of credit reports was typically asimple system-to-system request for a credit report. In response, the entirereport was provided to the requestor with no additional intelligence about therelevance of any particular information in the report. This practice led toincreased demand for utilizing credit report data to make decisions that couldhelp institutions manage risk while increasing revenue opportunities. Equifaxworked with customers to develop batch processes that applied a set ofbusiness rules to sets of available consumer credit histories to determine listsof consumers to whom they would want to solicit business. This batch processwas useful, but customers were soon clamoring for more timely solutions.Equifax launched Decision Power in the early 1990’s to help customers takeadvantage of opportunities in cross-selling services to their consumers whilethey were involved in live interactions with the consumers. Initially, the goal wassimply to take existing offline batch processing business rules and make thedecision-making capability available in real time on an individual transactionbasis. When an individual was opening a bank account, the bank could requesta quick—and reliable—decision on whether, and on what terms, to offer a creditcard account or a line of credit.

Decision Power Decision Power was innovative in that it provided more than just the creditreport; it also delivered a response consistent with the requestor’s credit policy,e.g. “Approve the offer with a $2,000 credit limit” or “No, we have to deny theloan request because of x, y and z.” This resulted in a significant change in thebusiness of managing credit—from a time-consuming process requiringindividual judgment to an immediate and consistent result with a built-inexplanation. For example, creditors interested in tapping the sub-prime lendingmarket require more intricate logic, utilizing data from a broader set of sources.In sub-prime lending it is critical to manage risk appropriately. Many consumersthat were previously unable to secure credit were now able to do so, becausecreditors could distinguish more effectively among higher risk consumers.

As Equifax customers started to use Decision Power, greater opportunitiesbecame apparent. They developed more complex business rules to make finerdistinctions among potential borrowers and identified more situations in whichpolicies could be automated. They could expand from relatively easy creditdecisions to more complex ones, increasing revenue opportunities withinmanageable risk guidelines. Decision Power was a client/server based systemin which the business rules were hard-coded. The rules were separated fromthe other program code, enabling relatively quick modifications withoutintegration concerns, but changes still required Equifax IT intervention. Ascustomers became more sophisticated in their ongoing business rulerequirements, Equifax needed a new platform on which to support them—andInterConnect was born.


InterConnect Having moved beyond basic separation of business rules in specificationdocuments and in program code, Equifax identified the need for a business rulemanagement system as a core component of its new platform. Equifax neededa system that enabled it to:

• Deploy business rule changes quickly and without system disruption.• Give customers the power to edit business rules and make changes to

rules as needed. This required exposing business rules in abusiness-friendly language that resources outside of the IT departmentcould easily understand.

• Provide real-time responses at high-volume transaction loads.• Easily integrate the decision making components of the InterConnect

platform with other modules.

Figure 30: Business Rules at Equifax


Why did Equifax select ILOG JRules?Once Equifax decided upon the incorporation of a business rule engine into itsInterConnect platform, the company settled the “build vs. buy” question quickly,due to the availability of good commercial options and the inherent complexityof a rule engine. Because the rule engine would be a central and criticalcomponent of InterConnect, Equifax carefully considered the choice of vendor.Beyond the basic technical requirements, Equifax was seeking a relationshipwith a vendor who would work closely with them to ensure their success. InJRules, Equifax found a solid rule management platform with built-in flexibilityand excellent performance. In ILOG, Equifax found a partner willing to work withthem on extensions and customizations as needed and willing to listen toongoing requirements as Equifax’s own solution matured. Today, Equifax andILOG continue to share product roadmaps to ensure they align as much aspossible.

"Whenever we had a problem or needed a feature/function, ILOG wasvery accommodating and worked with us to ensure our success."

Fred Hughes, SVP Strategic Development, Equifax

How is JRules helping Equifax?Equifax depends on several key features of ILOG JRules in the InterConnectplatform.

HighPerformance Rule

Engine and RuleExecution Server

(RES)

Equifax considered performance an important criterion when selecting aBRMS. Equifax customers expect an average response time of no more thanthree seconds for execution. As an application service provider (ASP), Equifaxexpects to be able to handle 50,000 transactions per hour, with a reasonableinfrastructure. Starting with its latest InterConnect release on JRules 5.1,Equifax takes advantage of Rule Execution Server (RES), which providesmanaged deployment with enhanced ruleset management, J2EE role-basedsecurity, and cluster management.

BusinessUser Rule

Management

Equifax’s business users are not Equifax employees, but rather employees ofEquifax customers. As an ASP, Equifax manages the core environment,development and maintenance of customer systems, with business rulemaintenance performed by the customers themselves. During the initial setupof a customer implementation, an Equifax project team works with the customer


to identify the necessary data sources, capture and implement the initial set ofrules, and train customer personnel on using the system, including businessrule maintenance.

Equifax uses the JRules Web Rule Editor as the interface for its businesscustomers. As Equifax migrates InterConnect to JRules 6, this interface will bereplaced by JRules Rule Team Server, providing a rule authoring environmentdesigned specifically for business users in a friendly web-based application.Rule Team Server provides enhanced repository support with role-basedpermissions on a relational database repository, history tracking, baseliningand rollback, and productivity tools such as queries and smart views.

Different customers place different demands on the rule maintenanceenvironment—some change rules weekly, some monthly; some plan theirchanges well in advance, while others need to react more quickly to businesspressures. What is universally important is that they can change the rulesthemselves, on their own schedules, and in a way that isn’t disruptive to theoverall application.

Making significant changes to business rules generally takes time, ascustomers must first become confident with rule management. At first, they willlikely focus on simple changes such as adjusting acceptable score thresholds.As they grow more comfortable with such changes and become more confidentwith the tools, they will start to make more complex changes, such as addingand removing conditions or adding entirely new business rules.

"Our clients' first implementations have become trivial; customers arebecoming more and more comfortable with complex rules involving mul-tiple data sources and they can more confidently make decisions onriskier consumers."

Sandeep Gupta, VP B2B Software Development, Equifax

Flexibility in RuleLanguage and

Artifacts

Flexibility was also a critical factor in Equifax’s selection of JRules. Workingwith ILOG JRules 4.x and 5.x, Equifax has customized the user interface forcustomers in several ways. Some customizations are to assist in the initialproject startup phase and others are for ongoing rule maintenance by businessusers. Since Equifax provides much of the data used by each customer, theyhave pre-built business object models (BOMs) representing common datasources. They use plug-ins to import and merge the BOMs required for a givenproject, along with any specific data sources the customer is introducing, to setup the rule authoring environment. They also make available a set of starter


tasks, such as “Pull Equifax credit report,” that are commonly used but can bemodified, to speed the model build process. Since many of the variables usedin business rules are also common, and can require complex definitions,Equifax has incorporated a mechanism to re-use variable definitions acrossbusiness rules. To expand upon the types of rules that can be captured andmanaged, they have created a custom business rule language, incorporatingtheir own proprietary grammar for certain rule types, using the JRules BusinessRule Language Definition Framework (BRLDF). For developer testing, theyhave integrated JUnit testing into the Rule Builder (the developers’ ruleauthoring environment).

How Have Customer Experiences Like Equifax’s Influenced ILOG to Enhance JRules?ILOG is constantly seeking feedback from customers on how to improve itsproducts, and many of these enhancements are evident in ILOG JRules 6.Although Equifax tends to be a “power user” of ILOG JRules BRMS technology,they share requirements with many ILOG customers. In continuing tostrengthen a BRMS from the base of a rule engine and basic rule editingfacilities, ILOG has established four foundational capabilities for its BRMSproducts:

• Full empowerment for business teams• Full productivity for technical teams• Synchronized full life-cycle business rule management• Unequalled performance

Full empowerment for business teams means that business users can:

• Satisfy regulatory and business imperatives for security, traceability andauditability of policy changes

• Learn business rule management quickly• Author, maintain, and deploy business rules directly, safely, and

confidently

Full productivity for technical teams means that developers and architects can:

• Apply corporate development standards, best practices, and processes toapplications that incorporate business rules

• Master business rule management quickly, working with familiartechniques


• Integrate BRMS naturally and natively within current and future technicalinfrastructures

Synchronized full life-cycle business rule management enables both teams to:

• Work on several release cycles simultaneously, maintaining the releasein production while preparing the next minor release and the next majorrelease

• Share and reuse rules among rule authors with different professionalbackgrounds and languages

• Ensure confidence and control over the rule management life cycle

Lessons LearnedWith InterConnect’s second major release due out in 2006, and morecustomers moving to the platform each quarter, Equifax shared some “lessonslearned” with ILOG that could help others embarking on building business rulessystems.

• Keep the system flexible: Equifax credits much of InterConnect’ssuccess as well as its ability to plan for major product enhancements to aflexible approach to business rule management. ILOG JRules is designedprecisely for such flexibility, but make sure that the other components areintegrated in a way that doesn’t obstruct the natural flexibility of arules-based approach.

• Employ good governance: Good governance over business rulechange must not be overlooked. This is critical whether the peoplechanging the business rules are within the company or in an externalorganization, such as is the case with Equifax systems. For a typicalEquifax customer, a small mistake in a rule change could have significantfinancial implications. While you want to keep the governance processagile to ensure changes can be quickly accommodated, don’t skimp onthe approval process.

• Provide testing and simulation tools: Testing and simulation are criticalto business user confidence in exercising control over productionbusiness rules. Business users themselves are often the driving forcebehind putting business rule changes in the hands of policy makers.However, once given that power, many are skittish about implementingchanges that could have negative side effects. Once they becomecomfortable making such changes, the natural evolution is to work on howthey can make their rules better. Using historical data and simulationcapability, business users can perform what-if analysis on potential rule


changes and improve the rulesets they deploy. Incorporating a testing andsimulation module into InterConnect became an important priority for thesecond major release of the platform.

• Know your data: At Equifax, one impact of exposing business usersmore directly to business rules and enabling them to change them hasbeen an explosion of data sources used. One of the ways in whichbusiness customers expand and increase the complexity of their businessrules is to utilize data from additional sources. This requires carefulmanagement of the overall set of data, organized into one or more BOMsthat are the basis for the business rules written.

• When investigating technology, think broadly: As you mature in thediscipline of business rules, your technology needs will move beyondbasic rule authoring and a business rule engine to a broader BusinessRule Management System, with an emphasis on longer-term rulemanagement, business user tooling and testing and simulationcapabilities.

• Pay attention to processes for development and deployment: Due tothe nature of BRMS technology, particularly the intended redeployment ofbusiness rules as they change, processes for development, deploymentand change management may need to be revised.

• Train your people and utilize expert resources as needed: Thisapplies both to the IT resources involved in the initial development of thesystem and to those people who will be involved in maintaining the systemon an operational basis. Operational teams should be involved from thebeginning of the development process. Equifax focused mainly onensuring its internal resources gained the skills needed to build andmaintain the system but also worked with ILOG professional services toensure that key pieces were done optimally. Finally, do not forget thebusiness analysts and business people who will be involved in designingand maintaining the system.

What do Equifax Customers Think?Equifax customers are the true end users of the InterConnect system. Thebenefits to banks, credit card issuers and telecommunications companies thatrely on InterConnect to make decisions about what they can and should offerto prospective (and existing) consumers are substantial. The speed with whicha customer can be initially set up on the system, due to the core infrastructurein place and an established and repeatable process of gatheringcustomer-specific requirements, makes the solution a compelling choice. Theongoing ability to modify the business rules used to deliver results to the


customers is a significant competitive advantage for Equifax. Once customersare exposed to the capabilities the rule-driven system offers, they gain a worldof new opportunities.

"Providing our bankers with tools that help them make more informedcredit decisions is critical to helping us provide world standard serviceto our clients and manage risk. InterConnect, Equifax's business rulesmanagement system, gives us a powerful solution that fits well with ourfront-end system, custom models and SBFE interface."

Carlos Goodrick, Senior Vice President and SBB Risk Manager, BB&TSmall Business Banking

Looking Ahead—InterConnect and JRules 6At its core, the Business Rules Approach is about bringing business and ITgroups together—aligning goals, enabling collaboration and producing a betterresult by focusing on business user-defined business logic. That logic isimplemented in systems that, by their nature, are maintainable with continuedbusiness/IT collaboration. JRules 6 embodies the spirit of this approach. Eachnew module of JRules 6—Rule Studio, Rule Team Server, Rule ExecutionServer, and Rule Scenario Manager—offers additional value to Equifax aboveand beyond that already realized with previous versions of JRules.

Rule Team Server is a highly scalable rule management server and repositorywith a collaborative web environment for authoring, managing, validating anddeploying business rules. Rule Team Server provides enterprise-class contentmanagement for rules.

• Rule Team Server’s (RTS) core business user focused capabilities, pluscustomizable look and feel and extension points, will allow Equifax to useRTS as the public face of InterConnect.

• Business rule management capabilities (versioning, baselinemanagement, role-based permissions) of Rule Team Server will enhanceEquifax customers’ ability to successfully manage their rule changes.

Rule Scenario Manager delivers powerful ruleset testing and businesssimulation capabilities. Rule Scenario Manager provides an integratedenvironment for verifying the correctness of rules and simulating changes inbusiness policies. Customizable, it can be tailored to enterprise data stores,deployment processes, and reporting requirements.


• Equifax is investigating how best to incorporate Rule Scenario Managerinto InterConnect to provide further capabilities to end users for testingand simulation.

Rule Studio is an integrated development environment (IDE) for ruleapplications. Rule Studio fits directly into the Eclipse family of IDEs, whichincludes the Eclipse IDE, IBM Rational Application Developer and IBM RationalSoftware Architect, BEA Workshop, and others. Rule Studio supports rulesetdebugging and deployment to ILOG JRules Rule Execution Server, andenables collaboration among business rule authors through Rule Team Server.Benefits to Equifax include:

• Management of multiple/composite BOMs, particularly important to anASP solution such as InterConnect, is made much easier.

• Establishing dependencies among projects to create composite projectsthat share existing components (BOMs, rulesets, templates, etc.)provides needed flexibility in designing applications. Equifax can moreeasily segment projects by customer while maintaining common BOMinformation and templates for all customers.

• The move to the Eclipse platform provides automatic integration withJUnit as well as other Eclipse-based functionality such as source codecontrol systems.

• And for continued individual or forward-thinking extensions, developerscan take advantage of the Eclipse plug-in framework combined with ILOGJRules’s inherent flexibility.


Rule Execution Server is a robust J2SE- and J2EE-compliant managed ruleexecution environment. Rule Execution Server is used to deploy business ruleSOA services to the leading web and application servers from IBM, BEA,JBoss, Oracle and Apache. Rule Execution Server includes a webadministration console and components for synchronous, asynchronous andweb service-based invocation of business rules. Rule Execution Server is fullyintegrated with Rule Studio and Rule Team Server to support business ruledeployment for both developers and policy managers.

• As an application service provider, the reliability and ease ofadministration in Rule Execution Server solidify Equifax’s confidence inILOG JRules as an integral component of InterConnect.

Figure 31: Major features of JRules by release


Summary• Equifax’s journey to fulfilling the full promise of a Business Rules

Approach has been a long one.• Success has been found along the way, increasing over time to create a

flexible and efficient IT infrastructure and a platform that providesenormous business value to Equifax and its customers.– Initial separation of business rules from other specifications and code

enabled Equifax to respond to customer demand for changes relativelyquickly.

– Further separation with Decision Power and improved technology enabledreal-time responsiveness with automated decisions.

– InterConnect leverages a full BRMS to empower business users andfacilitate enhanced back-end processing.

• At this stage, Equifax has the tools and the business experience to focuson maximizing business value by:– Putting more rule authoring and management in the control of policy

managers.– Enabling policy managers to create the best rulesets through testing and

simulation.– Managing a smoothly running, high performance execution environment.

• The capabilities Equifax can offer with ILOG JRules at the heart of itsInterConnect platform have changed the way its customers do business– Better decision-making capabilities enable creditors to increase their

customer touch points and the types of products they can offer.– Effectively managing business decisions through rapid deployment of

business rules provides creditors the ability to take advantage of newbusiness opportunities as they arise.

– Repository and administrative tools help Equifax and its customers managechange and complexity, freeing them to focus on the content of businessrules more than the processes used to manage them.


ReferencesMoore, Ariana-Michele. “Business Rule Management Systems and FinancialServices: Equifax as a Case Study.” Celent Communications, 2005.http://www.celent.com.

About Equifax (www.equifax.com)Equifax Inc. is a global leader in information technology that enables andsecures global commerce with consumers and businesses. We are one of thelargest sources of consumer and commercial data. Utilizing our databases,advanced analytics, and proprietary enabling technology, we provide real-timeanswers for our customers. This innovative ability to transform information intointelligence is valued by customers across a wide range of industries andmarkets. Headquartered in Atlanta, Georgia, Equifax employs approximately4,600 people in 13 countries throughout North America, Latin America andEurope. Equifax was founded 107 years ago, and today is a member ofStandard & Poor’s (S&P) 500® Index. Our common stock is traded on the NewYork Stock Exchange under the symbol EFX.

About ILOG (www.ilog.com)ILOG delivers software and services that empower customers to make betterdecisions faster and manage change and complexity. Over 2,500 globalcorporations and more than 465 leading software vendors rely on ILOG’smarket-leading business rule management system (BRMS), optimization andvisualization software components, to achieve dramatic returns on investment,create market-defining products and services, and sharpen their competitiveedge. The BRMS market share leader, ILOG was founded in 1987 andemploys more than 700 people worldwide.

Trademark notices:

ILOG, CPLEX and the ILOG logotype are registered trademarks, and allILOG product names are trademarks of ILOG.

Equifax and Equifax Decision Power are registered trademarks, andInterConnect is a trademark of Equifax Inc.

All other brand, product, and company names are trademarks orregistered trademarks of their respective holders.

http://www.celent.com

c h a p t e r


13 Implementing an Enterprise Policy Hub

James Taylor

Beyond Productivity Gain to Enterprise Policy HubsThere are two main ways to apply a business rules management system(BRMS). The first is to consider the Business Rules Approach as a way to gaindeveloper productivity, both for initial development and for subsequentmaintenance. Such productivity gains have proven to be significant—up to a75% reduction in ongoing maintenance. This deployment of a BRMS is similarto introducing a new, high-level programming language effectively.

The second way to apply a BRMS is to focus on decisioning as a new andemerging class of business problems, and on how an organization can best usethe Business Rules Approach and a BRMS as a platform for automating andimproving its critical operational decisions. This deployment of a BRMS is bothstrategic and visionary, resulting in an enterprise policy hub: strategic, becausethe automation of critical, yet frequently very distributed, decisions can have asignificant impact on revenue, loyalty, customer acquisition, customer retentionand more; visionary, because fundamentally making better decisions at allstages of the customer life cycle has equally significant impact on the entirebusiness.

Although the Blaze Advisor™ business rules management system is anexcellent product in both scenarios, this chapter focuses mostly on the benefitsof applying the Business Rules Approach and a BRMS for developing anenterprise policy hub, including practical advice for developing such adecisioning backbone. Therefore, the chapter covers:

Page 178 Chapter 13: Implementing an Enterprise Policy Hub

• The Blaze Advisor business rules management system• Key strengths and features of Blaze Advisor• Blaze Advisor customers• Definition of an enterprise policy hub• Benefits of an enterprise policy hub• Best practices in implementing an enterprise policy hub• Integrating an enterprise policy hub with BPM, SOA, and BI• Conclusion and customer quotes

The Blaze Advisor Business Rules Management SystemThe Blaze Advisor™ business rules management system (BRMS) from FairIsaac Corporation is a complete solution for enterprise business rulesmanagement, involving rule service design, authoring, testing, servicedeployment, and maintenance. A rule service, or a decision service, can bedefined as a monolithic view of all the conditions and actions that need to beconsidered in performing a self-contained, callable decisioning process as aservice function from a larger application. In a service-oriented architecture(SOA), these decision services are common in the business service layer, asshown in Figure 32. They might be exposed from within legacy applications ordeveloped as business services.

Figure 32: The Role of Decision Services in SOA

To create decision services, Blaze Advisor has a number of softwarecomponents that interact with business applications and data. Thesecomponents include an integrated development environment (IDE), generated


rule management applications (light, web-based applications for editingbusiness rules in a non-technical way), a rule repository, a rule server andengine, and SmartForms for Blaze Advisor. These components fit together todeliver a complete business rules management system as shown in Figure 33.It is important to understand the role of these components before explainingtheir use in an enterprise policy hub.

Figure 33: Overview of the Blaze Advisor Environment

1. Integrated Development Environment (IDE)Decision services are defined using Blaze Advisor’s IDE. The IDE is acomplete environment for decision service design, rule authoring, ruletesting, creating rules management applications, and for specifyingdesign templates for rules (covered in more detail later). The IDE alsoconnects directly to enterprise or external data sources and webservices to allow the rule service to use these when executing decisions.The IDE is available in six European and Asian languages.

2. Rule Management ApplicationsBlaze Advisor rule management applications allow controlled ruleediting and creation by non-technical users through standard webtechnologies. These template-driven applications expose some or all ofthe rules for controlled editing by non-technical users. These rules canbe changed in running systems directly or through a formal releaseprocess.

3. Rule RepositoryBusiness rules are maintained in a Blaze Advisor rule repository thatprovides the runtime service with the latest definitions of rules, asupdated by the development environment and maintenanceapplications. The repository provides versioning and management


services across all the components. The Blaze Advisor repository iscommon across all Blaze Advisor supported platforms (Java, .NET andCOBOL).

4. Rule Server and EngineWhen an application asks Blaze Advisor to perform a decision service,it is executed using the Blaze Advisor Rule Server and Engine. The RuleServer manages scalability, multiple service requests, rule updates, andmore. The Engine executes the rules with best-in-class performance. Inaddition the Engine can access necessary data sources or services toobtain information as and when needed to perform the service.

5. SmartForms for Blaze AdvisorSmartForms for Blaze Advisor allows rule services to publish aweb-form based GUI to collect data from a human user. The formsgenerated use a rules-based approach to collect and verify data, takingadvantage of the X-Forms standard to deliver next-generation HTMLforms and of AJAX to maximize responsiveness. The use of rules forguided data capture ensures that necessary data is captured andunnecessary data is not.

Key Strengths and Features of Blaze AdvisorBlaze Advisor is well-recognized as having the following strengths in thebusiness rules marketplace:

• Extensive history and experience• Heterogeneous environment support for Java, .NET and COBOL• Powerful rule repository• Top-of-the-line performance• Extensive integration capability• Patented rule management application generation• Predictive analytic models

Extensive historyand experience

Blaze Advisor today is the result of over 20 years of experience in developinga platform for expert systems and business rules management. The currentproduct was built from the ground up 10 years ago and is now mature andstable. Not only does it have a consistent history of major and minor productreleases over that time, Blaze Advisor is consistently the first product tointroduce new innovations in the business rules marketplace and to embracestandards. For instance, Blaze Advisor was first to introduce the rule flow,


decision tree and scorecard rule-entry metaphors. Blaze Advisor is widely usedwith over 500 customers worldwide and is, in addition, a platform for all othersoftware application development at Fair Isaac.

Heterogeneousenvironment

support for Java,.NET and COBOL

Blaze Advisor is unique in its ability to operate in today’s heterogeneousenvironment. Not only is a complete rule development and maintenanceenvironment available for both the .NET and Java environments, the executionof business rules is supported on .NET, Java Standard Edition, and JavaEnterprise Edition as well as COBOL. The product also has a single syntax andcommon enterprise-class rule repository across all platforms, allowingbusiness rules to be shared across all three deployment environments from asingle repository.

Powerful rulerepository

The repository itself supports, and ships with, best practices for developing astructured, management environment for business rules. Through the additionof management properties, it supports an extensible meta-model that can becustomized by organizations to meet their unique needs and methodology. Inaddition, powerful queries and actions for repository reporting andmanagement, along with release management, are provided directly from theIDE, making it practical to manage business rules across large enterprises.

Top-of-the-lineperformance

Top-of-the-line performance is available on both .NET and Java, with the mostadvanced inferencing algorithm on the market (Optimized Rete or Rete III), inaddition to the unique compiled sequential mode optimized for sequential ruleexecution. COBOL code generation ensures that legacy CICS/mainframeenvironments can leverage business rules with maximum performance. Inaddition, Blaze Advisor allows for different, appropriate, rule evaluation modesfor each rule set, providing both flexibility and performance.

Extensiveintegrationcapability

Blaze Advisor has a strong commitment to standards and open technologiesacross Java, .NET and COBOL. In the Java world, it supports J2SE and J2EE,along with WebSphere, WebLogic, Sun ONE, Oracle and JBoss applicationservers. It allows reading and writing of data from all leading SQL databases,XML schemas/documents, and external web services. It is easy to integratewith Business Process Management Systems and offers integrations withFileNet, Lombardi, Metastorm, DST, webMethods, Savvion, Fujitsu, OracleBPEL and more. With Blaze Advisor, you will not have to change yourenvironment to take advantage of business rules. In addition, Blaze Advisorprides itself on having a small memory “footprint.”


Patented rulemanagement

applicationgeneration

The rule management applications generated from Blaze Advisor, based on itspatented template technology, provide unique interfaces specifically designedfor business user rule authoring and collaboration. Rule maintenance is doneonce and deployed anywhere through the shared repository. This enables bothbusiness and information technology (IT) professionals to effectively managethe rules in a central repository, regardless of deployment complexity ormanagement environment. Blaze Advisor rule maintenance applications allowcontrolled rule editing and creation by non-technical users through standardweb technologies. These template-driven applications expose some or all ofthe rules for controlled editing by non-technical users.

Predictiveanalytic models

Fair Isaac’s unique experience in combining business rules with powerfulpredictive analytic models is shown in the analytic integration offered by BlazeAdvisor. Not only does this allow the mining of business rules from data, it alsoallows for executable predictive analytic models to be brought directly to bearin decision services for true enterprise decision management. Fair Isaac’sanalytic tools allow for the conversion of insight into action, through embeddingexecutable rules and models directly into the decision services used byapplications. These models might be predictive scorecards, decision trees,neural nets or rules derived from genetic algorithms. This is where the futurelies: bringing true business intelligence to operational decision-making.

Blaze Advisor CustomersBlaze Advisor is in use at hundreds of companies and government agenciesaround the world, from banking and insurance to telecommunications andmanufacturing; from underwriting and origination to fraud detection, taxes andnetwork configuration. Organizations like Auto Club Group, CaliforniaDepartment of Motor Vehicles, Walgreens Health Services, British Telecom,egg, Unitrin Kemper, First Data, The Hartford, Sun Microsystems, and DellFinancial Services all deliver 24x7, mission-critical production decisionservices through Blaze Advisor-based systems.

• Auto Club Group is using Blaze Advisor for precise and consistentproperty and casualty policy quotes and uniform underwriting decisionsacross seven states.

• At the California Department of Motor Vehicles, Blaze Advisor drivesmodernization of legacy systems to deliver $4 billion dollars in vehicleregistration fee calculations that are accurate and consistent statewide.

• Unitrin Kemper uses Blaze Advisor for real-time, risk-based underwritingof new business, a lowered combined ratio, reduced underwriting losses,and improved targeting of new business.


• First Data Corporation uses Blaze Advisor™ business rules managementsystem for “Merchant Scoring”—analyzing merchant and agent data formore than 4,000,000 merchants who process daily transactions for theircustomers.

• Sun Microsystems uses Blaze Advisor to minimize customers’ informationtechnology risks, by empowering over 9,000 people around the world toidentify and mediate potential IT issues (system configurations, firmwareand software patches) before they can affect system downtime.

• egg’s award-winning Blaze Advisor system provides coordinated creditrisk decisions, reducing the amount of manual interventions and reducingthe time for rule change from 35 days to 2 days.

• British Telecom uses Blaze Advisor for its Transform Operations SupportSystem. Blaze Advisor remotely configure the organization's networkdevices, based on customer orders and configuration requests.

• Air Products uses Blaze Advisor to ensure accuracy of material mastercreation for its SAP implementation – the largest in the world.

• Walgreens Health Services uses Blaze Advisor rules to alert a pharmacistto potential adverse drug interactions. Drug interaction rules may bebased on patient age, other drugs being taken, length of dosage and timebetween dosages, and so forth.

• The Hartford uses Blaze Advisor to handle the risk assessment of theAutomobile, Homeowner and Umbrella lines of business from quoting toissuing to endorsing the final policy.

• Dell Financial Services (DFS) has implemented an enterprise policy hubusing Blaze Advisor for continuous pricing—risk-based pricing of creditlines with suggested alternatives in real time.


Definition of an Enterprise Policy HubAccording to IDC, “The policy hub is that point in a business process at whichdecisions are made and from which the results of the decision arecommunicated to the people and business transactional/operational systemsthat are affected.”32

An enterprise policy hub, sometimes called a universal decision engine, is aplatform that delivers the results of operational decisions to the front-linetransactional/operational systems and business processes. An enterprisepolicy hub centralizes an organization’s operating policies, procedures,regulations, models, and expertise, delivering them operationally to all systemsthroughout the extended enterprise. It is the place where any process orsystem goes to get operational decisions made.

The delivery of an enterprise policy hub becomes possible when anorganization decides to manage business policies, regulatory compliance, andbusiness expertise as valued, reusable, and changing corporate assets. Theenterprise policy hub concept is inherently compatible with currentservices-oriented architectures (SOA).

An organization’s business policies and procedures define who they are as abusiness. For example, an organization lending money for automobilepurchases indirectly defines who it is by how its personnel interact withpotential customers, how it rates credit risk, and, therefore, how it pricesservices. The organization may either have policies and procedures that bestsupport only low-risk customers, they offer products and services that cater tohigh-risk clients, or both, but it’s the business rules that effectively define thecustomer-base. For example, business rules that offer competitive interestrates only to customers with very high FICO® scores are implicitly defining amarket segment. Customers with lower FICO® scores who are offerednon-competitive rates are effectively shunned.

32. Morris, Henry, and Dan Vesset. “Policy Hubs: Progress Toward Decision-Centric BI,” IDC.


An enterprise policy hub can be logical or physical. An organization might havea common set of APIs and calls that handle all decisions. Or, it might use astandard SOA environment to manage a set of decision services by building allof them in a BRMS like Blaze Advisor. A typical heterogeneous IT environmentis likely to be a mixture—a single BRMS and rule repository with deploymentsas services and components in traditional architectures (Java, .NET orCOBOL).

Figure 34: Overview of an Enterprise Policy Hub

An enterprise policy hub, as illustrated in Figure 34, delivers precise,consistent, and agile decisioning to all applications and processes throughoutan enterprise. An enterprise policy hub has five key elements. First, there is alogical or physical service or set of services that deliver decisions to operationalsystems. In a pure SOA environment this might be an actual decision serviceor services, but in a more heterogeneous environment it consists of services,Java or .NET components and even COBOL programs deployed without aservices wrapper. Regardless of the implementation approach, the enterprisepolicy hub has the responsibility for responding to requests for decisions onbehalf of the enterprise in a consistent manner, regardless of request origin.


Second, the enterprise policy hub must be able to answer requests for the coreoperational decisions required by other systems. These decisions, such asassessing credit or calculating the next best offer, will often be used by multiplesystems, will interact with each other, and may share rules. The enterprisepolicy hub must make it easy to share common rules effectively, and mustensure consistency of response across different systems and differentimplementation environments.

Third, operational data must be directly available to the enterprise policy hub.It can rely on information passed with the request, but should also be able toreach out to operational stores and even external sources for additional datarequired to make the appropriate decision.

Fourth, the enterprise policy hub is driven from an enterprise rules repository(physical or logical). The rules in this repository are managed in collaborativefashion by the business and IT. Business owners will use a performancemanagement dashboard to monitor the business—both the behavior of theenterprise policy hub itself in the form of decision logs, and correspondingchanges to rules. This might involve adding, changing, or removing rules, andwill take advantage of the full range of rule authoring, rule versioning, releasemanagement, and other features offered by the repository.

Fifth, the enterprise policy hub is also the deployment infrastructure forpredictive analytic models. As analysts and business users mine data forbusiness rules (e.g. segmentation rules derived from customer data), or usedata to build predictive models (e.g. a predictive scorecard for retention risk),these will be deployed into the decisioning framework that implements theenterprise policy hub. Not only does this allow the analyses to be deployed tooperational systems, it allows new rules that take advantage of these insights,ensures consistency of usage of models, and maximizes return on investment(ROI) by guaranteeing that the analytically-enhanced decision is re-usedacross the enterprise.

Lastly there must be a control panel for the enterprise policy hub, a place wherethe business can control its behavior. This will typically be integrated withcorporate performance management dashboards and other reports. Bydelivering rule maintenance alongside these measurement tools, the businesscan go from tracking behavior to controlling and managing behavior. This iswhen the new kind of business future begins—when true business intelligenceguides operational decisions in the hands of business leaders.


The Benefits of an Enterprise Policy HubThe benefits of an enterprise policy hub are many:

• Separation of core business logic• Consistency and agility• Precision• Reusable business logic• Competitiveness and profitability

Separation ofcore business

logic

An enterprise policy hub extends the benefit of separating business rules (corebusiness knowledge) from applications throughout the enterprise. Although thetactical Business Rules Approach separates high-value business rules fromapplications, only an enterprise-wide approach will do so with smaller groupsof rules in minor applications. Without the enterprise approach, it is unlikely thata BRMS will be part of the tactical solution if only a few rules are re-usable orrequired by an application. However, if an enterprise policy hub is in place,many projects find it worthwhile to externalize, manage, and leverage businessrules, bringing the proven benefits of business rules to a higher percentage ofthe application portfolio.

Consistency andagility

An enterprise policy hub is designed to provide consistency with agility. Bycentralizing operational decision-making, it helps guarantee consistentdecision-making enterprise-wide. By using the Business Rules Approach anda BRMS to manage these decisions, it ensures that this consistency does notcome at the expense of business agility. Modifications to the business policiesare made once and, once deployed, are available via the rule service to theentire enterprise. With a combination of pressures to both demonstratecompliance with an ever-increasing array of regulations and more aggressiveand faster-moving competitors, business agility must be maintained, but in anauditable, controlled, and compliant way.

Precision One of the challenges facing many companies today is how to apply businessintelligence to operational systems. An enterprise policy hub provides aplatform for injecting precision into operational decision-making. With a singleplace to go for a particular decision, and a clear structure of how that decisionis made, it is much easier to identify potential uses of information to improvedecisions. Mining data for new rules or thresholds and embedding predictiveanalytic models to enhance the data available for decisioning enables new,more sophisticated rules behind automated decisions in the enterprise policyhub.


Reusablebusiness logic

An enterprise policy hub truly enables an organization to treat logic as areusable enterprise resource, to be managed and exploited. When theorganization adds customer interaction channels, those channels can reuse allor part of the decision-making infrastructure to ensure rapid set-up andconsistency. By automating decisions the organization can empowercustomers, partners, and employees to self-serve, and so reduce costs andimprove service. By focusing human resources on the 5% of a decision thatcannot, and perhaps should not, be completely automated, the organizationcan better leverage the experience and intelligence of its staff. By controllingthe key decision-making points in operational processes, an organization isbest positioned to in-source or outsource as needed.

Competitivenessand profitability

Decision making is a critical process to organizations seeking to improvecompetitiveness and profitability. Since many types of decisions are recurringor repeatable (such as pricing, extending credit, or allocating resources),decision-making processes exist that are amenable to automation. One benefitto decision process automation is that it enables greater consistency in the waydecisions are made. This is important, not only for competitive reasons, butalso increasingly for compliance reasons. As IDC said, “Companies mustdemonstrate that decisions were not arbitrary but followed establishedprocedures. Hence, they require an auditable record of decisions and a defineddecision process.” 33

Best Practices in Implementing an Enterprise Policy HubWhile there are huge benefits to be gained by implementing an enterprisepolicy hub, most organizations cannot and do not take on large projects thattake too long to show a return. Implementing an enterprise policy hub musttherefore generate an ROI at each stage. The following staged approachallows for incremental ROI and for a gradual increase in complexity where theexperience in each stage helps reduce risk in the next.

Stage 1: Identify the potential decision services within your enterprise andbegin establishing knowledge management processes to capture and engineerbusiness rules. Identify enough of these processes to identify high-valuedecision services, the experts who understand them, and the legacy systemsthat must be considered. It is essential to find the right first project and to startas you mean to go on—considering rules as a corporate asset.

33. Ibid.


Having found the right first project, create value with an initial decision service.This requires two parallel activities. One activity is to implement rules locally ina high value service/system, to generate an immediate ROI for a system orservice that is suitable for business rules automation. These typically:

a. Have lots of rules—hundreds, thousands or more.b. Have rules that change often—perhaps weekly or daily.c. Have rules that are very complex, making coding them difficult.d. Have rules that require domain expertise to be understood, making

it valuable to have the business users author them to reduce errors.

The second activity, done simultaneously with the first, is to design anenterprise rules repository. Even if the organization starts with a single projectto show ROI and develop experience, it must invest in designing the repositoryfor enterprise use. This is akin to designing services, not just for their first use,but for subsequent ones and their likely relationship to future services.

Stage 2: Find opportunities to reuse rules. A high-quality SOA enables reuseof services. In addition, some rules from first projects can often be reused inother systems. Sometimes a whole rule service can be reused (either as a

Notes on repository designThere are some general organizational guidelines for repository architecture. In general, there are four main components: a business library, technical library, rule services library and testing library.

• Business Library: Contains the business rules maintained by the business users using the rule maintenance application, and is organized in a way that follows a natural navigation scheme for the business users.

• Technical Library: Contains the technical “infrastructure” entities created and maintained by technical users using the IDE. It typically includes entities such as the object definitions, overall rule flow, and the templates that will control what business users can edit. The Technical Library content is typically managed by the rules architect and rules developers. Typically, groups of related services will have common object models and templates.

• Rules Services Library: Contains everything deployed in the production application(s); describes the external interface to the rule service (the data required and returned) and also specifies which repository entities make up this rule/decision service, typically assembling all or part of the Technical Library and some Business Library folders.

• Testing Library: Contains the rules services to be unit tested, test data, a mechanism to load test data from a data warehouse, and a test rule flow that strings together one or more rules services for testing.


service in the SOA-sense or by regenerating the rules into a new deploymentfor a different platform). However, often only some of the rules will be reusable.For instance, there might be another opportunity to use customer segmentationrules or dispute rating rules. It may well be that there is a need to replace oldcode or add additional functionality to old systems. This can often be justifiedby reducing ongoing costs (by reducing or eliminating maintenance) or addingvalue (better targeted cross-sell, resulting in additional revenue).

The first opportunities to reuse rules will likely require re-factoring unless thereis a very stable and well-defined object model. Those organizations well on theway to a model-driven approach should have object models that are sufficientlywell-defined to make this straightforward. Others may have to allow forre-factoring time.

Stage 3: Identify business/elemental services under development or inplanning that are “decision-centric.” Automate them using the rules platform.This is an ongoing activity for those organizations adopting SOA. Businessservices are often decision-centric and meet the criteria outlined above—manyrules, complex rules, changeable rules or business-centric rules. The rulesplatform should be used for these. These services need governance andmanagement above and beyond that offered for other services, as thebusiness users will be collaborating in changing the services and the serviceswill likely change more often.

Stage 4: Encourage the business groups responsible for the rules to start tofeel accountability for the decisions and the decision engine, not just the rulesor logic. This is a more advanced step. Essentially, you want those groups whodefine how decisions are made (such as credit analysts with credit policies orunderwriters with underwriting guidelines) to be responsible to the enterprise,not only for the policies, but for the decision engine itself.

Stage 5: Leverage predictive analyses to improve rules. There is a hugepotential for analyses in this context. Not only can analytic techniques be usedto find better rules, e.g. by mining data, they can also be used to enhance theinformation available to rules. Thus, mining a set of data about customerbehavior can produce statistically significant segmentation rules, aimed at aretention score showing how “at risk” a customer is. The next step is to defineadditional rules to handle effectively these risk customers.


Integrating an Enterprise Policy Hub with BPM, SOA, and BIOne of the great advantages to an enterprise policy hub is that it adds value toand works with core technology adoption trends, not against them.

An enterprise policy hub ensures simplicity of process definitions in a BPMS bykeeping decision complexity out. Decisions are handled by a decisioningbackbone leaving the process environment to handle process definition andexecution. This also allows for the same decision to be made consistentlyacross the enterprise and/or multiple BPMS implementations, and betweenBPMS and other systems.

This approach also provides a platform for operationalizing businessintelligence (BI). One of the challenges with most BI approaches is thatapplying the insight gained from data to the day-today (or second-to-second)operational decisions is hard. Most people do not find it easy to use OLAPcubes or advanced visualization and analysis tools. Automating decisionsacross the enterprise creates a platform for using insight to improve decisionsover time. Because the decision logic is encapsulated and managed, it can bechanged based on new analysis, or enhanced with new analytic models withoutimpacting the systems that rely on it.

If an organization is adopting an SOA approach, a subset of all businessservices will be delivered through your enterprise policy hub. These servicescan then be managed as atomic services (something your SOA environmentdoes), but also in terms of the regulations, policies, and procedures that defineyour business. These services are most often the ones that must change, andthe use of a business rules management system to automate them makes thischange easier to manage. The use of an enterprise policy hub can also makeit easier to guarantee consistency and compliance across channels, acrossbusiness units, and across services.

An enterprise policy hub also enhances your performance managementbackbone by giving you points of pressure at which you can apply the insightgained from your performance management systems. There is, of course, nopoint in monitoring or measuring something you cannot readily change. Anenterprise policy hub underpins the corporate performance managementapproach to make sure you can change what is not working.


SummaryWhile an organization can deploy a BRMS as a very significant programmerproductivity tool and achieve great benefits, the greatest ROI becomespossible when automating and improving operational decisions across theenterprise. Blaze Advisor is a great solution, either way.

Finally, here are some words from Blaze Advisor customers.

“The most important thing that we would stress to other organizations ishow important it is to have a strategic vision with an eye on the future.”Michael Koscielny, Director, Regional Underwriting Operations at ACG

“We were able to isolate our highest ROI component and renovate it withthe best value.”Jerrianne Seitz, Data Processing and DMV Project Manager

“We have business people in the Underwriting Department managing ourrules and managing the promotion of our rules into code.”Patrick Madigan, VP of Underwriting, Kemper Auto and Home

“To our knowledge, no other merchant processing system of this scaleexists today that empowers such precision, consistency, agility andanalytic rigor for decision management strategy implementation andexecution.”Giancarlo Marchesi, senior vice president of Global DecisionManagement at First Data

“We got a full ROI on Blaze Advisor in six months, and we estimate it hasgenerated £5 million in savings per year.”Phil Jobson, egg

More information on Blaze Advisor can be found at:www.fairisaac.com/rulesbook or by emailing: [email protected]

James Taylor authors blogs at www.edmblog.com andwww.ebizq.net/blogs/decision_management. Details on James’ writing and speaking are available at www.aboutjt.com.

ReferencesMorris, Henry, and Dan Vesset. “Policy Hubs: Progress TowardDecision-Centric BI,” IDC.

c h a p t e r


14 Putting the Business Back in Business Rules

(A Source Rule Repository for RMM Level 2)

Barbara von Halle

The Significance of RMM Level 2Most organizations included in the RMM Survey discussed in Chapter 2 listedagility as their top motivator for the Business Rules Approach. This is notsurprising, if we remember what Charles Darwin once said, “It is not thestrongest of the species that survive, nor the most intelligent, but the one mostresponsive to change.” Thus, RMM Level 2 is the most commonly soughtorganizational or project target, as organizational agility truly begins at RMMLevel 2. RMM Level 2 is also the jumping-off point for achieving higher levelsof the RMM, and the level at which today’s common practices, standards, andtechnology come together.

As a quick reminder, a Level 2 organization seeks agility in its rules. Not onlydoes the organization need to know some of the rules, but wants to be able tochange them on demand. Perhaps it wants to respond more quickly to threatsor to opportunities.

Specifically, organizations aiming for RMM Level 2 will usually deploy abusiness rule management system (BRMS), because doing so achievestechnical agility.

With a BRMS (from vendors such as ILOG and Fair Isaac), an RMM Level 2organization can develop new rules and make rule changes faster than Level0 or Level 1, because the technology enables changes, one rule or set of rulesat a time. And this is done with minimal programming. The development timefor systems with a BRMS is shorter and, more importantly, the maintenancecycle for rule changes can be significantly shorter.

Page 194 Chapter 14: Putting the Business Back in Business Rules

The Greatest Challenge for RMM Level 2The RMM Survey also pointed out that most organizations want to harvestbusiness rules from business people, and they want to manage those rulesfrom a business perspective. Survey participants often stated that, despitegood intentions, rules delivered in systems, even with a BRMS, can becomelost to the business again. That is, the business rules are buried again, andthere isn’t a clear way to measure the impact of business rule changes onvarious aspects of the business and systems.

Therefore, another important aspect of a true RMM Level 2 organization is toconduct impact analysis of potential rule changes on the business itself (notjust its systems). After all, it makes little sense for an organization to makemany rule changes quickly, without knowing how those changes are expectedto impact processes, systems, and stakeholders.

Meeting the Challenge of RMM Level 2Achieving RMM Level 2, therefore, means assessing business rule changesand changing the right rules quickly. This requires sufficient business-rulemetadata to tie the business- relevant pieces together. It also requirestraceability from the business rules to business- relevant models. Otherwise,the ability to do impact analysis about proposed rule changes is limited. Thistraceability is made possible by new software functionality that provides linksfrom rules to all relevant business items.

The KPI STEP™ Workbench, available today, provides the separation andtraceability required for achieving RMM Level 2 for business and IT audiences,independent of target implementation technology. The KPI STEP™Workbench is the subject of this chapter. It is available with the KPI STEP™License, which also includes methods, templates, training, and softwaresupport.

The remainder of the chapter covers:

• Sample best practices and standards today• Enterprise architecture, the Zachman Framework, and business rules• Separating business rules in a process chart• Separating business rules in a use case• The rule-rich decision as a critical business lever• Business versus technical analysis of business rules• Tracing business rules to process charts in the KPI STEP™ Workbench


• Tracing business rules to use cases in the KPI STEP™ Workbench• Tracing object models to business rules in the KPI STEP™ Workbench• Putting it all together and delivering Rule Maturity Model level 2• Beyond Rule Maturity Model level 2• Essential lessons learned

Sample Best Practices and Standards TodayRMM Level 2, because it is so critical to the continued success of the BusinessRules Approach, needs to be easily attainable. Therefore, business rules in anRMM Level 2 organization or project must integrate smoothly with standarddeliverables that are familiar to organizations today.

Consider the six important areas for which there are standard or commondeliverables in Table 7.

A goal for Rule Maturity Model Level 2 is to seamlessly incorporate businessrules into these common modeling and architecture techniques, whiledelivering the benefits and functionality of managing those rules. Let’s explorethese areas, starting with enterprise architecture.

Table 7: Six Practice Areas and Commonly Managed Deliverables

Practice Area Sample Standard or Common Deliverables

Enterprise architecture Zachman Framework for enterprise architecture

Business modeling Process chart (swimlane diagram)

Use case modeling Use case model

Use case description

Object Modeling UML model

Data Modeling Entity-relationship model

Business Rules Separated business rules

Business-relevant business rule metadata

Business and technical analysis of business rules

Traceability of business rules to models and metadata

Authoring and storing of technical rules

Rule flow diagrams of technical rules

Analysis of technical rules


Enterprise Architecture, the Zachman Framework, and Business RulesChapter 4, The Business Architecture of Business Rules Based Enterprises,proposes a logical relationship of business rules (in the Zachman FrameworkColumn 6) and some of the other columns of the framework.

For example, Chapter 4 proposes that strategy and objectives belong inColumn 6 of the Zachman Framework (Motivation) and Row 2 (Planner’sPerspective). Rule families or sets of rules, rules in natural language, and acorresponding glossary belong in Column 6, Row 3 (Owner’s Perspective).And, finally, designed rule sets belong in Column 6 Row 4 (Designer’sPerspective).

Chapter 4 also advocates that all business rule deliverables be linked inmeaningful ways and traceable to deliverables in the other columns. Thus, theZachman Framework becomes a foundation for designing the traceabilityneeded for achieving Rule Maturity Model Level 2.

Rather than review these linkages in detail, it is important to understand howthe linkages should occur, based on standard or common deliverables in thecolumns of the Zachman Framework. The starting point is the FunctionColumn, representing function or process deliverables. Because mostparticipants in the RMM Survey are using process modeling techniques anduse cases, this chapter explores separating and tracing business rules to thesedeliverables.


Separating Business Rules in a Process ChartFigure 35 depicts a process chart, sometimes called a swimlane diagram. Aprocess chart consists of a starting event (e.g., a customer requests a loan) andan ending event (e.g., a customer loan is approved). In between those eventsare processes or tasks that are performed in a prescribed sequence and byspecific parties. In Figure 35, there are two processes (i.e., process 1 andprocess 2) performed by the Applicant and one process (i.e., process 3)performed by the Loan Department.

Figure 35: Business Rules and Process Charts

A process chart should say nothing about business rules, other than illustratingwhere rules are to guide the processes. A common, but bad, practice is to burythe business rules in the descriptions behind the process boxes. This is badbecause the rules are buried too deep for traceability and for true impactanalysis, delivering, at most, an RMM Level 0 process.

On the right in Figure 35, the rules are in the yellow boxes. Each yellow boxrepresents a set of rules, so there are five sets of rules. For example, the boxlabeled “Probability of Default?” is the set of rules that determines whether anapplicant is likely to default on a loan. The box labeled “Mortgage Holder?” isthe set of rules that determines whether an applicant has an active mortgage.


There are arrows among these rule sets. The arrows represent dependenciesamong them. So, for example, the rule set that determines if the applicant hasa home equity loan provides input to the rule set that determines if the applicanthas other loans.

In Figure 35, the whole entire collection of these rule sets are organizedtogether under the green box, called a Decision. Organizing whole sets of rulesunder one decision, in a rigorous manner, allows a process box to beconnected to one decision with all of its underlying rules. The decision can alsobe connected to all relevant process boxes in all relevant process charts. Inthis way, all of the rules are then linked to these models in this manner, throughthe use of one decision anchor point. The decision separates the rules fromthe process chart, allowing changes to the rules in the decision to beindependent of changes in the process chart and vice versa.

Separating Business Rules in a Use CaseFigure 36 illustrates the details behind a use case. The use case has a name,shown in the red bubble, which is “Pre-qualify Loan Request.” The blue boxesdepict the detailed steps behind this use case.

Like the previous process chart, a use case should say nothing about businessrules, other than to indicate which steps in it are guided by rules. A bad practicewould be to bury the rules in the use case description or within thedocumentation for each use case step. Again, this buries them too deep fortraceability and for impact analysis, creating an RMM Level 0 use case.


Figure 36: Business Rules and Use Cases

On the right in Figure 36, in yellow, is the same collection of related rule setsfrom Figure 35. However, in Figure 36, these rule sets are anchored throughthe green Decision to Step 8 of the use case, which is “System DeterminesDefault Probability of Applicant.” So, the same rules behind the decisionenables the decision to be linked to the use case step. This means thatchanges in the use case steps can be independent of changes in the rulesthemselves.

But there is one more benefit to appreciate. What if the same decision, as acollection of rule sets, is relevant to a step in a use case and to a process boxin a process chart? The decision, which groups all relevant rules together, canserve as the common anchor point for those rules in any kind of process modeldeliverables, from process charts to use cases to activity diagrams.

An added benefit is that this common linkage also encourages consistentapplication of decisions across many different kinds of model-orienteddeliverables, thereby also supporting the consistency goal for Rule MaturityModel Level 3.


The Rule-Rich Decision As a Critical Business LeverIt turns out that decisions are really running the company, whether thosedecisions are strategic ones or tactical ones, and whether or not they arecarried out appropriately, automated or not.

Decisions are therefore important to the business and can be managed assuch. They become visible to customers, because decisions determine howyou interface with each customer. If an important decision is done incorrectlyor inconsistently, it can cost money or cause regulatory violations. Decisions,made tangible and manageable, bring the business people closer to the waydecisions drive business. Decisions, as collections of rules, are where thebusiness can start to fine-tune itself by changing one rule at a time anddetermining the impact of that change.

Finally, decisions fit seamlessly into any modeling technique, done properly,not just process models.

The decision, therefore, emerges as the standard link, starting with RMM Level1. The decision in the KPI STEP ™ Workbench is how business rules areseparated from all other kinds of models.

Business vs. Technical Analysis of Business RulesTo better understand the importance of the decision as the business ruleanchor point, consider the distinction between what we call business analysisof business rules and technical analysis of business rules.

Business analysis of business rules means being able to answer questionssuch as the following:

• Where is a particular decision operating in the business today? Whichprocesses, systems, use cases, etc. are part of that decision?

• What objectives are to be achieved by a particular decision? How closeare you to attaining those objectives?

• What metrics are associated with a particular business process? Whichbusiness rules are put into place within that business process in order toachieve or exceed those metrics?


• If you change a particular business objective, which rules need to change,and who will be impacted by that change?

Sophisticated traceability from business rules to business-related metadata isneeded to answer these questions.

On the other hand, technical analysis of business rules means being able toanswer questions such as the following:

• Which rule sets are incomplete, have inconsistencies, or have overlaps? • Which business rules require which attributes in an object model?• Who is empowered to change a rule in a production system?

Traceability from business rules to technically-related metadata and tosemantics is needed to answer these questions.

Tracing Business Rules to Process Charts in the KPI STEP™ WorkbenchFigure 37 contains a set of screens from the KPI STEP™ Workbench. Screen1 contains a browser listing of items in this repository. Scrolling through thebrowser, a decision is selected because the decision is the subject of potentialchange. In this case, it is the decision called “Determine the Default Probabilityof Applicant.”

In Screen 2, this decision is referenced by three different factors: use casesteps, business rules, and elementary business processes. So, changinganything about the decision, such as its objectives or rules, will impact all ofthese factors.


Figure 37: Tracing Business Rules to Process Charts

In Screen 3, the selected elementary business process from Screen 2 is shownto be part of the process chart called “Web-E Loan Processing” and isreferenced in the swimlane assigned to the “Applicant or CustomerRepresentative.”

If the decision had been referenced in more than one process chart, theprocess charts would be disclosed, providing an understanding of the fullimpact of changing anything about that decision on process charts.


Tracing Business Rules to Use Cases in the KPI STEP™ WorkbenchScreen 1, in Figure 38, contains the same browser listing of items in therepository as in Figure 37, with the same decision highlighted. Again, in Screen2, this decision is referenced by three different factors: use case steps,business rules, and elementary business processes.

Figure 38: Tracing Business Rules to Use Cases

However, this time, in Screen 3, you see that the referenced use case step inScreen 2 is part of the use case called “Pre-Qualify Loan Request” and thepackage “Web-E Loan.”

Again, if the decision had been referenced in more than one use case, thesewould be disclosed, providing a full impact on use cases of changing anythingabout that decision.

Screen 4 discloses that the use case is referenced by the elementary businessprocess called “Check Pre-Qualification of Loan.” This traceability has becomeintriguing.

It seems that someone has attached this use case to this particular process boxin a process chart. It all begins to make sense.


During scoping, an analyst may attach decisions to a box in a process chart toset the stage for rule harvesting. Later, as part of detailed requirements ordesign, the decisions can be assigned to steps in a use case, as appropriate.In fact, the rules behind the decision can be added at any time, actually.

Tracing Object Models to Business Rules in the KPI STEP™ WorkbenchFigure 39 illustrates the traceability from an attribute in an object model tobusiness rules.

Figure 39: Tracing Object Models to Business Rules

In screen 1, a class attribute, “default probability,” is selected. Screen 2discloses that this class attribute is connected to a business rule term, “DefaultProbability of Applicant,” and to a class, representing an entity called“Applicant.”

Screen 3 further discloses that this business rule term is referenced by threerule clauses (which can be conditions or conclusions in rules) and by onedecision. These rule clauses are “Default probability of applicant is High,”


“Default probability of applicant is Medium,” and “Default probability ofapplicant is Low.” So the business term, represented by the selected classattribute, is used in three rule clauses and is the result of one decision.

Screen 4 illustrates the items that reference one of the rule clauses, and,specifically, five business rules that contain this clause, either as a condition ora conclusion.

Therefore, a change in that class attribute, such as its data type or set ofallowable values, may impact five business rules and one decision. There iseven more to know with sophisticated traceability.

Once the traceability leads to a decision that will be impacted by a change, thedecision is the anchor point to all process models and use cases. So thecorresponding process charts, use cases, and any other models impacted by achange in this decision or its rules can be disclosed. Also, not shown here, istraceability to stakeholders, so you can notify people of pending changes.

And this is just the beginning. Any models can be connected in this way, to thesame rules, the same decisions and the same terms. This is how the power ofsophisticated business rule traceability and impact analysis becomes possible,and when business rule changes can be assessed for impact analysis beforethey are deployed in a manual process or BRMS, for example.

Pulling It All Together and Delivering Rule Maturity Model Level 2The table in Figure 40 lists the common and standard deliverables fromTable 7. The third column indicates that the first four of these deliverables arevery well supported with today’s modeling and requirements tool suites. But,support for the business rule pieces is either lacking or minimal with suchproducts.

The fourth column indicates the business rule support provided by most BRMSproducts. However, traceability from models to the business-relevant businessrule metadata is usually lacking in these products.

So, there is an important gap: a barrier to achieving full RMM Level 2 benefits.


The fifth column of Figure 40 fills the gap. It represents the softwarefunctionality available with KPI’s STEP™ Workbench. The combination of theKPI STEP™ Workbench and BRMS(s) covers all bases needed for RMM Level2. There is now an unbroken business rule continuum.

Figure 40: Essential Functionality for RMM Level 2

Beyond Rule Maturity Model Level 2 Achieving higher levels of the RMM requires more sophisticated software.Today, organizations aiming for or achieving Rule Maturity Model Level 3 andhigher usually develop their own software. But the vision for such software isin the Rule Maturity Model and evolution of commercial software will follow thedemand.


Summary and Lessons Learned from RMM Level 2 SoftwareFor most readers of this book, RMM Level 2 is an appropriate goal that deliversmany promises of the Business Rules Approach. RMM Level 2 aims forknowledge and agility of rules. For the knowledge part, the source rulerepository needs to store rules, at least in business-friendly form, with termsand rule clauses and grouped by decisions.

But for the agility part, the source rule repository must enable fast rule changes.Fast rule changes are possible to the technical rules in the BRMS, but theimpact of those changes on the business requires more metadata andtraceability. Specifically, RMM Level 2 demands traceability from businessmotivations to rules, from rules to process models and use cases and systems,from data elements and class attributes to rules, and from rules tostakeholders. The RMM Level 2 source rule repository providescomprehensive traceability at business fingertips.

Essential Lessons Learned• Comprehensive traceability ensures that the impact of rule changes is

known ahead of time.• Comprehensive traceability ensures that all relevant stakeholders are

notified, can discuss, and are prepared for rule changes before theyhappen.

• Traceability needs to be provided to every possible deliverable anorganization creates.

• Re-use of terms, rule clauses, and rules in a source rule repository savestime and minimizes errors.

• The connection of business relevant items (e.g. motivations, decisions,stakeholders, rules, and terms) to technical relevant items (e.g. datamodels, object models) allows business and technical people to use thesame source rule repository.

• The source rule repository needs to be fully customizable to theorganization’s or project’s methods and standards.


And looking a bit further an RMM Level 3 source rule repository will provide:

• Sophisticated security and authorization capabilities. • Workflow management for the entire business rule life cycle (i.e., roles,

authorizations, tutorials, and queue management).• Integration with testing and simulating capabilities.• Separation but integration with BRMSs, so as to remain agnostic to target

platform and be useable across many platforms and for non-automatedrules.

• Integration with full repositories, so as to share models and deliverablesacross multiple tools, even within one organization.

• Management dashboards to assess the status of current and future rulesets.

When these are so, the promises of RMM Level 3 are just around the corner.Business leaders will truly navigate the business, powered safely by itschanging business rules.


Part IVWrap Up

It seems most fitting that we end this book with a look at innovations thatare changing the world as we once knew it and also how the BusinessRules Approach will play such a role. We close also with highlights fromour valued book supporters.

“The alternative is to drift into the storm and to be lost at sea.”

Chapter 15, Larry Goldberg

Page 210 Part IV: Wrap Up

c h a p t e r


15 The Time is Now: The Economic Imperative for the Business Rules Approach

Larry Goldberg

One of the great innovations of modern times is the joint stock company. Somuch of the wealth of the world has been created because of this simple butingenious solution to the issue of individual investment risk.

As a consequence of the extraordinary success of this evolution of humanorganization, particularly in the great free-market economies of the West,corporations have evolved into immense organizations of great complexity.Economies of the First World have thrived, generating wealth unrivaled in thehistory of the world.

Not just in the First World. The real story today is that global economic growthis reaching historic highs, and the engines of growth lie beyond the borders ofthe First World. Now that nations in the developing world are able to bypasshistoric and sometime circuitous evolution toward free markets, and are rapidlyadopting the tools of the modern economy, new global economic powers arerapidly emerging. China, India, Russia, and other emerging nations are alteringthe balance of economic power. Corporate organizations, unknown heretofore,are suddenly household words: Lenovo, Tata, Rosneft.

What has this to do with a book about The Business Rules Revolution? Well,everything.

New forces are afoot in the world. As large, and as complex, as ourorganizations have become, they are going to have to react to the disruptivechanges brought about by the emergence of the global economy. Outsourcingis only a tiny part of the story. a harbinger of the storm to come. Serious newcompetition in almost every field of endeavor will become the norm. Change inits revolutionary sense will become the imperative of survival and prosperity inthis brave new world. This will impact not only for-profit based organizations.

Page 212 Chapter 15: The Time is Now: The Economic Imperative for the Business Rules Approach

Government and Non-Government Organizations (NGOs) will be equallychallenged to change with the arrival of the storm. And change is not easywhen we are in large organizations that have evolved over decades.

During the most recent period of technologic disruption, the advent of theInternet, we saw great successes amongst those organizations that were ableto rapidly adjust to change, and the eclipsing of those that were incapable ofagility by tiny upstart rivals. As great an upheaval as technology disruption maybe, it pales against the forces of economic disruption.

So we believe that agility is the single most important quality for a competitiveorganization. Not technological agility, a necessary but insufficient condition,but business agility.

How does the business achieve agility when most operating platforms todayare based on large legacy information systems, many of them built decadesago, where the processes and logic of the system are deeply buried beneathmany layers of history, like the remnants of ancient cities that lie beneath thesands of time?

We don’t propose glib answers to this crucial question. But in this book thediscerning reader should have grasped an outline of a path towards greateragility. The great promise of the Business Rules Approach is corporate agility,but it is clear that there are many steps along the path that must be taken, oneby one, to reach the goal.

At first there is the business decision to take this approach: a crucial step andone that needs to engage many facets of the organization.

Then there is the architectural preparation, planning at every level of theorganization for the implementation of change. This may involve aconsiderable amount of archeology to discern what the organization hasbecome, and what lies under the sands. And it requires a vision for the futureof each and every aspect of the business, and a structural plan of how this canbe achieved.

Then comes the technology planning. The future of the technology is excitingin and of itself. Your editors invited two leading technology vendors to proposetheir vision of the future (which can be found later in this chapter), and thesevisions, while somewhat divergent, point to technology that can truly enableorganizational agility. These solutions and others from the wider community ofvendors will continue to evolve: the ability of the business to deploy them to doits bidding will in the end depend upon the maturity of its approach, not only intechnology, but in business governance and control. Therefore, we also inviteda leading Business Rules services vendor to summarize how they supportBusiness Rules technology and governance projects.


Execution at both the business level and the technology level is crucial. TheBusiness Rules Approach, in order to achieve business agility, needs to acquirea relatively advanced level of maturity. Some tension may have been detectedin the degree of business control implied in several of the chapters in this book.This is a natural reflection of divergence in the level of maturity of the approach.It is almost essential in many cases for IT professionals to lead the way in thisnew endeavor. Over time, as the capabilities of the enabling technologymature, so does the business professional fully grasp the reins of control overthe business rules. This may have to be the nature of the journey.

Ultimately, however, management is going to have to grasp control of thebusiness rules to both envision a future state and to make the rapid coursecorrections that will be necessary to achieve that future state. The alternativeis to drift into the storm, and to be lost at sea.

Fair Isaac

Fair Isaac Corporation (NYSE:FIC) helps businesses improve their decision-making.. The company’s solutions and technologies for enterprise decision management give businesses the power to automate more processes and apply more intelligence to every customer interaction. By increasing the precision, consistency and agility of their decisions, Fair Isaac clients throughout the world increase sales, build customer value, cut fraud losses, manage credit risk, reduce operational costs, meet changing compliance demands and enter new markets more profitably.

Founded in 1956, Fair Isaac powers hundreds of billions of decisions a year in financial services, insurance, telecommunications, retail, consumer-branded goods, healthcare and the public sector. Fair Isaac also helps millions of U.S. individuals manage their credit health through the www.myfico.com website.

Your business decisions are your next critical source of value. But making the best decisions is well beyond the capacity of most business systems today, when decisions must be made faster, across more channels and product lines, leveraging more data, under greater regulatory demands and competitive pressures, and with more complicated constraints and trade-offs. The best way to meet these demands is through a common decision management infrastructure that serves multiple processes and systems.

This is why businesses are embracing the discipline known as enterprise decision management (EDM)—a systematic approach to automating and improving decisions. Through business rules management technology, advanced predictive analytics and more effective use of data, EDM increases the precision, consistency and agility of operational business decisions.

Fair Isaac provides enterprise decision management solutions that integrate predictive analysis with business rules management to automate and improve decisions in customer management and other areas. Among these solutions are the systems used to manage two-thirds of the world’s credit cards, and protect them from fraudulent activity. Fair Isaac also provides tools and services that help businesses develop and deploy their own systems for enterprise decision management.


Fair Isaac is recognized as the leading company in enterprise decision management, with the most comprehensive portfolio of industry solutions and advanced technologies. Our approach to EDM gives your existing information management systems—data warehousing, business intelligence, existing applications—the intelligence you need to operate on your “efficient frontier,” where risks, costs and losses are minimized, while efficiency, customer service, ROI and profit are maximized.

Our market-leading EDM Applications span the customer lifecycle—including marketing, originations, customer management, collections and recovery, and fraud management—and are available for specific processes in financial services, insurance, telecommunications, retail and healthcare. We also offer the most sophisticated EDM technology, including the Blaze Advisor™ business rules management system, model development tools, custom analysis and other services. You can design your EDM architecture using the same technology we use to build and deploy our EDM Applications, or rely on our expertise to create a custom application for your needs.

Because Fair Isaac applications are based on a common EDM technology platform, businesses can integrate, extend and expand their EDM architecture, which reduces development, maintenance, and training costs while enabling true lifecycle customer management.

The Blaze Advisor™ business rules management system is a comprehensive, advanced rules management solution that covers the entire process for developing, deploying and maintaining rules-based business applications. This leading-edge technology radically improves the way enterprises manage business applications and processes by enabling them to develop complex applications faster, respond quickly to changing business factors, and reduce the total cost of day-to-day operations.

Visit Fair Isaac online at www.fairisaac.com

Learn more about Blaze Advisor at www.fairisaac.com/rules

Read the EDM blog at http://edmblog.fairisaac.com

Request more information by E-mailing [email protected] or calling 1-888-FICO-EDM (+1 408 535 1500).

Fair Isaac (continued)

http://edmblog.fairisaac.com


Next Steps or How to Get Started Now—ILOG Excerpt

Given that ILOG’s mission as a company is to deliver software and services that empower its customers to make better decisions and manage change faster, it is understandable why ILOG has worked so hard to make JRules™ the market-leading business rule management system (BRMS). JRules makes business rule management practical by providing innovative tools to author, deploy, and manage business rules across the whole spectrum of policy-intensive applications present in the modern enterprise. In so doing, JRules has become an essential part of the IT infrastructures of hundreds of businesses worldwide. Besides Equifax, customers of the award-winning JRules include eBay, Grupo Santander, Harrah’s Entertainment, Visa, Vodafone, Zurich, and many other leading Global 2000 companies and governments.

ILOG has consistently built on its history of product innovation to make JRules the industry’s leading business rule software. Gartner Dataquest ranked ILOG the market share leader of the worldwide business rule engine software market for 2004, and positioned ILOG in the leader quadrant of Gartner’s 2005 Magic Quadrant for Business Rule Engines. The company has also been twice-named the BRMS market leader by IT research firm IDC.

With JRules 6, ILOG has produced the first BRMS to provide enterprise business rule management without compromise:

• Full empowerment for business teams• Full productivity for tech teams • Synchronized full life-cycle business rule management• Unequalled performance

Because JRules 6 requires no compromises, it is able to deliver the fastest time-to-business value and lowest total cost of ownership of any BRMS.

More information on ILOG JRules including datasheets, case studies and white papers can be obtained from ILOG’s BRMS web pages at brms.ilog.com. To speak to an ILOG representative directly by phone call 1-800-FOR-ILOG


InScope Solutions

InScope Solutions is a trusted advisor to clients in the federal, commercial, and non-profit sectors. We pursue business, engineering, and technology solutions that transform, inspire, and advance the success of our clients.

This pursuit has led us into business rule solutions, naturally. By assembling world-class expertise and best practices, InScope Solutions is well-positioned to assist your enterprise in deploying sound and successful business rule management systems.

We believe that it is important to view the adoption of the Business Rules Approach from an enterprise perspective. Initiating the adoption process with a consolidated, global view is crucial to fully realizing the vision of business rules as a true corporate asset.

This global outlook encompasses all phases of development as the business rule capabilities of an enterprise mature:

• Enhanced business value, by understanding what the rules are, how they should be captured, where they should be documented, and how they ultimately fit into system requirements.

• A sound technical state, emphasizing quality and consistency through the implementation cycle.

• Facilitated business control, by creating an environment that has the right people, processes, and systems in place to accommodate rapid change.

We don't do this alone. InScope Solutions has partnered with leading BRMS vendors and business rule practitioners to craft a complete methodology, bound together by our industry-tested approach for business rule governance.

InScope Solutions has a prestigious list of clients, including both defense and civilian government agencies, non-profit organizations, and commercial enterprises, including several Fortune 500 members. InScope has been identified by CMP Media's CRN as the eleventh fastest growing solution provider in the nation and #1 in the Washington, DC-metropolitan region for the period 2003 to 2005.

More information on InScope Solutions may be found on our website at http://www.inscopesolutions.com/.

Information specific to our Business Rule Practice, including white papers, can be obtained at http://rules.inscopesolutions.com/.

To speak to an InScope Solutions representative directly, please call 1-703-391-1990.

http://www.inscopesolutions.com/

http://rules.inscopesolutions.com/


A b o u t K P I

About Knowledge Partners, Inc.Knowledge Partners, Inc. (KPI) has—since its founding by Barbara von Hallein 1997—been one of the industry's premier thought-leadership company in thebusiness rules sphere.

In 2001 KPI completed a seminal book on the practice of business rules(Barbara von Halle, Business Rules Applied, New York: John Wiley & Sons,Inc., 2002) that laid out a foundation for a practical approach to business rulesprojects. While focused on providing methodologies, the book reflected KPI'scommitment to achieving results rather than creating theoretical constructs. Asa result of this down-to-earth, get-it-done approach, the book is a standard textin the field of business rules, and became a finalist for the 2002 CMP Media’sSoftware Development Magazine Jolt award. Candidates for this award, whichis reserved for “products, books, and websites that have jolted the industry byhelping to create faster, easier, and more efficient software,” are nominated byend-customers and finalists chosen by judges.

Other important milestones in KPI's long association with the Business RulesApproach include:

IBM® Rational Unified Process or RUP® Plug-inKPI, in partnership with Fair Isaac Corporation, developed a business rulesplug-in for RUP, still today the only defined business rules methodology forRUP available on the market.

Business Rules Mining MethodologyWorking with clients and technology suppliers, KPI developed acomprehensive methodology to mine business rules from a disparate range oflegacy systems. This methodology was incorporated into the KPI STEP™License Program.

Page 218 About KPI

KPI Rule Maturity Model (KPI RMM™)Responding to client requests that KPI survey the current state of the BusinessRules Approach across industries in the United States, KPI undertook a studyand formalized the findings in the KPI Rule Maturity Model (KPI RMM). Themodel includes a mapping to the business values, technology requisites, andgovernance issues of each level of maturity. It provides a roadmap forenterprises to adopt the Business Rules Approach, ensuring the highest returnon investment while effectively managing risk. KPI has developed a range oftechniques to leverage the power of the KPI RMM, and continues to validatethe KPI RMM through wide ranging surveys of enterprises that have adoptedor are about to adopt the Business Rules Approach.

KPI STEP™ License ProgramIn 2005 KPI announced a licensing program for the KPI STEP methodology.The objective was to provide a comprehensive and fully-supportedenvironment for implementing the Business Rules Approach with amethodology that can be readily integrated into an existing projectmethodology. The license comprises the following sections (see the detailedillustration in Table 8):

• How-to: Step-by-step listings of project tasks and the appropriate inputand output templates for each step, with training programs for ruleharvesting, rule mining, and project planning, as well as comprehensivetemplates to be used with the "how-to" guides.

• Software: The KPI STEP Workbench as a comprehensive business rulesrepository and management system that fully supports KPI RMM Level 2,as well as software specifications and database schema to support up toKPI RMM Level 5, so that the licensee can build custom software shouldthey so elect.

The KPI STEP License program is fully supported by KPI and its alliancepartners of Consultants and Independent Service Providers. It includes aprogram of continuing improvements in the KPI STEP materials issued underthe KPI STEP License Enhancement Program. The KPI STEP License can bepurchased in the form of a Provisional License ("try-before-buy"), Project LevelLicense, or Organization Level License (for organizations up to an enterpriselevel), and may be purchased through KPI alliance partners.

The Business R

ule Revolution

Page

219

Table 8: A Subset of KPI STEP License Artifacts, Release 3.2.1

STEP-by-STEP How-To KPI STEP Software

General Methods Techniques Software Specs KPI STEP Workbench

Master matrix of tasks, templates, and samples

2-day Rule Harvesting and Analysis course

MS/Word templates Software requirements correlated to RMM Level

Modeling capabilities, reporting, web-publishing, multi-user support

STOP paper on use cases and business rules

KPI Business Rules Applied MS/Excel templates Software requirements correlated to KPI STEP Workbench

KPI STEP and Business Rules Mining Reference Guide for the KPI STEP Workbench

Introduction to KPI RMM Part 1, 2

3-day Business Rule Mining course

PowerPoint samples Logical Data Model to fully support KPI STEP

KPI STEP Workbench Install Guide

Beyond Business Rules Applied booklet, Issue 1

Business Rule Mining user guide

KPI STEP Workbench screen templates

Detailed Attribute Definitions Pre-populated with KPI STEP Workshop Solutions

Page 220 About KPI


Y o u r B o o k

Create Thought Leadership for Your Company

Contact Happy About at 408-257-3000 or go to http://happyabout.info.

http://happyabout.info

I would like to congratulate Barbara von Halle, KPI and the co-authors of this new publication.

Remember, on the road ahead, BPM will lead the way to renewed and newly-invented processes. A Business Rules Approach will ensure old rules give way to agile ones. The powerful BPM and BRE combination is only in its first generation.

BPMInstitute.org is fortunate to have Barbara as Editorial Director of the BR Bulletin – our monthly newsletter featuring timely articles, research, white papers, and more.

Visit www.BPMInstitute.org/BR for the latest information to ensure the success of your BPM/BR initiatives.

We look forward to serving you.

Best regards,

Gregg V. RockEditor & FounderBPMInstitute.org

BUSINESS RULES Home Page

www.BPMInstitute.org/BR

EDITORIAL DIRECTOR

Barbara von Halle Editorial Director

Business Rules Bulletin and Founder, KPI

BUSINESS RULES SYMPOSIUM

Co-Chaired by Barbara von Halle, the Business Rules Symposium is the leading event for Business and IT Professionals seeking an unbiased source of education, expertise and guidance on their BR initiatives.

Visit www.BPMInstitute.org/BR for dates and locations.

The Peer-to-Peer Exchange for Business Process Management

Professionals

BUSINESS RULES



https://www.BPMInstitute.org/BR

Business Rule Revolution

Documents

physician

secures global

barbara von

barbara von

business policy

business rule

enterprise

walgreens