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 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 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 is 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, 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.
At Dulcian, we have looked carefully at 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). For example, 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 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?
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 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 the BRIMä
or a Similar 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.
·
The BRIMä 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 such as those included in BRIM™
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.