Businesses today are confined by budget and time more than ever, which in turn affects the projects that are approved. IT and business organizations must review each project to ensure that it will provide value to the overall business to attain business objectives. There are also additional external pressures today affecting business projects, such as the increasing rate of business change due to mergers and acquisitions, intense global competition, the opportunity for 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 their business processes and focusing on the business rules needed for good business decisions in a constantly changing environment is a key differentiator.
“A business rules approach to systems development promises to be the most practical and desirable way to build systems. It can help to build better, easily changeable systems faster then any previous approach.” (von Halle, Business Rules Applied, 2002)
KPI’s Business Rule Approach ensures that the organization’s business rules – the key knowledge asset of your organization – are defined, documented and managed through their lifecycle. Our approach operates under four basic STEP™ principles:
- Separate the rules…so the business knows what they are, where to find them, and can apply them consistently
- Trace rules…so the business knows where the rules come from (policies), why they exist (objectives) and where they are utilized (procedures, automation)
- Externalize rules…so the business audience knows what they are and can challenge them
- Position rules for change…so the business can evolve at its own pace
It also outlines the tasks, deliverables and roles necessary to harvest, document and analyze the rules during business requirements gathering. However, to ensure the complete success of implementing a business rules approach, you must address where you will store 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. You need this information organized for your organization’s needs, in a well-structured way that enables flexible access when investigating future rule changes. You need to manage not only the implementation of the business rules, but the business reason for an 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 to defining and ensuring the most important part 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 rule engine). It provides the business with a “single source of truth” of the business rules. As indicated in a related article in this publication (What is the Rule Maturity Model (RMM)™ and How Can It Be Used), the capabilities that are implemented in the organization’s source rule repository determines the levels of the RMM™ that are attainable for that organization. This article focuses on a source rule repository that is needed at Level 2 of the RMM™.
An RMM™ Level 2 source rule repository should provide the capability to capture a wide variety of metadata, including:
High level rule groupings (e.g., KPI’s rule classes) for scoping and assessments
Decisions to link business rules to business processes for reuse and business strategy management
Rule families and rule patterns for rule analysis and rule design
Multiple expressions of the business rules for various audiences, including a natural language expression and a templated expression following a more formal syntax (e.g., KPI’s rule templates), with reusable rule clauses and reusable business rule terms
Correlation of business rule terms to formal models (e.g., object models) for precision
Status information to track the rule lifecycle
Implementation information to provide full traceability
Ideally, the source rule repository at Level 2 should also support graphical capabilities for the entire rule model (such as tracing decisions in processes or use cases to rule families to rule patterns, to rules) with drill down capability.
For starters, this business rule information stored within the source rule repository is utilized as a critical component of system requirements. 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 that they were often not prepared to give, or just decided what the rules were on his/her own. 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.
Following the KPI Business Rule Approach, the rules in structured form have been analyzed to ensure they are consistent and complete for each business decision and that they truly support related business objectives, well before the programmers get started. These analyzed rules can also be easily translated to technical implementation, allowing the programmers to focus on what they do best – coming up with the most efficient way to design and implement the solution – not coming up with the business’s rules. To complete the loop, the source rule repository will need to be updated after design with where the rules are implemented in order to ensure that the full traceability to implementation is maintained.
But, this is only half of the story, 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 because business rules may have a shorter life cycle than the life cycle of a 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 mechanism (the source rule repository) to store the rules and related information gathered during the business rule tasks, but you also need processes defined to manage the rules post-implementation. Remember the last STEP™ principle – Position for Change – the biggest benefits of the business rules approach are realized when you need to change the business rules and are well-positioned to do so by having the information available and good procedures to follow. Rule management is the business function that manages the organization’s rule assets (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 rules!
Rule management with the source rule repository allows for rapid rule changes because the rules can be known and challenged, changes can be known, and those processes or systems impacted can be known, hence predictable. Some of the sample queries that can be “asked of the source rule repository” are:
What are all the rules for a particular business decision?
What are all the rules that affect this piece of information?
What is the definition of this business term?
Where is this rule implemented?
When was this rule last updated?
Who has the authority to change this rule?
What impact will a change have?
If a change to this rule is made, what other rules are affected?
If I change this process, what are all the rules in this business process?
If I need to change the value set of a business term, what rules should I review to see
if they need to be changed?
There is a lot of confusion on the differences between a business rule engine (BRE) repository and a source rule repository. The BRE repository manages the implementation of rules that are defined to their individual BRE, and only rules that will execute in the BRE. You cannot define manual rules or rules that are implemented elsewhere. Most also only manage rules within a given project or application, not enterprise-wide. In addition, you first need to define the technical implementation model (i.e., object model) which is generally completed in the design phase of the system requirements before you can start defining the BRE rules (which is appropriate for designing the implementation of the rules). The source rule repository captures all the business rules and their metadata earlier in the project life cycle and, if desired, from an enterprise perspective. The source rule repository links to the implementation of the rule, wherever that is, but does not manage the implementation itself (i.e. the executable form).
There are only a few options for a source rule repository available today. Some companies have used a simple option of capturing business rules in formatted MS Word or MS Excel documents. But, this is a starter solution, appropriate for pilots or small projects only because there is limited capability in the type of reporting that can be done. Thus, this option is referred to in Level 1 of the RMM™. It is very difficult to maintain discipline in defining rules and it is difficult to make the business rules available in an efficient way to large numbers of people or to do large-scale analysis on rules captured in MS Word or MS Excel.
KPI has worked with companies to customize the KPI Rule Metamodel for specific needs and implement the customized metamodel into modeling or requirements tools. Each tool must be reviewed to see how flexible the existing metamodel is to customize. They are typically not designed for this. The limitation of the underlying metamodel of these tools will directly affect the flexible rule reporting and rule management needed to attain Level 2 of the RMM™.
There is a practical path to the appropriate source rule repository. It starts with the identification of the business reasons and objectives in adopting a Business Rules Approach for your project or enterprise and ends with the implementation or customization of an appropriate source rule repository solution for your organization. Along this path, alignment of the business objectives to the RMM™ is critical as well as an assessment of the current RMM ™level and the targeted RMM ™level.
There are two successful source rule repository solutions that KPI has included as part of our Business Rule Offerings – Extensions to IBM’s RequistePro for Business Rules and KPI’s BR Workbench. Both of these source rule repository solutions are currently being used in companies today to store and manage business rules for project specific implementations as well as enterprise wide rule repositories.
