Information systems often fail because their requirements are poorly defined. This book shows IT professionals how to specify more precisely and more effectively what their systems need to do. The key lies in the discovery and application of what are called business rules. A business rule is a compact and simple statement that represents some important aspect of a business. By capturing the rules for your business--the logic that governs its operation--you will gain the ability to create systems fully aligned with your business needs.
In this book, Tony Morgan provides a thorough introduction to business rules, as well as a practical framework for integrating them into information systems. He shows you how to identify and express business rules, offers practical strategies for their use, and explains the key elements of logic that underpin their application.
Topics covered include:
Whether you are an analyst, designer, developer, or technical manager, the in-depth information and practical perspective in this valuable resource will guide you in your efforts to build rule-centered information systems that fully support the goals of your organization.
Download the sample pages (includes Chapter 3 and Index)
List of Figures.
I. A NEW APPROACH TO BUSINESS SYSTEMS.1. The Problem.
What This Book is about.
Why Should You Care?
What is a Business Rule?
The Way We Build Software.
How Could It Be?
Is This Really Practical?
Where We Stand.2. Frameworks, Architectures, and Models.
Case Study: A Sample Business Architecture.
Business Process Elements.
Actors and Roles.
What Does a Complete Model Look Like?
II. CAPTURING BUSINESS RULES.3. Defining Business Rules.
Business Rule Characteristics.
What Should a Rule Say?
Levels of Expression.
Forming Rule Statements.
Static Models Versus Rule Statements.
References to Facts.
Terms and Rules.
References to Multiple Items.
Tips on Rule Construction.
Quantifications and Qualifications.
States and Events.
Structure and Consistency.
Case Study: Microsoft Outlook.
Outlook Rule Structure.
Conditions, Exceptions, and Actions.
Outlook Rule Features.
Rule Description Summary.4. Discovering Business Rules.
That Which We Call a Rule.
Where Rules Come Rrom.
Automated Rule Discovery.
Case Study: Loan Approval.
The Early Stages.
Rule-discovery Summary.5. Controlling Rule Quality.
Developing Quality Rules.
What to Look for in Reviewing Rules.
Review Records and Approvals.
Planning and Preparation.
Conducting a Walkthrough.
Planning and Preparation.
Managing an Inspection.
The Use of Testing.
The Process of Testing.
Case Study: Testing the VBB Loan-application Rules.
Setting up the ABC Testing.
Assessing the Rules.
Choosing Test Cases.
Implementing the Rule Tests.
VBB Test Results.
III. IMPLEMENTING BUSINESS RULES.6. The Technology Environment.
More about Architecture.
A Typical Reference Architecture.
Server Pages and Ccripting.
Implications for Business Rules.
Where Rules Live.
Data Services Tier.
Summarizing the Technology Environment.7. Realizing Business Rules.
Flags and Magic Codes.
Implementation Summary.8. Managing Business Rules and Models.
Coping with Changes.
Testing a New System.
Supporting a Live System.
Tools to Support Rule Management.
Why a Repository?
Repositories and Rules Engines.
An Example Repository Design.
Rule Management Summary.
IV. THE ROLE OF BUSINESS RULES.9. A Wider View.
Marshaling Intellectual Resources.
Developing Knowledge Management.
What's the Problem?
Packaging for Reuse.
New Kinds of Services.
Knowledge Summary.10. Summing Up.
The Purpose of This Book.
Business Process Reengineering.
Reducing the Maintenance Burden.
Business Rule Characteristics.
Advantages of Business Rules.
Business Rule Features.
Categories of Benefits.Appendix: A Little Bit of Logic.
Logic and Logics.
A Logical Framework.
Forms and Symbols.
What's a Proposition?
Standard Forms of Proposition.
Alternative Forms of Propositions.
Other Kinds of Arguments.
Handling Logical Values.
Nothing but the Truth.
Combining Logical Values.
How Many Functions?
Final Words.Selected Bibliography.
It seems that every week brings a new story about a software project or a system that's failed in some way. Quite often, the failures are so big that they make it to the national press. Most of the information given is anecdotal and circumstantial, but even a nontechnical observer might suspect that something is seriously wrong with the way we develop software systems.
My own view is that the core of the problem lies in the casual way we treat "the requirements": the statements that tell us what an information system is supposed to do. These statements are typically captured only in a rudimentary way, are poorly structured, and are linked to the software only by ideas in the heads of analysts and developers and so aren't open to examination or verification.
If we can return "the requirements" to a more prominent role in the process and use them to drive the subsequent development stages, we have the potential for a drastic reduction in the number of errors. Adding automation to this process can further reduce the opportunity for error and, as a bonus, also give big reductions in time and cost. We haven't been able to do this in the past, because there's been no clear strategy that we could adopt to drive things forward.
The idea of business rules, rooted in a business model, might provide part of the answer. But practical information on the topic is unexpectedly sparse, even though most of the basic ideas have been around for some time. Ideally, this book will help plug the gap.
I wrote the book to pull together a load of separate strands and to show how they fit together to provide a coherent foundation for building information systems. In truth, very little in the book is completely new, and maybe that's a good thing. What we need is not so much new technology as a renewed focus on what's important.
The intention is not to convince you to use rules. You're already using them. In fact, if you're in a large organization, you probably have thousands of them. They guide the way your organization works, they make sure that you comply with legal and other regulations, and they are a source of competitive advantage or a barrier to success. But in most organizations, rules lead a shadowy existence. They may be enforced by your information systems, so that you're always directed toward the goals the business has adopted. But then again, the rules may not be so enforced.
You need to get an adequate level of control over your environment. I cannot know about your specific circumstances, but maybe the material in this book will help you to come up with some actions that put you in a better position to be a leader, not just a survivor, in your industry.
Although the information here is probably enough for you to develop your own complete set of tools and processes for building rule-centered systems, it's not really what I would recommend. Generally speaking, you should prefer a properly supported commercial product--if one exists--to a home-brewed tool. But all products have their little foibles, and before you fall into the arms of a particular vendor, you need to understand what you're gaining and what you're giving up. The information in this book should help you to ask the right questions before you make a commitment. You can also use the material in this book to help you to define any local "glue" that may be required to make your tool set stick together properly.
This book contains no information about particular commercial products or vendors. This comparatively new area for tool support is an immature technology, and is undergoing rapid change. Any descriptions of current tools would be out of date in a few months or even weeks. The best sources of information are the suppliers' Web pages, where you'll usually find product descriptions, white papers, and other supporting materials. Just search for terms like "business rule," pull out the sites that are on topic from the list returned, and build up your own set of favorites. You should also check out the Addison-Wesley Web site at www.aw.com/
This book is aimed primarily at professionals working in the field of information technology (IT). If you have any involvement in the definition, creation, or management of an information system, you should be able to gain something of value from this book.
Analysts, responsible for capturing requirements and for specifying information systems, can find out more about producing logically complete definitions of the needs of the business. This includes understanding business models and their various constituents, knowing how to locate business rules, and determining how to express them in a form that maintains their true value.
Designers and developers, with responsibility for the implementation and testing of systems, can find practical examples of how business logic, expressed in the form of rules, can be conserved and taken forward into operational software. This also provides for two-way traceability between the worlds of specification and implementation.
Managers and strategists are obliged to take a higher-level view of the whole process. What they will find here are practical steps to help them to manage the intellectual property represented in a system, along with ideas for improving the development process in order to deliver information systems faster, cheaper, and, above all, to a level of quality that can far exceed current ad hoc methods.
Please don't treat this book as a set of edicts about what you should or should not do. It's meant to be a source of ideas that you can meld into your own approach to the needs of information systems in the twenty-first century.
The thing that resonates with me most strongly after engagements in a large number of IT environments is that they are different! Of course, there are similarities from place to place, but no one wants to be just the same as everyone else in their market sector. In fact, you can't really afford to be a "me too" player, who at best expects to survive, not to be a winner.
Using IT effectively requires you to balance out two different things.
The material in this book is aimed at providing you with the information you need to make crucial decisions in this area. I can't tell you how to run your business, but I can provide pointers to ideas that you may be able to use to lead your industry in the application of information technology.
The content falls into four main parts. Part I--A New Approach to Information Systems--sets the scene by suggesting how we could begin to approach information systems in a different way. Chapter 1 paints a picture of an alternative future that uses structured descriptions of a business to drive system development. Chapter 2 fills in some of the background on what we mean by structuring and managing knowledge about a business. This chapter introduces business models and the role they can play in meeting the demands of new business directions, such as e-commerce.
Although business rules have a particularly important part to play here, they are probably the least well documented of all the business model elements. Part II--Capturing Business Rules--therefore delves into rules in greater depth and provides some fairly detailed information that should help you to set up a sound framework for delivering logical business descriptions. Chapter 3 explains how to define business rules in a systematic way. Chapter 4 discusses how to identify business rules and pull them into a managed environment. Chapter 5 shows how the business logic that underlies the rules can be validated, providing assurance that the intentions of the business have been captured accurately so that later stages can proceed with confidence.
In Part III--Implementing Business Rules--we take a look at the other end of the process and consider realistic mechanisms for the implementation of information systems and business rules in particular. Chapter 6 reviews the kinds of technical architectures that dominate in most organizations and shows where rules can fit into the kinds of structure that are likely to be available. Chapter 7 goes into more detail on the various ways that business rules can be realized using readily available technology. Chapter 8 discusses ways of managing rules and models and the part they play in information system development.
Finally, Part IV--The Role of Business Rules--rounds things out by summarizing the current state of play. Chapter 9 shows how business rules build on long-standing ideas about structuring descriptions of interactions between people and between people and machines and points to some directions that this may take in the future. Chapter 10 gives a summary of the main characteristics of business rules and the value they can provide.
The Appendix summarizes the key elements of logic that need to be understood by anyone working with business rules. If you're entirely comfortable with the ideas of formal logic, you can skip this material, but you may want to dip into it if you feel the need for a refresher.
Most of all, I would be happy if this book encourages you to think about information systems in a different way. Let's focus on producing a logically complete description of what we want and let the machines take care of the details..