SKIP THE SHIPPING
Use code NOSHIP during checkout to save 40% on eligible eBooks, now through January 5. Shop now.
Register your product to gain access to bonus material or receive a coupon.
The idea of Business Rules has been around for a while. Simply put, a Business Rule is a statement that defines or constrains some aspect of the business. In practice they are meant to reduce or eliminate the delays, waste, and frustration associated with the IT department having to be involved with almost every action affecting an organization's information systems. The advent of Web services has created renewed interest in them. There are now several well established rules-based products that have demonstrated the effectiveness of their use. But until now there has not been a definitive guide to Business Rules. Ron Ross, considered to be the father of Business Rules, will help organizations apply this powerful solution to their own computer system problems. This book is intended to be the first book that anyone from an IT manager to a business manager will read to understand what Business Rules are, and what how they can be applied to their own situation.
Principles of the Business Rule Approach: Areas of Opportunity
Principles of the Business Rule Approach: The 'Flow' and the 'Know'
Principles of the Business Rules Approach
Click below for Sample Chapter(s) related to this title:
Sample Chapter
1
Preface.
I. THE BUSINESS PROBLEM: WHY BUSINESS RULES?: READINGS FOR BUSINESS PROFESSIONALS.
Overview.
1. What's This about Business Rules?: The Problem and the Fix in a Nutshell.A Telltale E-Mail Trail.
The Case for Business Rules.
When Is a Door Not a Door?
The Business Rule Difference.
2. Areas of Opportunity: Changing the Face of Business.Where Does the Business Rule Approach Apply?
The “Re's” of Business Rules.
Let's Make a Deal.
A Killer App for Business Rules.
Reempowerment for the Company's Provisioning Processes.
There's a Lot More to Reference Data Than Just Data!
Business Rules as Customer Interface.
New Ways to Link Up.
What about Web-Based Commerce?
Harnessing the Dynamics of an Open Rule Marketplace.
3. Serving Up Knowledge: The Need to Know.What Is Knowledge Management?
And What Does It Have to Do with Business Rules?
Personalized, Never-Ending, On-the-Job Training.
Knowledge Companions for 21st-Century Line Workers.
4. What about IT Projects?: Where the Rubber Meets the Road.If We Had Already Started Coding….
Meeting Those Project Deadlines.
Two Things Wrong with Traditional Business Systems Development.
Yes, There Is a Better Way!
What Business-Driven Really Means.
Getting to the Right Mind-Set.
More on What Business-Driven Really Means.
The Business Model.
The Policy Charter.
A Small-Sized Big Picture.
The True Business Analyst.
The Go-To Guy for 21st-Century Business Systems.
II. BUSINESS RULE CONCEPTS: THE MECHANICS OF BUSINESS SYSTEMS.
Overview.
The Marvelous Organism.
A New View of Business Systems.
5. Organizing Basic Business Knowledge: What You Need to Know about Terms and Facts.Terms and Facts.
About Terms.
About Facts.
Using Graphic Fact Models.
The Fact Model and Behavior.
6. Exercising Control: What You Need to Know about Rules.Rules for Control.
Rules and Events.
About Violations of Rules.
Implications of Rules Playing the Central Role.
Ways in Which Rules Can Exercise Control: Functional Categories of Rules.
Rejectors.
Producers.
Projectors.
Expanding the Coverage of Rules.
Suggestions and Guidelines.
Handling Exceptions.
Rules and Guidance in the Business Rule Approach.
7. Doing Work: What You Need to Know about Processes.Challenges Facing Businesses Today.
Putting Business Rules to Work.
Building on What You Know.
Basing Procedures on Terms and Facts.
Basing Procedures on Rule Independence.
Including People in Scripts.
Implications for the Business Side.
Back to Training.
Building on What You Already Know How to Do.
Normal Reuse of Scripts.
Abnormal Reuse of Scripts.
III. BEST PRACTICES FOR EXPRESSING RULES: BRS RULESPEAK.
Overview.
8. Expressing Rules: The Dos and Don'ts.Not How, Not Where, Not Who, Not When.
Not Procedural.
Not Inscrutable.
Not Impossible.
Always Built on Terms and Facts.
No AWOL Facts.
No Fluff.
No Plural Subjects.
Careful about Iffy Starts.
No AWOL Subjects.
Careful about Actors as Subjects.
No Commands.
No CRUD.
Careful about Events as Subjects.
Careful to Qualify
Careful to Extract Embedded Computations.
Careful to Isolate Your Logic.
And No Etc..
9. Developing Rule Statements: The Basics of BRS RuleSpeak.About the Rule Sentence Templates.
Success Factors in Using the Templates.
Fundamental Concepts.
Every Rule Has a Functional Category.
Every Rule Should Have a Subject.
Every Rule Should Use a Rule Word.
Every Rejector Has a Flip Side.
Every Permission Statement Should Use a Permission Word.
Any Rule Can Be Qualified.
Any Rule Can Include a Time Bracket.
Any Rule Can Reference a Value.
Basic Usage Notes.
Using Shall.
Using Should.
Using May.
Using No.
Using Not…Not.
Using Or and And.
Special Usage Notes.
Using Rule Types in RuleSpeak.
Using A, Some, and Each.
Using Strictly ANDed and ORed Conditions.
10. Functional Categories of Rules: The BRS Rule Classification Scheme.The Basic RuleSpeak Templates at a Glance.
12. Expressing Business Logic by Using Decision Tables: The RuleSpeak Approach.When Decision Tables Should Be Used.
Decision Tables Involving One Evaluation Term.
Decision Tables Involving Two Evaluation Terms.
Decision Tables Involving Three or More Simple Evaluation Terms.
Decision Tables Involving More Complex Sets of Decision Criteria.
Appropriate Outcomes for Decision Tables by Functional Category of Rule.
IV. WHAT IS THE BUSINESS RULE APPROACH?: READINGS FOR IT PROFESSIONALS.
Overview.
13. More Principles of the Business Rule Approach: A New View of Business Logic.The Basic Principles of Rule Management.
Databasing Your Rules.
What Is a Business Rule?
Separating the “Know” from the “Flow”.
Business Rules and the “Flow”.
Correcting Some Misconceptions about Business Rules.
Business Rules and the “Know”.
Rules for Processes and Rules for Products/Services.
Why Business Rule Methodology Is Different.
What It Means to Mean Business.
Analysis Paralysis.
Preventing the Disease Behind the Symptoms.
14. More about Fact Models: Structuring the Basic Business Knowledge.Critical Success Factors for Fact Models.
Organizing the Basic “Know” Part.
Doing the Data Model Right for Business Rules.
Using Rules to Reduce the Impact of Change.
V. A THEORY OF BUSINESS RULES: A TUTORIAL ON THE FORMAL BASIS FOR BUSINESS RULES AND BUSINESS RULE NOTATION.
Overview.
15. Three Perspectives on Business Rules: A Framework for Formal @AHEADS = Discussion.The Three Perspectives.
A Word about Terms.
A Word about Types.
Special Terminology.
16. The Theoretical Foundation of Rules: About Formal Constraints.The Formal Definition of Rule.
More on Terms.
Terminology: Instances and Classes, Values and Variables.
Rule Notation.
Constraints: Rejection versus Inference.
17. The Theoretical Foundation of Facts: About Predicates.Predicates and Facts.
Predicate at the Business Manager's Perspective.
Predicate at the System Developer's Perspective.
Predicate at the Technical Designer's Perspective.
Facts: Type versus Instance.
The Existence Principle.
A Brief Introduction to R-Notation for Facts.
Inferencing and Deduction Revisited: Using Predicates.
18. Higher-Order Rules: Pattern-R Rule Types.The Definition of Pattern-R Rule Types.
Examples of Pattern-R Rules.
Example 1: The Monitor Rule.
Example 2: The Union Rule.
The Assembly of Pattern-R Rule Types.
Part 1: The Yield-Value Function.
Part 2: The Truth-Valued Function.
Assembly of Example 1: The Monitor Rule.
Assembly of Example 2: The Union Rule.
Appendices for Part V.Appendix A. Evaluating the Truth Value of a Rule.
Appendix B. Terms at the Technical Designer's View.
Appendix C. The Fundamental Kinds of Rules.
Appendix D. About the IF…THEN…Syntax.
Appendix E. Halpin's Definitions for Fact and Related Terms.
Appendix F. Semantics in the Relational Model.
Appendix G. Basic Operators and Higher-Order Rule Types.
Appendix H. Formalization of the Pattern-R Approach.
Appendix I. What Does Declarative Mean?
Appendix J. The “Mary” Inferencing Example Step-by-Step.
Appendix K. More on R-Notation for Facts.
Appendix L. Special Built-In Fact Types in R-Notation.
Glossary.The driver for business systems should always be business need. Business workers should be involved in expressing this need in very direct, concrete ways. Applying these principles in practice means taking a fresh approach to business systems that will profoundly affect the roles of both business professionals and information technology (IT) professionals.
This fresh approach can be called business analysis, and its basic deliverable a business model. Unfortunately, these terms are often used very loosely. There are large numbers of system developers who think their deliverables would qualify as business models, but do not. Rather than try to explain here--it does require some background--I will leave that topic for Part I. For now, let's simply call the fresh approach business-driven and move on.
A basic ingredient of the business-driven approach--a very exciting one--is business rules. Before continuing, let me clarify something. We could certainly talk about business rules without necessarily discussing everything else needed for a business-driven approach. In other words, we could discuss business rules separately.
But why would we want to? If business need is the driving factor for business systems, then both the business-driven approach and business rules should be put on the table and served together. That way the business can achieve the very best business solutions to the challenges it faces in the 21st century. In a nutshell, that describes the basic mindset of this book.
That brings me to the audience, or more accurately, to the audiences for this book. In general terms, there are three audiences: Business professionals, IT professionals, and academics. In today's world, there are significant gaps between these three communities--and that in itself is part of the problem. To create the best business solutions possible, these three communities must come closer together in common purpose and approach. This book will help show the way.
I will say a few words to each of these three communities in a moment, but first let me say a word about technology. Because I believe so strongly that business systems should be driven by business need, I have purposely avoided discussing technology (with some difficulty!) throughout the book. But the topic certainly does deserve comment, so let me talk about it briefly.
We are on the verge of a huge new wave of technological innovation focused on the knowledge capabilities of the business. Think of business rules (which I collectively call business logic) as a first--and in many respects relatively modest--step in that direction.
The plain truth is that such technology has never been a significant part of mainstream business IT. Expert systems made a minor foray into that realm in the 1980s, but had very little impact. There were many reasons why, but perhaps the most important was technological. Computing architectures then (and since then until recently) were basically monolithic, and provided no easy way to accommodate "outside" services.
Without going into detail, that fundamental barrier is now being eliminated, and plug-in services are becoming easier and easier to incorporate. And what better service to incorporate than direct knowledge support?!
"Knowledge support" does sound a bit abstract. There are several terms in current usage for such a service, including rule engine and decision-management platform. In Part V of this book, we suggest business logic server. By whatever name, we predict without hesitation that such services will be part of all major business software platforms within a mere matter of years.
To many, this technology will seem like a tidal wave from nowhere. But that's not really true. In fact, the theoretical foundations of this new technology go back many, many years, again as discussed in Part V. Commercial offerings date to the mid-1980s; applied research goes back well before that. Refer to the special boxed item opposite for a brief review of where this technology stands at present.
In the near future, commercial technology servicing business logic is likely to be offered in several different ways, including the following.
And the list does on. A big question mark for the future concerns database management systems (DBMS). In Part V I argue that in the long run, database support should be integrated within a business logic server.
Again, our focus in this book is not technology, but rather where do the business rules come from? That brings us to the business rule approach.
Like the technology, the business rule approach also did not suddenly appear from nowhere. In fact, the core concepts (as described in Part II) date to the mid to early 1990s, and many of the related techniques and methodologies (including those in Part III) have been thoroughly battle-tested by pioneering organizations during the late 1990s and early 2000s. (The same is true, incidentally, about business-driven approaches.) So what we talk about in this book is not unproven theory or academic conjecture, but pragmatic, real-world stuff.
The interesting and perhaps unique thing about the business rule approach is that it did not arise as a response to any emerging new class of software tools--knowledge-oriented or otherwise. (Again, the same is true for business-driven approaches.)
Rather, the business rule approach is a real-world, grass-roots movement whose driving force is business success, not technology. It arose from the vision of dedicated professionals with many years' experience in the trials and challenges of business software. Their goal: to offer companies the best possible approach to developing business solutions involving automated systems.
For that reason, it is appropriate that I address members of the business-side community first. To repeat, this is not a book about technology, but rather one about business opportunity. The key question should therefore be why your knowing about business rules is important as a business proposition.
So exactly what is the value proposition of business rules? Part I provides the answer, but let me give you a short version here, then invite you to read on. Refer to the special boxed item opposite.Part I also discusses what business-driven approaches are about. From a business perspective, the business rule approach fits hand-in-glove with them. Combined, they are potent indeed. I hope Part I will prove so compelling in this regard that you will read on. I have tried to use a readable, non-technical style throughout the book, so there is much to be gained from going as deep into the book as you care to go.
Part II explains the basic ideas of the business rule approach using a broad analogy to the human body. Continuing from there (or skipping ahead if you chose), Part III provides a comprehensive language, called BRS RuleSpeak, to capture and express your business rules. You will find that material informative and in places, perhaps entertaining.
Part IV is officially directed toward IT professionals, but it is actually a continuation of, or more accurately a different perspective on, the material in Part I. I believe it is very important for business professionals and IT professionals to speak with the same voice; that material should help your organization achieve it. By the way, the first Section of Part IV is the only other place in the book I talk about business-driven approaches directly.
Just a word first about business-driven approaches first - I believe they are closely aligned with the architecture-based or model-based development strategies now emerging in the industry. In particular, a business-driven approach provides an excellent front-end for these strategies in the form of the business model. A business model represents a top-down, multi-aspect blueprint of the business whose contents are driven by business professionals. That's a great starting point for system design and development of an application system (or deployment of an application package). These ideas are developed in Parts I and IV of the book.
If your interest centers specifically on business rules, you can concentrate on Parts II and III. There are important portions of Part IV devoted to rule management, rule capture, and data design you will also not want to miss.
The main objective for all this material is to help you gain a deep understanding of what business rules are about, and make them a comfortable part of your professional toolkit. I think you will be quite excited by the powerful ideas and techniques that await you.
By academics, I do not mean only those readers who happen to be in universities or research labs. I mean any serious student of logical systems - systems here in the sense of theory, not applications. I also mean those who are just plain intellectually curious. Part V is aimed toward all such readers.
Part V provides answers to some of the big questions of business rules, such as their basis in formal theory--the predicate logic. You should not let that intimidate you. Part V is written as a tutorial so that the ideas are as accessible as possible to all. At the same time, we anticipate that this material will provide the basis for continuing research--some of which has already commenced.
The bottom line is this. You know you are on to something really powerful when good theory and successful practices converge. That convergence is exactly what has happened with business rules, and it is a very exciting time to be in the field!
Click below to download the Index file related to this title:
Index