Introduction

Team-Fly    

 
Requirements Analysis: From Business Views to Architecture
By David C. Hay
Table of Contents
Chapter 8.  Column Six: Motivation

Introduction

Interest in business rules is not a recent phenomenon , but its role in systems development has escalated significantly in recent years . Figure 8.1 shows the Architecture Framework with Column Six highlighted.

Figure 8.1. The Architect FrameworkMotivation.

graphics/08fig01.jpg

When the computer industry began, there were programs. All attention was paid to writing programs that performed functions. Beginning in the 1970s and more fully during the 1980s, people began to focus on data. Then, John Zachman published his architecture in 1987, adding location, reflecting the fact that distributed systems were all the rage. In 1992, he and John Sowa expanded these notions of "what", "how", and "where" to include "who", "when", and "why": people and organizations, timing, and motivation. The first five elements were fairly well understood . It was less clear what to do with "why".

It seemed that from the scope point of view motivation consists of things like mission and vision, and the business owners ' views are concerned with things like objectives and goals, but none of this was formalized , and it was uncertain what should be done with the other rows.

At about the same time, Ronald G. Ross recognized that the rules determining the integrity of a business's data were not adequately dealt with in the systems development process:

Specific integrity rules [of an enterprise], even though "shared" and universal,... traditionally have not been captured in the context of its [data] models. Instead, they usually have been stated vaguely (if at all) in largely uncoordinated analytical and design documents, and then buried deep in the logic of application programs. Since application programs are notoriously unreliable in the consistent and correct application of such rules, this has been the source of considerable frustration and error. It sometimes also has led, unjustly, to distrust of the data model itself [Ross, 1987, p. 102].

In the early 1990s business rules and the "why" column began to come together with the formation of The Business Rules Group as a project within GUIDE, IBM's user group. In 1994, Mr. Ross then published the first edition of his Business Rules Book , and Barbara von Halle began writing articles on business rules for the data industry magazine, Data Base Programming and Design .

Suddenly business rules began to attract attention as a way of improving systems by better describing the world they addressed.

It was discovered that just describing what processing should be done and what data should be manipulated was not sufficient. There are rules and constraints that control processing and that constrain data valuesand failure to address these is failure to address a major part of the effort.

In 1988, for example, one analyst dutifully prepared data models and function models for a large communications company and turned these over to a programmer, so that the latter could produce a system to process invoices. It quickly became evident, however, that very complex rules were associated with the invoices and the accounts to which they should be credited. These were not described in the analyst's models. The programmer was now forced to spend many hours with the accountants to learn these rulessomething that should have been done by the analyst. [1]

[1] Yes, that analyst would be your author.

Since business rules are derived from business policies, and these in turn are the direct implementation of business goals and objectives, they seemed at home in Column Six, the "why" column.

One of Mr. Ross' insights was that, contrary to what might be supposed, in the context of system development a business rule is ultimately about data, not about processing. It is a constraint on what data may or must be updated. If a particular row in a table can be updated only when certain constraints are met, it does not matter which process is trying to do the updating: The rule lives with the data.

To be sure, the rules themselves are not part of the data, even though they act upon them. Indeed, business rules are often implemented through program processing. In recent years there has been a movement to build "rules engines" specifically to separate the definition and execution of business rules both from the database and from other processing. But again, if a rule constrains what can be updated in a database, that rule applies no matter what processes try to do the updating.

In 1995 The Business Rules Group (the GUIDE organization mentioned above) published a white paper, Business Rules: What Are They Really? , describing the nature of business rules from a Row Three perspective. This addressed the question of how rules interact with data, and it described categories of rules from the architect's Row Three perspective. In 2000 The Business Rules Group published a second paper, Organizing Business Plans: The Standard Model for Business Rule Motivation, describing the business owners' Row Two approach to business rules. The paper presents a data model of such concepts as "mission", "vision", "strategy", "tactics", and so forth. It discusses a business's ends and means and the role that rules and business policies play in establishing and managing these. It defines more precisely than ever before these motivation terms, which tend to be used cavalierly in modern business.

The second paper describes why a business does what it does, while the first paper describes why a system should behave the way it does.

The Business Rules Group Motivation Model is shown in Appendix C. This was created without cardinality or optionality designations. An extended model with these included is in Appendix D.

Most recently, in 2002, Ms. von Halle has published an extensive discussion of business rules, Business Rules Applied . In it she describes in detail just how business rules should be captured and organized as part of a system development project.

The first part of this chapter is based on the Business Rules Group Motivation model and on Ms. von Halle's book. The remainder is a description of various techniques for representing business rules.


Team-Fly    
Top
 


Requirements Analysis. From Business Views to Architecture
Requirements Analysis: From Business Views to Architecture
ISBN: 0132762005
EAN: 2147483647
Year: 2001
Pages: 129
Authors: David C. Hay

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net