9780201743913

Business Rules and Information Systems Aligning IT with Business Goals

by
  • ISBN13:

    9780201743913

  • ISBN10:

    0201743914

  • Edition: 1st
  • Format: Paperback
  • Copyright: 2002-03-18
  • Publisher: Addison-Wesley Professional

Note: Supplemental materials are not guaranteed with Rental or Used book purchases.

Purchase Benefits

  • Free Shipping On Orders Over $35!
    Your order must be $35 or more to qualify for free economy shipping. Bulk sales, PO's, Marketplace items, eBooks and apparel do not qualify for this offer.
  • Get Rewarded for Ordering Your Textbooks! Enroll Now
List Price: $59.99 Save up to $24.00
  • Rent Book $35.99
    Add to Cart Free Shipping

    TERM
    PRICE
    DUE

Supplemental Materials

What is included with this book?

  • The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.
  • The Used, Rental and eBook copies of this book are not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.

Summary

Why this book

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.

The goals of this book

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/cseng/, where you'll find more information relating to this book.

Who should read this book

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.

How to use this book

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.

  • You need to be realistic about what technology can provide but also be prepared to take up new capabilities as they arise.
  • You have to look for ways in which you can differentiate your operation by doing it faster, cheaper, or to a level of quality that the competition can't match.

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 exp

Author Biography

Tony Morgan is a Senior Solution Specialist at Unisys Corporation. He has a broad range of IT experience gained at companies such as EDS and Unisys, including more than fifteen years of rule-based system development. His main interest is in IT systems that deliver real business value. Tony holds a Ph.D. in Computer Science from the University of Cambridge and is a Visiting Research Fellow at Brunel University in London, England

Table of Contents

List of Figures
xiii
Preface xvii
Acknowledgments xxi
PART I A NEW APPROACH TO BUSINESS SYSTEMS 1(56)
The Problem
3(14)
What this book is about
3(3)
Why should you care?
4(1)
What is a business rule?
5(1)
The way we build software
6(3)
The vision
9(2)
How could it be?
9(2)
Some implications
11(1)
Is this really practical?
11(3)
Moving forward
14(1)
Where we stand
15(2)
Frameworks, Architectures, and Models
17(40)
Needful abstractions
17(10)
Frameworks
19(3)
Architectures
22(2)
Models
24(3)
Case study: a sample business architecture
27(28)
Overview
27(1)
Business objects
28(7)
Business process elements
35(4)
Narratives
39(5)
Business events
44(3)
Actors and roles
47(3)
Business intentions
50(3)
Organizational units
53(1)
Business rules
54(1)
What does a complete model look like?
55(1)
Model summary
56(1)
PART II CAPTURING BUSINESS RULES 57(112)
Defining Business Rules
59(42)
Rule statements
59(7)
Business rule characteristics
59(2)
Business aspects
61(1)
What should a rule say?
61(2)
Levels of expression
63(2)
OCL
65(1)
Forming rule statements
66(6)
Pattern conventions
68(1)
Rule patterns
69(2)
Rule sets
71(1)
Static models versus rule statements
71(1)
References to facts
72(5)
Terms and rules
72(2)
Individual items
74(1)
References to multiple items
75(2)
Business parameters
77(2)
Tips on rule construction
79(12)
Using facts
79(2)
Simple constraints
81(3)
Quantifications and qualifications
84(1)
States and events
85(1)
Actors
86(1)
Dangerous verbs
87(1)
Computation
88(1)
Structure and consistency
88(3)
Case Study: Microsoft Outlook
91(9)
Outlook rule structure
91(1)
Conditions, exceptions, and actions
92(5)
Internals
97(1)
Logic
97(2)
Outlook rule features
99(1)
Rule description summary
100(1)
Discovering Business Rules
101(30)
That which we call a rule
101(1)
Where rules come from
102(7)
Information sources
104(1)
Common indicators
105(4)
Finding rules
109(12)
Static analysis
110(5)
Interactive sessions
115(4)
Automated rule discovery
119(2)
Case study: loan approval
121(9)
The early stages
121(1)
Fishbones
122(3)
Input data
125(2)
Loan-assessment rules
127(3)
Rule-discovery summary
130(1)
Controlling Rule Quality
131(38)
Developing quality rules
131(2)
Reviewing rules
133(6)
What to look for in reviewing rules
133(1)
Roles
134(1)
Rule context
135(1)
Tone
136(1)
Review outcomes
136(1)
Review records and approvals
137(2)
Walkthroughs
139(1)
Planning and preparation
139(1)
Conducting a walkthrough
139(1)
Inspections
140(3)
Planning and preparation
141(1)
Managing an inspection
142(1)
Testing
143(7)
The use of testing
143(2)
Test implementation
145(3)
The process of testing
148(2)
Case study: testing the VBB loan-application rules
150(12)
Setting up the ABC testing
150(1)
Assessing the rules
150(2)
Choosing test cases
152(1)
Implementing the rule tests
153(4)
VBB test results
157(5)
Metrics
162(4)
Guidelines
163(2)
Minimum metrics
165(1)
Quality summary
166(3)
PART III IMPLEMENTING BUSINESS RULES 169(90)
The Technology Environment
171(28)
More about architecture
171(2)
A typical reference architecture
173(6)
Business flexibility
176(2)
Shared resources
178(1)
Component architecture
179(6)
Interfaces
182(1)
Component interaction
183(2)
Transactions
185(2)
Server pages and scripting
187(1)
State management
188(1)
Implications for business rules
189(2)
Where rules live
191(6)
Client
191(1)
Channel tier
192(1)
Middle tier(s)
193(1)
Data services tier
194(2)
Legacy systems
196(1)
Summarizing the technology environment
197(2)
Realizing Business Rules
199(28)
Taking stock
199(1)
Distributing rules
200(1)
Realizing rules
201(23)
Program statements
202(2)
Scripts
204(1)
Rule components
205(2)
Rules engines
207(6)
Database mechanisms
213(5)
Workflow systems
218(2)
Look-up tables
220(2)
Flags and magic codes
222(2)
System rules
224(1)
Implementation summary
225(2)
Managing Business Rules and Models
227(32)
Life-cycle costs
227(1)
Managing evolution
228(7)
Coping with changes
228(5)
Automating housekeeping
233(2)
Deploying rules
235(5)
Testing a new system
235(1)
Rollout
236(1)
Supporting a live system
237(3)
Tools to support rule management
240(1)
Rule repository
241(17)
Why a repository?
241(1)
Repositories and rules engines
242(3)
An example repository design
245(13)
Rule management summary
258(1)
PART IV THE ROLE OF BUSINESS RULES 259(44)
A Wider View
261(28)
Marshaling intellectual resources
261(3)
Knowledge management
262(1)
Developing knowledge management
263(1)
Capturing knowledge
264(23)
What's the problem?
264(1)
Knowledge representation
265(2)
Enriched models
267(6)
Packaging for reuse
273(7)
New kinds of services
280(7)
Knowledge summary
287(2)
Summing Up
289(14)
The purpose of this book
289(1)
Models
289(1)
Trends
290(2)
Business process reengineering
290(1)
Quality management
291(1)
Reducing the maintenance burden
291(1)
Better specification
291(1)
Distributed computing
292(1)
Soft assets
292(1)
Business rule characteristics
292(2)
Rule populations
294(1)
Other properties
295(2)
Who?
295(1)
Where?
296(1)
When?
296(1)
Rule programming
297(1)
Advantages of business rules
298(5)
Business rule features
298(1)
Categories of benefits
299(4)
APPENDIX: A LITTLE BIT OF LOGIC 303(36)
A.1 Business logic
303(4)
A.1.1 Why logic?
303(1)
A.1.2 Logic and logics
304(1)
A.1.3 A logical framework
305(2)
A.1.4 Forms and symbols
307(1)
A.2 Propositions
307(8)
A.2.1 What's a proposition?
307(2)
A.2.2 Standard forms of proposition
309(1)
A.2.3 Visualizing propositions
310(2)
A.2.4 Alternative forms of propositions
312(3)
A.3 Logical operations
315(8)
A.3.1 Syllogisms
315(4)
A.3.2 Other kinds of arguments
319(4)
A.4 Handling logical values
323(14)
A.4.1 Nothing but the truth
323(2)
A.4.2 Combining logical values
325(4)
A.4.3 How many functions?
329(8)
A.5 Final words
337(2)
Selected Bibliography 339(2)
Index 341

Excerpts

Why this book 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. The goals of this book 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," pu

Rewards Program

Write a Review