Organizations today are constantly reviewing IT projects to focus on those projects that will provide value to the success of the business. In addition, there are external pressures affecting business projects, such as the increasing rate of business change due to mergers and acquisitions, intense global competition, the opportunity and challenges of offshore systems development, and strict regulatory requirements such as the Sarbanes-Oxley Act, the USA PATRIOT Act and HIPAA. These increasing business pressures have led to the growing adoption of a business rules approach across industries. Organizations are realizing that streamlining business processes and focusing on the business rules needed for good business decisions in a constantly changing environment is a key differentiator.
But, when adopting a business rules approach, an organization needs to address the management of the business rules to support the business perspective and related information, such as the stakeholders for the rules and the processes in which the rules execute. This information, managed in a well-structured way, enables flexible access when investigating future rule changes. The need to manage not only the implementation of the business rules, but the business reason for and understanding of the rules that serve as the source for implementation. Hence, the need for a Source Rule Repository.
The source rule repository is a critical component for defining and ensuring the most important ingredient of business requirements. The source rule repository “houses” the business rules and their descriptive information as they are harvested, starting with scoping, and tracing to where the rules are implemented (e.g., in a manual process or in procedural code or in a business rules engine). It provides the business with a “single source of truth” about the business rules.
It is common today for business rules engines (BRE) to refer to their software environments as business rule management systems or rule repositories. This is correct today when speaking of a BRE repository that manages the implementation of rules that are to execute in the BRE, but less useful for managing rules that will not execute in the BRE. That is, it is usually not optimal for manual rules or rules that are not implemented in the BRE to be defined and managed in the BRE repository. In addition, the technical implementation model (i.e., object model) which is generally completed in the design phase of the system requirements needs to be completed before you can start defining rules to the BRE.
In contrast, a source rule repository captures all important business rules and their metadata earlier in the project life cycle. The source rule repository provides traceability to the implementation of the rule, wherever that is, but does not manage the implementation itself (i.e. the executable form).
Too often in the past, the details of business rules were not uncovered until the development phase, because there were no disciplined methods for capturing and analyzing them during requirements gathering. However, this often led to situations in which a programmer, under pressure to get the code done, either went back to the business with a need for a quick answer, or the programmer decided what the rules ought to be. This has led to unfortunate but common situations where the program code is running the business, even if no one knows what it is doing.
Business rules, while it is easy to think of them as a kind of business requirement, are a very special kind of business requirement. That is because some business rules may have a shorter life cycle than the life cycle of system maintenance. So, business rules are living requirements that may need to change in between planned maintenance for a target system. This brings us to the concept of rule management.
In order to fully realize the benefits of adopting a business rules approach, you must have a source rule repository for storing the rules and related information gathered during the business rule tasks, but you also need processes for managing the rules post-implementation. The greatest benefits of the business rules approach are realized when the business needs to change the business rules and this change is facilitated by the availability of relevant information and good procedures for accelerating changes.
Rule management is best described as the business function that manages the organization’s ruleassets (as stored in the source rule repository). Communication between business and IT professionals is enhanced by proper rule management and by putting the business people in control of the requirements that are their rules!
Rule management is the key to allowing the business to rule the code and not the code to rule the business.
