The Business Rules Approach to Systems Development
Dr. Paul Dorsey
Dulcian, Inc.
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 the 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 these 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 way of describing how good systems analysis has always been done. The business rules approach is not something new, it is simply a better, 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 list 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 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 alone 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:
1. Analysis (high-level) rules are stated in a way that is very close to the way in which users think and talk.
2. 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. BRIM™ uses data models and process flows to store the implementation rules.
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). Other 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 read about in the BRIM™ System Development Life Cycle document.
A Complete Business-Rules Based Solution
BRIMä is the only product available that supports a complete business rule-based design and development environment. The existing products and approaches currently available only deal with a portion of the system design process. Most products assume an existing relational database and data structures. All of the existing process flow-based products use this model. Other products either generate database triggers or application code to support business rules that traditional relational databases do not handle well.
Past attempts to place business rules in places where they can be manipulated by users so that neither the data structures nor applications need to be modified include reference tables and generic data modeling. Rather than having the business rules be completely inaccessible in code or data structures, they are placed in some type of user-maintained repository. Because none of these approaches allow all of the rules to be placed in one repository, fragmentation of the business rule storage throughout the system is inevitable.
BRIM’s solution is to provide a single, consistent, integrated repository for all of a system’s business rules.
Why Use the BRIMä Approach?
Traditionally, most systems are designed using the communication process shown in Figure 1. 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 1: Traditional System Design Process
This approach can break down in many places including:
· Translating the business rules from the users’ heads to the analysis document
· Interpreting the analysis document into system design specifications
· Implementing the system design specifications
· 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 BRIMä environment is shown in Figure 2.
Figure 2: BRIMä System Development Process
In this environment, users and IT professionals work together to specify the rules and place them into the BRIMä repository. This repository acts as a common point of communication for both users and IT professionals. The advantages of developing systems in a BRIMä 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.
· The BRIMä generators can immediately generate a working version of the system.
A key difference between the traditional communication process and the BRIMä communication process is that the information in the repository can be understood and used by users, IT professionals and the BRIMä 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.
Managing Business Rules
In any ERP-type system, there are many business rules. For high-level analysis rules, an ERP is likely to have anywhere from a few thousand to tens of thousands of rules. For implementation rules, the numbers can be in the hundreds of thousands or even a million or more for large systems. Managing this many objects is very difficult. Some type of reductionist thinking and some assumptions must be made before it is even possible to gather all of the rules necessary for building a system in a responsible time frame.
Gathering a million rules at a minute per rule would require 8 person-years to collect. A million sentences are also unmanageable for anyone to read and organize. There must be an effective mechanism for managing implementation rules.
Sorting rules in an Oracle environment can be done using a function hierarchy and logical data models. The object-oriented approach employs use cases to manage the rules. Other approaches generate various types of analysis documents. As an industry, there has not been a mechanism for supporting implementation-level rules. This is the problem that BRIMä has solved.
First, rules are partitioned into structural and process rules:
· Structural rules are process independent things of interest. How they relate to each other can be represented in a data model.
· Process rules consist of the steps required to execute an organization’s business events. These rules can be represented as a process flow.
BRIMä uses the Unified Modeling Language (UML) as its business rules grammar. The UML is the industry standard for building object-oriented systems. Originally a merging of the different approaches by Booch, Rumbaugh and Jacobsen, UML has evolved into a rich, easily extendable framework for designing systems. (Dulcian’s use of UML is discussed in the BRIMä Architecture document.)
BRIMä has taken the basic UML structures and extended them so that all of an organization’s rules can be placed into these two types of diagrams, making them easy to specify, manageable and compact.
Implementation of the rules
As mentioned above, the implementation rules are stored in the BRIMä repository as data models and process flows.
The actual implementation of these rules consists of Oracle tables, views and procedures that the BRIMä generator builds. The BRIMä repository stores the detailed representations of business rules, not their implementation. Implementation is defined by the algorithms built into the BRIMä generators. These algorithms can be changed at any time. For more details see the System Generator document.
Using this approach, the rule specification has been abstracted away from the system design process, allowing it to focus exclusively on the business rules. Only when the process of completely specifying the rules, generating the system and testing/validating the rules is complete should any custom development take place. (See the BRIMä Software Development Life Cycle document for more details.)