Business Rules and Information Systems: Aligning IT with Business Goals / Edition 1

Paperback (Print)
Rent
Rent from BN.com
$14.93
(Save 75%)
Est. Return Date: 08/01/2015
Buy Used
Buy Used from BN.com
$35.29
(Save 41%)
Item is in good condition but packaging may have signs of shelf wear/aging or torn packaging.
Condition: Used – Good details
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 96%)
Other sellers (Paperback)
  • All (28) from $1.99   
  • New (10) from $26.83   
  • Used (18) from $1.99   

Overview

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:

  • Understanding the role of business rules and models in information systems development
  • Using models to structure and manage business activities, including e-commerce
  • Defining and discovering business rules
  • Controlling business rule quality
  • Fitting business rules into varied technical architectures
  • Implementing business rules using available technology

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.

0201743914B03042002

Read More Show Less

Editorial Reviews

Booknews
A business rule is a simple statement that represents some important aspect of a business. This book shows IT professionals how to apply business rules to create information systems aligned with business needs. It tells how to identify and express business rules, offers practical strategies for their use, and explains the key elements of logic that underpin their application. Information is useful for analysts, designers, developers, and technical managers. Morgan is a visiting research fellow at Brunel University, UK. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Read More Show Less

Product Details

  • ISBN-13: 9780201743913
  • Publisher: Addison-Wesley
  • Publication date: 3/18/2002
  • Series: Unisys Series
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 384
  • Product dimensions: 6.20 (w) x 9.00 (h) x 1.00 (d)

Meet the Author

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.

0201743914AB03112002

Read More Show Less

Read an Excerpt

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 buildinginformation 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/<break/>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 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..

Read More Show Less

Table of Contents

List of Figures.

Preface.

Acknowledgments.

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.

The Vision.

How Could It Be?

Some Implications.

Is This Really Practical?

Moving Forward.

Where We Stand.

2. Frameworks, Architectures, and Models.

Needful Abstractions.

Frameworks.

Architectures.

Models.

Case Study: A Sample Business Architecture.

Overview.

Business Objects.

Business Process Elements.

Narratives.

Business Events.

Actors and Roles.

Business Intentions.

Organizational Units.

Business Rules.

What Does a Complete Model Look Like?

Model Summary.

II. CAPTURING BUSINESS RULES.

3. Defining Business Rules.

Rule Statements.

Business Rule Characteristics.

Business Aspects.

What Should a Rule Say?

Levels of Expression.

OCL.

Forming Rule Statements.

Pattern Conventions.

Rule Patterns.

Rule Sets.

Static Models Versus Rule Statements.

References to Facts.

Terms and Rules.

Individual Items.

References to Multiple Items.

Business Parameters.

Tips on Rule Construction.

Using Facts.

Simple Constraints.

Quantifications and Qualifications.

States and Events.

Actors.

Dangerous Verbs.

Computation.

Structure and Consistency.

Case Study: Microsoft Outlook.

Outlook Rule Structure.

Conditions, Exceptions, and Actions.

Internals.

Logic.

Outlook Rule Features.

Rule Description Summary.

4. Discovering Business Rules.

That Which We Call a Rule.

Where Rules Come Rrom.

Information Sources.

Common Indicators.

Finding Rules.

Static Analysis.

Interactive Sessions.

Automated Rule Discovery.

Case Study: Loan Approval.

The Early Stages.

Fishbones.

Input Data.

Loan-assessment Rules.

Rule-discovery Summary.

5. Controlling Rule Quality.

Developing Quality Rules.

Reviewing Rules.

What to Look for in Reviewing Rules.

Roles.

Rule Context.

Tone.

Review Outcomes.

Review Records and Approvals.

Walkthroughs.

Planning and Preparation.

Conducting a Walkthrough.

Inspections.

Planning and Preparation.

Managing an Inspection.

Testing.

The Use of Testing.

Test Implementation.

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.

Metrics.

Guidelines.

Minimum Metrics.

Quality Summary.

III. IMPLEMENTING BUSINESS RULES.

6. The Technology Environment.

More about Architecture.

A Typical Reference Architecture.

Business Flexibility.

Shared Resources.

Component Architecture.

Interfaces.

Component Interaction.

Transactions.

Server Pages and Ccripting.

State Management.

Implications for Business Rules.

Where Rules Live.

Client.

Channel Tier.

Middle Tier(s).

Data Services Tier.

Legacy Systems.

Summarizing the Technology Environment.

7. Realizing Business Rules.

Taking Stock.

Distributing Rules.

Realizing Rules.

Program Statements.

Scripts.

Rule Components.

Rules Engines.

Database Mechanisms.

Workflow Systems.

Look-up Tables.

Flags and Magic Codes.

System Rules.

Implementation Summary.

8. Managing Business Rules and Models.

Life-cycle Costs.

Managing Evolution.

Coping with Changes.

Automating Housekeeping.

Deploying Rules.

Testing a New System.

Rollout.

Supporting a Live System.

Tools to Support Rule Management.

Rule Repository.

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.

Knowledge Management.

Developing Knowledge Management.

Capturing Knowledge.

What's the Problem?

Knowledge Representation.

Enriched Models.

Packaging for Reuse.

New Kinds of Services.

Knowledge Summary.

10. Summing Up.

The Purpose of This Book.

Models.

Trends.

Business Process Reengineering.

Quality Management.

Reducing the Maintenance Burden.

Better Specification.

Distributed Computing.

Soft Assets.

Business Rule Characteristics.

Rule Populations.

Other Properties.

Who?

Where?

When?

Rule Programming.

Advantages of Business Rules.

Business Rule Features.

Categories of Benefits.

Appendix: A Little Bit of Logic.

Business Logic.

Why Logic?

Logic and Logics.

A Logical Framework.

Forms and Symbols.

Propositions.

What's a Proposition?

Standard Forms of Proposition.

Visualizing Propositions.

Alternative Forms of Propositions.

Logical Operations.

Syllogisms.

Other Kinds of Arguments.

Handling Logical Values.

Nothing but the Truth.

Combining Logical Values.

How Many Functions?

Final Words.

Selected Bibliography.

Index. 0201743914T03042002

Read More Show Less

Preface

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

.

0201743914P03042002

Read More Show Less

Introduction

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

.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)