Home > Store

Business Rules and Information Systems: Aligning IT with Business Goals

Register your product to gain access to bonus material or receive a coupon.

Business Rules and Information Systems: Aligning IT with Business Goals


  • Sorry, this book is no longer in print.
Not for Sale

eBook (Watermarked)

  • Your Price: $38.39
  • List Price: $47.99
  • Includes EPUB, MOBI, and PDF
  • About eBook Formats
  • This eBook includes the following formats, accessible from your Account page after purchase:

    ePub EPUB The open industry format known for its reflowable content and usability on supported mobile devices.

    MOBI MOBI The eBook format compatible with the Amazon Kindle and Amazon Kindle applications.

    Adobe Reader PDF The popular standard, used most often with the free Adobe® Reader® software.

    This eBook requires no passwords or activation to read. We customize your eBook by discreetly watermarking it with your name, making it uniquely yours.


  • Copyright 2002
  • Dimensions: 6-1/4" x 9-1/4"
  • Pages: 384
  • Edition: 1st
  • Book
  • ISBN-10: 0-201-74391-4
  • ISBN-13: 978-0-201-74391-3

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.


    Sample Content

    Sample Pages

    Download the sample pages (includes Chapter 3 and Index)

    Table of Contents

    List of Figures.




    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.




    Case Study: A Sample Business Architecture.


    Business Objects.

    Business Process Elements.


    Business Events.

    Actors and Roles.

    Business Intentions.

    Organizational Units.

    Business Rules.

    What Does a Complete Model Look Like?

    Model Summary.


    3. Defining Business Rules.

    Rule Statements.

    Business Rule Characteristics.

    Business Aspects.

    What Should a Rule Say?

    Levels of Expression.


    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.


    Dangerous Verbs.


    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.

    Information Sources.

    Common Indicators.

    Finding Rules.

    Static Analysis.

    Interactive Sessions.

    Automated Rule Discovery.

    Case Study: Loan Approval.

    The Early Stages.


    Input Data.

    Loan-assessment Rules.

    Rule-discovery Summary.

    5. Controlling Rule Quality.

    Developing Quality Rules.

    Reviewing Rules.

    What to Look for in Reviewing Rules.


    Rule Context.


    Review Outcomes.

    Review Records and Approvals.


    Planning and Preparation.

    Conducting a Walkthrough.


    Planning and Preparation.

    Managing an Inspection.


    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.



    Minimum Metrics.

    Quality Summary.


    6. The Technology Environment.

    More about Architecture.

    A Typical Reference Architecture.

    Business Flexibility.

    Shared Resources.

    Component Architecture.


    Component Interaction.


    Server Pages and Ccripting.

    State Management.

    Implications for Business Rules.

    Where Rules Live.


    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.


    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.


    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.


    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.



    Business Process Reengineering.

    Quality Management.

    Reducing the Maintenance Burden.

    Better Specification.

    Distributed Computing.

    Soft Assets.

    Business Rule Characteristics.

    Rule Populations.

    Other Properties.




    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.


    What's a Proposition?

    Standard Forms of Proposition.

    Visualizing Propositions.

    Alternative Forms of Propositions.

    Logical Operations.


    Other Kinds of Arguments.

    Handling Logical Values.

    Nothing but the Truth.

    Combining Logical Values.

    How Many Functions?

    Final Words.

    Selected Bibliography.
    Index. 0201743914T03042002


    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.




    Acceptance testing, 235, 236
    Access. See Microsoft Access
    Active Server Pages (ASP), 187
    Activity diagrams, 38
    Actor catalog, 48
    questioning, 86
    roles and, 47-50
    as subjects, 86-87
    Agents, software, 280-282
    Alexander, Christopher, 277
    Analysis workshops, 117-119
    logic function, 327
    using, 83
    Architectures, 22-24, 171
    See also under type of
    Associations, 31-32
    Assumptions, questioning basic, 80
    Attributes, 30, 32-33
    Authentication, 193
    Author role, 134, 144
    Automated rule discovery, 110, 119-121
    Automation, to manage rules, 233-235
    Automation systems, 105
    Availability management, 240
    Basic constraint pattern, 69
    Behavioral rules, 103
    Blackboard systems, 276
    Boole, George, 304
    Business architecture, defined, 22-23
    Business architecture, example of
    actors and roles, 47-50
    business rules, 54-55
    events, 44-47
    intentions, 50-53
    narratives, 39-44
    objects, 28-35
    organizational units, 53-54
    overview, 27-28
    process elements, 35-39
    Business continuity, 239
    Business logic
    reasons for, 303-304
    use of term, 6, 190, 193
    Business model
    example of, 55
    introducing, to your organization, 26-27
    outer limits, 17, 18
    reasons for, 24-25, 289-290
    structure and notations, 25-26
    use of term, 17
    Business parameters, 77-79
    Business process reengineering (BPR), 36, 290
    Business records, 105
    Business rules
    advantages of, 298-301
    applications, 61
    characteristics, 59-66, 292-294
    defined, 5-6, 54
    forming, 66-72
    levels of expression, 63-65
    locating, 109-121
    populations, 294-295
    sets, 71
    sources for, 102-109
    types of, 102-104
    Business rules, common construction problems
    actors, 86-87
    computation, 88
    qualifications, 84-85
    simple constraints, 81-84
    states and events, 85-86
    structure and consistency, 88-91
    using facts, 79-81
    verbs and, 87-88
    Business stories, 39
    Business type, 29
    Capacity management, 239-240
    Cardinality, 31, 71-72
    Cascading updates, 215
    coping with, 228-233
    identifying, 228-229
    introducing, 238-239
    Channel tier, rules in, 192-193
    Check constraints, 215
    Classes, 30-31
    Classification pattern, 70
    Client layer, rules in, 191-192
    Code analysis, 120-121
    Compiled rules, 207, 208
    Complex rules, 83-84
    COM+, 186-187
    Component architecture
    benefits of, 180
    defined, 23, 179
    features of, 181
    interactions, 183-185
    interfaces, 182-183
    Component object model (COM), 181, 182, 183
    Components, implementing rules in rule, 205-206
    ambiguous, 88
    embedded, 88
    pattern, 70
    Conceptual dependency (CD), 270-272
    Conflicting rules, 90
    Conjunction, 327
    Consistency, maintaining, 229-231
    Constants, 77
    role of, 194-195, 214-216
    on structures, 195
    on values, 195
    Context, grouping rules by, 135-136
    Contrapositive, 314-315
    Control mechanism, 207, 208
    Converse, 313
    Cookies, 189
    CRUD-type words, 87-88, 213
    Custom program, 145-146, 155-156
    Cyc project, 280
    Database mechanisms, implementing rules in, 213-218
    Data-driven inference, 210-211
    Data mining, 119-120
    Data services tier, rules in, 194-196
    De Morgan, Augustus, 330
    De Morgan's theorems, 330
    Decision making (automated), as a rule indicator, 107
    Definitional rules, 104
    Definitions or formulas, as a rule indicator, 109
    Deploying rules, 235-240
    Developer role, 144
    Development process, improvements to, 6-13
    activity, 38
    fishbone/Ishikawa, 122-125
    flow, 38-39
    hierarchy, 37-38
    use case, 39, 43-44
    Venn, 76, 310-312, 330, 331
    Discriminators, as a rule indicator, 108
    Disjunction, 320-321, 327-328
    Distributed computing, 292
    Distributed transaction coordinator (DTC), 186
    Distributing rules, 200-201
    Documentation, 104
    analyzing, 113-115
    types of source, 111-113
    Dot notation, 74-75
    Duplication of rules, 89
    "Each" and "every," using, 85
    ebXML (electronic business XML), 284
    Electronic data interchange (EDI), 284
    Enablers, 52
    Enactments, 35
    Enterprise JavaBeans, 23, 181, 187
    Enterprise model. See Business model
    Enthymemes, 318-319
    Enumeration pattern, 71
    Enumerations, as parameters, 78
    Equivalence, 328
    Event-condition-action (ECA) rules, 46
    defined, 44
    examples of, 44-46
    as a rule indicator, 108
    rules, 46
    as subjects, 85
    using, with UML, 47
    Exclusive-or, 82-83, 328-329
    Expert systems, 200, 212
    Expression, levels of, 63-65
    External sources
    as a rule indicator, 106
    types of, 111-112
    Fact model
    application, 79-80
    individual items, 74-75
    references to multiple items, 75-76
    terms and rules, 72-74
    Facts, obscure, 81
    Fishbone diagrams, 122-125
    Flags, 222-224
    Forward-chaining systems, 276
    Framework for Enterprise Architecture, 19-21
    Frameworks, 19-21
    Gatekeepers, 219
    Goal-driven inference, 211
    Goals, 50-53
    Grouping rules by context, 135-136
    Guards, 219
    GUIDE, 6
    Hamming, R. W., 287
    Handbook of Artificial Intelligence (Barr and Feigenbaum), 268
    Hard-coding, 77
    Housekeeping, automated, 233
    HTTP, 282, 283
    Hypotheticals, 321-323
    "If," using, 84
    Implementing rules
    in database mechanisms, 213-218
    factors to consider when, 202
    flags and magic codes, 222-224
    in look-up tables, 220-222
    principles of, 199-200
    in program code/statements, 202-204
    in rule components, 205-206
    in rules engines, 207-213
    in scripts, 204-205
    in workflow systems, 218-220
    Implication, 329
    Inclusive-or, 82-83
    Individual items, 74-75
    Inference mechanisms, 207, 208, 210-211
    Information constraints, as a rule indicator, 108-109
    Information sources, 104-105
    Inspections, 132, 140-143
    Integration testing, 235
    Intentions, 50-53
    Interactive sessions, 110, 115-119
    Interception, 185
    Interfaces, 182-183
    Internal sources, 111
    Interviews, structured, 116-117
    Invariants, 59
    Inversion of rules, 89-90
    Ishikawa diagrams, 122-125
    JavaScript, 204
    Java Server Pages (JSP), 187
    Just-in-time (JIT) instantiation, 184, 204
    Karnaugh Map, 334-336
    Kipling, "The Elephant's Child", 20
    Knowledge, capturing
    defining the problem, 264-265
    enriched models, 267-273
    new kinds of services, 280-287
    packaging for reuse, 273-280
    representing in machine-readable form, 265-267
    Knowledge-based systems, 273-277
    Knowledge elicitation protocols, 39
    Knowledge management
    developing, 263-264
    purpose of, 262-263
    Knowledge sources (KSs), 276
    Legacy systems, rules in, 196-197
    Life-cycle costs, 227-228
    Links, 267-270
    List constraint pattern, 69-70
    Loan approval example, locating rules and
    fishbone/Ishikawa diagrams, 122-125
    initial stages, 121-122
    input data, 125-126
    rules that were created, 127-129
    Loan approval example
    assessing rules, 150-152
    choosing test cases, 152-153
    custom program, use of, 155-156
    real life applications, 161-162
    rules engine, use of, 156-157
    spreadsheets, use of, 153-155
    test results, 157-161
    Locating rules
    automated rule discovery, 110, 119-121
    in channel tier, 192-193
    in client layer, 191-192
    in data services tier, 194-196
    interactive sessions, 110, 115-119
    in legacy systems, 196-197
    loan approval example, 121-129
    in middle tiers, 193-194
    static analysis, 110-115
    in technical architecture, 191-197
    deductive versus inductive, 305
    fuzzy, 304-305
    nonstandard/deviant, 304
    predicate, 337
    propositional, 308
    standard/classical, 304
    symbolic, 307
    Logic server. See Rules engine
    Logic simulator, 240
    Logic structure, Microsoft Outlook, 97-98
    Look-up tables, implementing rules in, 220-222
    Magic numbers, 77
    Maintenance, reducing, 291
    Managing rules
    See also Repository
    automation to, 233-235
    deploying rules, 235-240
    evolution of, 228-235
    tools that support, 240-241
    Memory organization packets (MOPs), 272-273
    Meta Object Facility (MOF), 25
    Metrics, 162-166
    Active Server Pages (ASP), 187
    DNA (Distributed interNet Architecture), 173-179
    Passport, 282-283
    Windows NT 4.0, 186
    Windows 2000 and COM+, 186-187
    Microsoft Access, repository implementation, 245-258
    Microsoft Outlook
    conditions, exceptions, and actions, 92-96
    internal code, 97
    logic structure, 97-98
    rule features, 99-100
    rule structure, 91-92
    Middle tier(s), rules in, 193-194
    Missing rules, 88-89
    Modeling tool, 240
    Models, 24-27
    Moderator, 134
    Multiple items, 75-76
    Multiple models, managing, 231-233
    Multiple states, as a rule indicator, 106
    Multiplicity, 31, 71-72
    N-tier architecture, 174
    defined, 39
    example of, 39-40
    purpose of, 40
    size of, 42-44
    structure of, 40-42
    style of, 42
    tool support, 44
    Negation, logical, 326
    Nodes, 267-270
    "Not", logic function, 326
    Nullable fields, 195, 214
    Object Constraint Language (OCL), 65-66
    Object Management Group (OMG), 25
    associations, 31-32
    attributes, 30, 32-33
    classes, 30-31
    defining, 28-30
    state, 33-35
    Obverse, 314
    Ontology, business, 279-280
    logic function, 327-329
    using, 82-83
    Oracle, 213
    Organizational units, 53-54
    Outlook. See Microsoft Outlook
    Overelaboration, 82
    Overlapping rules, 89
    Parallel approach, 232-233
    Parameters, 77-79
    Patterns, 66
    analysis and design, 277-279
    basic constraint, 69
    classification, 70
    computation, 70
    conventions, 68
    enumeration, 71
    list constraint, 69-70
    role of, 67
    Permission statements, 81-82
    defined, 35
    elements, 35-39
    example of, 36
    flow, 38-39
    hierarchy, 37-38
    Production rules, 274
    Program code/statements, implementing rules in, 202-204
    Programming, rule-based, 297
    Prolog, 147
    Proof-of-concept (POC), 236
    Properties, 30
    alternative forms of, 312-315
    categorical, 308
    defined, 307-309
    standard forms of, 309-310
    visualizing, 310-312
    Proxy, 184-185
    Qualifications, 84-85
    Quality control mechanisms
    inspections, 132, 140-143
    loan approval example, 150-162
    metrics, 162-166
    summary of, 167
    testing, 132, 143-149
    trends in, 291
    walkthroughs, 132, 139-140
    Quality manual, as a rule indicator, 108
    Quality rules, developing, 131-133
    Realizing rules. See Implementing rules
    Recordkeeping, for reviews, 137-139
    Reference architecture, 172, 173-179
    References, complete versus consistent, 90
    Referential integrity, 195, 214
    Reification, 31
    Relational model, 213
    Relationships, making explicit, 81
    example of, 245-258
    information, 90-91
    purpose of, 241-242
    rule engines and, 242-245
    Requirements analysis, 24
    Resource description framework (RDF), 286-287
    RETE algorithm, 208
    Reviewers, 134
    Reviewing rules
    grouping rules by context, 135-136
    outcomes, 136-137
    records and approvals, 137-139
    roles, 134
    tone for, 136
    what to look for, 133-134
    Risks, 52-53
    Role-activity diagrams (RADs), 38
    allocating, 134
    names, 32
    reviewing, 134
    testing, 144-145
    Rollout, 236-237
    Rule components, implementing rules in, 205-206
    Rule construction, tips on, 79-91
    Rule definer, 240
    Rules engine, 146-147, 156-157
    deployment, 211-212
    expert systems and, 212
    expression, 209-210
    implementing rules in, 207-213
    inference mechanisms, 210-211
    main elements in, 207-208
    pros and cons of, 212-213
    respositories and, 242-245
    Schank, Roger, 270
    Scribe, 134
    Scripting, 187-188
    implementing rules in, 204-205
    sequence of actions, 272
    Semantic networks, 267-270
    Semantics, 285
    Sequential approach, 232
    Server pages, 187-188
    Service-level management, 240
    Servlets, 187
    SOAP (Simple Object Access Protocol), 283
    Soft assets, 292
    Software agents, 280-282
    Sorites paradox, 319
    common indicators, 105-109
    documents, analyzing, 113-115
    documents, types of, 111-113
    information, 104-105
    knowledge, 276
    Source rules, 207, 208
    Specialization/generalization relationship, 268
    Specifications, trends for better, 291
    Spreadsheets, 145, 153-155, 199
    SQL Server, 213
    State management, 188-189
    Statements, rule, 66
    States, 33-35
    ambiguous, 85
    component, 184
    multiple, as a rule indicator, 106
    Static analysis, 110-115
    Static models, 71-72
    Stored procedures, 216-218
    Stovepipe systems, 176-177
    Structural rules, 102-103
    Structured interviews, 116-117
    Structures, constraints on, 195
    Stub, 183-184
    Subclasses, as a rule indicator, 107
    Subdivisions, as a rule indicator, 106
    Syllogisms, 315-319
    Symbols, 307
    System development process
    description of new method for, 9-11
    description of traditional, 6-8
    practicality of new method, 11-13
    System rules, 224-225
    Tacit know-how, 104
    Technical architecture
    business flexibility, 176-177
    component, 179-185
    defined, 23, 172
    implications for business rules, 189-191
    locating rules, 191-197
    properties, 172-173
    reference, 172, 173-179
    server pages and scripting, 187-188
    shared resources, 178-179
    state management, 188-189
    transactions, 185-187
    Templates, rule, 67, 250
    obscure, 81
    plural, 84-85
    questioning, 80
    unqualified, 81-82
    vague, 81
    Testers, 145
    example of, 150-162
    implementation of, 145-148
    a new system, 235-236
    process, 148-149
    purpose of, 132, 143-145
    roles, 144-145
    Three-tier architecture, 174
    Threshold values, as a rule indicator, 107
    ambiguous, 86
    as a rule indicator, 107-108
    Tools, rule management, 240
    Transactions, 185-187
    Transitivity, 319-320
    Triggers, 104, 218
    Truth tables, 325-326
    Turing, Alan, 265
    UDDI (Universal Discovery Description and Integration), 283
    Unified Modeling Language (UML), 25-26
    using events with, 47
    Unit testing, 235
    Use case diagrams, 39, 43-44
    constraints on, 195
    handling logical, 323-336
    Variants, versions versus, 230-231
    VBScript, 187, 204, 205
    Venn, John, 310
    Venn diagrams, 76, 310-312, 330, 331
    action, 87
    command, 87
    Version number, 228-229
    variants versus, 230-231
    Visual Basic, 145, 147, 187, 203, 233
    Visual Basic for Applications (VBA), 233
    Web services, 282-284
    Walkthroughs, 132, 139-140
    When?, 86, 296-297
    Where?, 296
    Who?, 295-296
    Whole/part relationship, 269
    Workflow systems, implementing rules in, 218-220
    Working memory, 207, 208
    Workshops, analysis, 117-119
    WSDL (Web Services Description Languge), 283
    XML, 14, 248-249283, 284
    XML Metadata Interchange (XMI), 25
    Zachman, John, 19
    Zachman Framework, 19-21


    Submit Errata

    More Information

    Unlimited one-month access with your purchase
    Free Safari Membership