Introduction

This article discusses state-of-the-art technology with respect to true business rule management for the business.  The Business Rules Group (BRG) was one of the first to distinguish between the rules of the business and the business logic in IT Systems.^[1]  Their goal was to develop an altogether new approach where business rules are not merely artifacts of IT professionals but entities that can be authored, managed, and analyzed by business professionals with little IT background.  This approach catalyzed exciting ideas and developments.  In today's IT space we can find many products and methodologies that must pay credit to the BRG and its groundbreaking work.

Business Rules Management Systems (BRMS) have been on the market for many years, initially conceived as expert systems, then knowledge bases or rule engines, and finally business rules management systems.  The major difference between these systems and traditional development environments is that the concept of 'business rule' is separated from other concerns within a software application such as data processing, user interfacing, and control flow.  This separation has two major advantages:

1. Business rules have their own special syntax, often more easily readable than ordinary software code;
   
   
2. A specifically-designed engine is able to process these rules based on the availability of data thus relieving developers from the complexity of writing the business rules in a specific processing order.

This approach has been, and continues to be, successful in many organizations that have to process great amounts of business rules.

This exciting business rules approach has always appealed to the business and sometimes they (business professionals) could be successfully engaged in (technical) rule based projects, but only if they were logically skilled to some extent.  As a result, in many organizations business professionals have attempted to manage their business vocabulary and business rules in spreadsheets or other Microsoft Office documents but soon found these impossible to maintain.  Some of them had limited success using the repository capabilities provided with a BRMS.  In this article, we will discuss why a BRMS is not the best environment for those who really want to put the business rules in the hands of the business.

Applications of a General Rulebook System

A Business Rule Repository is a special kind of structured data storage.  A General Rulebook System manages a General Business Rule Repository — a repository used to record and manage business rules for as many purposes as possible.

We consider a repository that is used to manage business rules that are technical artifacts a System Rule Repository — not a bad concept in itself.  A Business Rule Management System (BRMS) typically manages such a repository.  The applications of a System Rule Repository include:

• Traceability between business rules and your systems and automated processes; the ability to perform impact analysis when business rules must change.
  
  
• Reusability of business rules throughout systems and automated processes.
  
  
• Homogeneous encoding of business rule statements to improve consistency.

In today's business rule landscape we can find several System Rule Repositories, usually shipped with a BRMS.  Considering business rules to be an IT responsibility is too narrow a perspective and poses considerable risks.  Perceiving business rules as IT system artifacts has the following consequences:

• You ignore all those business rules that get never implemented in software because they are either too complex or too expensive to automate.  Business rules are everywhere:  in people's heads, procedures, policies, contracts, and so on.  They are all valuable assets of your business.
  
  
• Your business rules will be mere system requirements at best.  You will likely introduce concepts and business logic that only make sense in the context of a system with a particular goal.
  
  
• A further consequence of the above consequence is that your rules may be less reusable than you thought.
  
  
• Developers may require a certain syntax or structured language for your business rules.  This will limit your ability to express the business rules.  They will also be harder to validate by experts.

Contrast that with a General Business Rule Repository (which is managed by a General Rulebook System), having these additional applications:

• Publication of business rules to a broader audience such as management, auditors, help desk, citizens, and customers.  It does not take a lot of investigation to learn that there are many parties in an organization that take an interest in carefully-documented, high-quality business rules.  If business rules are only expressed specifically for IT purposes, they will be very hard to adapt by other parties in your organization.
  
  
• Traceability between your business rules and legal requirements and policies — the ability to perform impact analysis when regulations or policies change.
  
  
• A single source to record data about your business rules that are not IT related, such as subject matter expert, motivation, examples, amendments, exceptions, and explanations.  This is an important aspect of knowledge management.  New employees will benefit from such a rich source of knowledge.
  
  
• Compliancy analysis.  Not only do your systems need to be compliant with regulation and policies, but you need to be able to demonstrate that compliance. 

A General Business Rule Repository is therefore much more suitable than a System Rule Repository for business analysts that perceive business rules as something more than mere technical artifacts.  It is a tool for those business professionals that want to manage an enterprise repository with their business vocabulary and rules, independently from IT systems.  Consequently, the business will take responsibility for these business rules, which is much harder to achieve with a System Rule Repository.  An example of a best-of-breed General Business Rule Repository is RuleXpress,^[2] which rose directly from the Business Rules Approach and supports all the requirements discussed below.

Features of a General Rulebook System

A General Rulebook System is a tool for those business professionals that want to manage an enterprise repository with their business vocabulary and rules, independently from IT systems.  Besides the ability to author, analyze, manage, and publish your business rules, it is of the essence that your business rules be based on a solid, complete, and high-quality Business Vocabulary.  A vocabulary consists not only of a glossary of terms but also, as we call it, a Fact Model.  A fact model describes the relationships between the various concepts in your glossary.  These are the pillars of the Business Rules Approach:  Terms, Facts, and Rules.

Concept Management

Concepts are all the 'things' that matter in your business.  Words are used to communicate about these concepts.  It is important that a tool has the notion of concepts because:

• Some concepts are signified by more than one word or phrase — in other words, there are synonyms.  Synonyms are almost unavoidable in day-to-day communication.  People use different words for the same thing and they can still understand each other … or can they?  Start organizing the words that your business uses into concepts and (very) soon learn that people use numerous words for the same thing.  This is probably not an issue when experts discuss their work together, but what if they talk to not-so-experienced members of their organization?
  
  
• As you collect these synonyms, you will soon find the need to express that some words are preferred and others should be avoided in official communication.  Identifying preferred terms for concepts helps you improve the quality of business expressions.
  
  
• This approach will also reveal homonyms — words that have a different meaning in a different context; for example, "application" can be a software system or a form.  These words are really troublemakers in your business communication.  Everybody knows of situations where the communicator and the recipient don't have the same 'picture in their head' for a word.  Some people think that homonyms should be banned, and they may be right, but in practice homonyms are very hard to get rid of.  The best you can do in that case is to record them and acknowledge that they exist.  Once you have them in your control you can make two important improvements:
  
  
  1. Ensure that a homonym used in a business expression is always annotated with a context like this:  "application [system]" and "application [form]".
     
     
  2. You can carefully start negotiations with all parties that use such a word and try to get consensus about the meaning.  Keep in mind that as long as you don't have that consensus, you can anticipate likely confusion!
     
     
• Define the words that you use.  Create your own business dictionary.  We find in practice that particularly the business terms that are also general words in the English language are important to define.  Everybody has a 'picture in his head' when you refer to "customer" but what does your business mean by that word?

Fact Modeling

Fact Modeling deserves an article (or a book!) in its own right.  A glossary of terms is extremely helpful; you can look up words and see their definition.  But how do all these terms relate?  Most relationships can be derived from the definitions of concepts.  For example, if the concept with term customer is defined as "a person that purchases a product" you can derive a categorization relationship between person and customer:  a customer is a person.  There is also a relationship between customer and product:  "customer purchases product."

A Fact Model consists of the following relationships:

1. Categorization (or Taxonomy).  For example:  customer is a category of person; gold customer is a category of customer; and so on.
   
   
2. Properties.  For example:  A person has an address; an address has a street name; and so on.
   
   
3. Classification or Assortment.  For example:  Texas is an instance of State.
   
   
4. Objectification.  For example:  "A person purchases a product" is objectified as 'purchase'.
   
   
5. Roles.  For example:  A person [customer] purchases a product.
   
   
6. Composition.  For example:  An arm consists of a hand; a hand consists of fingers.
   
   
7. And finally, there's the General Association that is none of the above.  For example:  customer purchases product.  These associations may be unary, e.g., a 'relationship' with just one noun concept involved ("product is available"), binary ("product is available at online store") or n-ary ("product is available at online store in North America").

The ability to organize your concepts this way has many advantages, including:

• It will affect the quality of your definitions.  As you design and construct your Fact Model you will review the definitions of the individual concepts, and you will often discover that your definitions need to be revised.
  
  
• A Fact Model is typically represented as a graphical diagram — easy to read, easy to validate.  Some experts prefer validating a graphical diagram, rather than having to read definitions.
  
  
• IT people love models.  A business analyst will impress his/her IT counterparts with this 'more formal' representation of things that they often perceive as 'data elements'.

Figure 1.  Example of a Graphical Fact Model^[3] 

If only you had your business glossary and Fact Model in good shape before you started your business rules project!  Specifying your business rules would have been a relatively easy task.  Why?  Business rules can be envisioned as expressions that tell exactly if and when a relationship in your Fact Model is permitted or required, or indicate what facts can be derived or computed from facts that already exist.

Business Rules Management

To successfully manage the volume and complexity of your business rules with a tool, two general features are critical:

1. The ability to express the rules on your terms.  If you require a business analyst to write business rules in syntax, he or she could as well apply for a programmer position.  Ideally, a business rule is expressed in the language of the business.  To ensure consistency and encourage preciseness, consider using business rule patterns.  A good resource and inspiration for business rule patterns is RuleSpeak.^[4]
   
   
2. The ability to organize and represent your business rules in various ways.  There are many ways to organize business rules including:

• Grouping:  Business rules can be grouped in various ways, process-oriented being just one of them.  They can be grouped by subject, project, release, owner, etc., etc.  Along with grouping comes the ability to nest groups and for a business rule to be part of more than one group.
  
  
• Decision Tables:  A decision table is a special group of rules that share the same goal and that are highly homogeneous with respect to the considerations that help reach that goal.
  
  
• Decisions:  A decision structure is yet another way to structure business rules.  As with rule groups, decisions can be nested, and a business rule can be part of more than one decision's logic.
  
  
• Rule-to-Rule Relationships:  Business rules can be related in many ways meaningful to the business.  A particular business rule may be a simplification of another, more complex business rule; or an exception to another business rule; or a rule that should be invoked upon violation of another rule; and so on.

Analysis

Managing your business rules is one thing, but getting a handle on the complexity that all these statements represent is something else.  Besides, it is hardly possible to organize your business rules in meaningful ways if you don't have the tools to look at that complexity from different angles.  Therefore, a General Rulebook System must support at least the following features:

• Automatically link and maintain the relationship between the business vocabulary and the business rules.  Concepts in your glossary must stand out in your rule statements, and the user must have easy access to the definition of these concepts.
  
  
• No Master-Detail dialogs:  A system that allows you to view detailed information only by moving to a different view will not be helpful (enough).  A business analyst needs to have as much related information in one view as possible, especially when trying to revise some aspect of the information.
  
  
• Dependency Views and Hierarchical Views:  There can be many kinds of relationships between the respective manageable items in a General Rulebook System.  Different views on these relationships are necessary to perform analysis.
  
  
• Navigation through Usage:  The business vocabulary and the business rules are highly interconnected.  Easy navigation from terms to statements (that use them), and vice versa, is invaluable.

Quality Assurance

Organizing and analyzing your business logic in a structured way, with help of a tool, will take your business rule repository to a high level of quality.  But there's an even higher goal to be achieved.  You want to make sure that your business rule statements and concept definitions make sense and are suitable for their target audience.  (There's always a target audience; we are not managing all this stuff for ourselves!)  A business rule in perfect English may still have room for improvement.  Here are just a few examples of quality checks that can be performed automatically:

• Does the business rule follow an approved business rule pattern?  RuleSpeak or another set of guidelines can be really helpful to ensure consistent and clear communication.
  
  
• Does the business rule use preferred or approved terminology?  Concepts that can be expressed by more than one term should carry some indication of which of those terms is preferred in business rules.
  
  
• Is a definition circular?  Definitions of concepts are always written using other terms.  In a large glossary it is very hard to avoid circularity in definitions.  For example, consider the following three definitions:  "an X is a Y that ...," "a Y is a Z that ...," "a Z is an X that ...."  The definition of X indirectly refers to Z, which uses X in its definition.  This makes all three definitions meaningless.

Ownership, Publication, and Adoption

A General Rulebook System must support the notion of both general, reusable concepts and business rules, and domain-specific terminology and business rules.  The general concepts and business rules are typically managed in, and owned by, an enterprise context, managed by a group of business analysts that are responsible for ensuring high quality of those items that are useful to the entire enterprise.  The analysts decide which of these items are available to the domain-specific contexts.  The more specific concepts and business rules are managed in, and owned by, a narrower scope, but they have the enterprise items at their disposal.  These domain contexts must be able to choose which items they want to adopt from the enterprise.  Alternatively, an organization must be able to force a domain context to adopt the enterprise items.

Meta Model Management

Every business is different, even in the same market.  A General Rulebook System must offer powerful metamodel features to allow a business to record and express everything that is needed to be successful in their projects.  This is essential if the General Rulebook System is methodology independent.

References

[1]  Visit the Business Rules Group at BusinessRulesGroup.org

[2]  Visit RuleArts.com

[3]  A Fact Modeling tool (FactXpress) is available for download on RuleArts.com (free).  FactXpress is widely used by business professionals to structure and validate business vocabulary, large or small.

[4]  Visit RuleSpeak.com

# # #