Business Rules Analysis in the Real World
The business rules approach to information systems development is becoming more and more widely accepted. At conferences and user group meetings, there are whole tracks devoted to business rules. Many papers, presentations and articles about this topic are available in publications and on the Internet. There are also many products purporting to operate in the business rules space. Is this “new” business rules-based system development approach simply the latest hype or does it truly represent a shift in thinking about how to design and build information systems?
What is a Business-Rules Approach?
In most traditional software development life cycles, analysis is focused on gathering system requirements. A business rules approach is a different way of thinking about the analysis process. Rather than focusing on system requirements, the analysis process is refocused on business rules. Instead of asking users what they want their system to do, they are asked about how their business or organization works.
Experienced and successful analysts will recognize that this is something that they have always done. Good analysts have always recognized the importance of understanding the business for which the system is being designed. Analysis is more than simply gathering system requirements from the users. For expert analysts, gathering the “system requirements” has always really meant gathering the “business rules”. Therefore, is this business-rules based systems development really a “new” approach? Actually, it is a better and more precise way of describing excellent systems analysis.
Gathering business rules entails gathering statements about the objects of interest to the organization and how they behave. An example of a business rule that a user would describe might be “All purchase orders over $50,000 must go through three levels of approval.” Note that nothing is said about how the system would accomplish this. It is merely a statement of how the business operates.
Business rules are represented using statements such as the one in the previous paragraph. Some business rules approaches suggest that rules can be structured using a grammar (formal or informal) or diagramming syntax, but the information content is the same.
Analysis done from a business rules perspective need not significantly differ from any traditional analysis process. Business rules can be organized using use cases, a traditional function hierarchy, or any other structure.
Analysis Rules vs. Implementation Rules
Business rules gathered from users do not provide sufficient information to build a system. Rules gathered at the level of detail that users typically describe are too general to be able to be implemented. We call such rules “analysis rules.”
In order to successfully implement an analysis rule in a system, more information must be gathered. Detailed descriptions of the rules are called “implementation rules.” This is not to say that the detailed implementation rules are the implementation of the analysis rule, but rather that the implementation rules provide sufficient detail so that the analysis rules can be implemented. The actual implementation of the rule is still not specified.
In summary, there are two different types of business rules:
· Analysis (high-level) rules are stated in a way that is very close to the way in which users think and talk.
· Implementation (detailed) rules include a complete specification with sufficient detail to allow the system to generate code and database structures.
Implementation rules cannot be represented in the same way that users think and talk. Human language is neither precise nor compact enough to allow for the management of the massive volume of rules that are needed to specify a system. One way to handle this process is with a business rule based tool. As an example, Dulcian’s Business Rules Information Manager (BRIM™) uses data models and process flows to store the implementation rules.
Analysis Rules
There has been much more work done by many different people in the area of analysis rules than in the implementation rules area. Most of the business rules community tends to focus on the analysis side of the process. Examining this body of work reveals a wide range of approaches from extreme formalism where business rules are articulated using a specialized syntax (often unfortunately reminiscent of formal mathematical logic) to easily readable English sentences with no specific structure at the other end of the spectrum.
This situation presents a paradox of two differing requirements. On one hand, business rules should be readable by end users and on the other hand, they must be precise enough to be used to build a system. It is important to recognize that it may be impossible to create a business rules development environment to simultaneously meet both the readability and precision requirements. Although it is possible to create and use a precise and readable rule grammar, gathering all of the business rules for a typical system this way inevitably leads to an unwieldy number of rules to be implemented.
As an example, the following business rule could be required in a typical system: “After the goods associated with a purchase order have been shipped, the shipping address should never be changed unless there was a simple data entry error. Even in this case, only a manager should be allowed to make the change.” For implementation purposes, including this type of business rule means that for every attribute of every object, every state that an object can go through, every role existing within an organization and the specific circumstances for that object, the system must be flexible enough to control what attributes are viewable or editable along with any additional restrictions that may or may not apply. If each object has an average of ten logical states, a total of several thousand attributes and 2-10 relevant roles for each type of object, for this one type of rule, a few hundred thousand questions would need to be asked of a user. This is not feasible when building a system. Assumptions must be made. In the example above, attributes would be displayed and editable in all contexts. Therefore for these types of rules, it makes no sense to gather them in English sentence format. Instead, these kinds of rules easily lend themselves to a small rule repository, the structure of which is shown in Figure 1.
Figure 1: Simple Rule Repository Structure
It is easy to imagine a simple database application to support this structure. Figure 1 is also an example of the previously mentioned implementation rules idea, namely a relatively precise representation that is fairly easy to understand and not text-based. Within the Oracle community, this is not a new approach. ERDs and reference table values are themselves small business rule repositories.
The question then remains: How many rules should be gathered at the analysis level? There seems to be general agreement that the number of analysis-level rules gathered should be small and manageable. For a large system, approximately 1,000 rules may be gathered. Each rule may be a short paragraph. As a group, these paragraphs will describe the system to be built. This document ends up being very much like any traditional analysis document that IT professionals have been creating for years.
How Should Analysis Rules be Gathered?
There doesn’t seem to be any one correct answer to this question. I have reviewed the many different ways that others have chosen to represent business rules. There was little consistency among approaches. Methods of gathering and organizing the business rules which worked well for one team didn’t always work well for another team.
The rules themselves should be represented in such a way that users can read, enter and edit them themselves. Any approach using a grammar that is unreadable by users is of little or no value.
This is not to say that paragraphs of rules should be gathered with no structure at all. Business Rule Solutions’ RuleSpeak™ tool applies a minimal structure to the rule gathering process and also creates an adequate level of consistency for the rule grammar and rule representations. It is beyond the scope of this paper to discuss the RuleSpeak syntax; however, most rules are expressed using the following syntax: “subject” must “condition” only if “modifier.” For example, “A purchase order must be approved by a senior manager only if the total amount is greater than $50,000.” Using the basic formal structure of starting with the subject (which usually translates to a class or table upon implementation) followed by the modifier brings a useful consistency to the expression of the rules in English sentences.
How Should the Rules be Grouped?
Having a thousand or more complex statements describing a system with no organization is not useful or manageable. Some rules may be modifiers of other rules (sub-rules).
One project that the author worked on required gathering rules to describe the process of how individuals are recruited into the US Air Force Reserves. Initially, rules were gathered as paragraphs with no specific structure. In examining the rules, it was observed that most could be associated with a particular type of recruit. A few types spanned all recruit types. As more rules were added, it was apparent that the recruiting process went through a few large, logical steps, namely Prospects à Leads à Applicants à “Gains” (enlisted). Therefore, the rules pertaining to this process could be broken down by recruitment status as shown in Figure 2.
Figure 2: Recruit Status Structure
This model allowed us to modify the structure of the rules database dynamically as the project evolved. This seems to be the right approach since it allowed the system to be flexible enough to handle changes to the rules and rule structures as needed.
Implementation Rules
Once the analysis rules are gathered, there is still not enough information to build a system at this point. It is necessary to create the implementation (specific) rules. The analysis rules serve as detailed rule categories for the tens of thousands of rules required in the actual production system. Implementation rule gathering can be done as part of the analysis process. As analysis rules are gathered, they can immediately be further analyzed down to the implementation level. Alternatively, implementation rules could be considered a separate part of the analysis process (detailed analysis). Some system architects might consider this implementation rules specification to be part of the design process. When and how these implementation rules are gathered is a design decision on the part of the architect. Dulcian’s suggestion for how to integrate BRIM™ into the SDLC can be examined in the BRIM™ System Development Life Cycle document at http://www.dulcian.com/BRIM.htm
How Should the Implementation Rules be Structured?
Again there is little consensus in the right way to gather detailed rules. Most business rules products focus on process rules only. Most tend to use an STE or flowchart approach. Representation of structural rules is virtually unknown among business rules products.
Within Dulcian’s business rules environment, structural business rules are represented in a data model-like format which is easily recognizable to relational database professionals. Unified Modeling Language (UML) class models were selected as the appropriate syntax since these diagrams have significant advantages over ERDs. (A full discussion of this topic can be found on the Dulcian website www.dulcian.com under Publications/Magazine Articles, “UML Class Models as a Data Modeling Tool.”)
For process-related rules, UML activity diagram syntax was used with some significant diagrammatic extensions to support many different classes of rules. Both class and activity diagram types work together. Classes (corresponding roughly to entities in ERDs) can either be “regular” or objects in those classes may pass through states.
The simplified implementation rule repository is structured as shown in Figure 3.
Figure 3: Implementation Rule Repository
Using this structure, classes have states which allow them to transition to other states within the same class. The actual structure of the repository is quite complex (see the BRIM™ whitepapers at http://www.dulcian.com/BRIM.htm for more detailed information).
This is not the only possible solution to the problem of representing implementation rules. Other radically different approaches may eventually emerge. To some extent, this solution evolved because of our familiarity with Oracle Designer and other similar products. It would not be surprising for those coming from an object-oriented programming perspective to create a very different structure.
Regardless of the approach used, the separation of analysis and implementation rules is appropriate. A universal optimal analysis structure does not exist. Any rigid structure used to try to support business rules analysis will fail.
Connecting Analysis and Implementation Rules
Analysis rules must be linked to implementation rules that are the precise, formal articulations of the analysis rules. The implementation rules contain much more information than the analysis rules. In order to guarantee that all analysis rules have been included in the implementation, a mapping must be done between the two rule sets.
Since the implementation rules can be quite detailed, including rules at the object, attribute, state, and role levels, mapping can be a very difficult task. At what level should the analysis rules be attached? Class? Attribute? Most rules naturally apply to one or more classes or one or more states within a class. Analysis rules that have been gathered rarely attach at the attribute level. This may be due to the types of questions asked during the analysis process at a relatively high level. In the BRIM™ environment, the implementation rules are used to handle the detailed analysis. Therefore, the process may vary depending upon the tools being used for analysis and implementation.
Mapping between the two sets of rules can be accomplished by combining the analysis and implementation models as shown in Figure 4.
Figure 4: Analysis/Implementation Model
As shown in Figure 4, rules are implemented in one or more states or classes. States and classes appear on diagrams so that rules can be attached at the diagram level as well.
In the BRIM™ environment, this association is handled by allowing users to flag tables as repository extensions eligible for this type of attachment. Using this approach, it is possible to have many different rule tables, some using freeform structures and others using rule templates for very structured rules.
Implementation
It is difficult to discuss implementation in a general way since it is dependent upon the structure of the implementation rule repository which drives how the system will be generated. Using the BRIM™ repository as an example, the class diagram translates into tables, views and triggers using an algorithm similar to how Oracle Designer generates tables. Process flow diagrams (state transitions) mostly impact the applications. Some of the process information is generated to procedures. Other process information drives views so that when an application is required to determine when a particular attribute can be edited or displayed, this determination can be generated into the application before runtime or accessed at runtime (and not hard coded) depending upon performance requirements.
Why Use a Business Rules Approach?
Traditionally, most systems are designed using the communication process shown in Figure 5. Users tell IT professionals what their system requirements are during the analysis phase. Some type of analysis document is generated. The IT professionals then build the system and deliver it to the users. Even with the best RAD approaches, the cycle time from rule/requirement specification to a working system is significant (days, weeks or even months). In order to validate that the system has met the specified requirements, users must interact with the system to reverse engineer their requirements and compare these with their originally stated business rules.
Figure 5: Traditional System Design Process
This approach can break down in many places including:
1. Translating the business rules from the users’ heads to the analysis document
2. Interpreting the analysis document into system design specifications
3. Implementing the system design specifications
4. Users validating original business rules in delivered system
Poor communication is certainly not the only reason that many systems fail, but this traditional approach creates a communication environment in which it is very difficult to succeed.
The alternative communication process in the rules-based environment is shown in Figure 6.
Figure 6: BRIMä System Development Process
In this environment, users and IT professionals work together to specify the rules and place them into the rules repository. This repository acts as a common point of communication for both users and IT professionals. The advantages of developing systems in a rules environment are as follows:
· Rules are represented in a format that is understandable by users. Users can help enter and manipulate the rules.
· Rules are represented in a format that can be used by IT professionals as a system design document.
· Generators can immediately generate a working version of the system.
A key difference between the traditional communication process and the business rules-based communication process is that the information in the repository can be understood and used by users, IT professionals and the system generators. The only potential communication breakdown in this environment is in going from the users heads to the repository rules. Since it is possible to generate almost immediate feedback from the entered rules, users can quickly interact with the system and evaluate whether or not the business rules they envisioned have been accurately represented. As soon as the rules are specified, they can be evaluated in a working system.
Finally, a real benefit of the business rules approach is that the rules repository forms the full system specification allowing for independent decisions about handling the rules. This is true even for substantial changes to the system architecture. For example, in the current uncertain web application environment, systems built today using Oracle Form Builder or Visual Basic may need to be deployed in JavaServer Pages or Java clients in JDeveloper or .Net. The best defense against this uncertainty is to hard code as little of the program logic into the applications as possible. This is not to say that application code cannot reside in applications when using a business rules approach. Instead, generators can be created to take the code from a repository and generate the applications. With this approach, all of the rules are kept in one place and the decision about how to implement them can be made independently.
About the Author
Dr. Paul Dorsey is the founder and president of Dulcian, Inc. an Oracle consulting firm specializing in business rules and web based application development. He is the chief architect of Dulcian’s Business Rules Information Manager (BRIM™) tool. Paul is the co-author of six Oracle Press books on Designer, Database Design, Developer, and JDeveloper, which have been translated into seven languages. He is President of the New York Oracle Users Group and a Contributing Editor of IOUG's SELECT Journal. In 2001, Dr. Dorsey was honored by IOUG as volunteer of the year and by Oracle as one of the six initial honorary Oracle 9i Certified Masters. Paul is also the founder and Chairperson of the ODTUG Business Rules Symposium, now in its fourth year. He can be reached via email at paul_dorsey@dulcian.com.