Business rules represent an important organizational knowledge asset. But this does not imply that it is appropriate for an organization to harness and manage all of its business rules in a formal way. Rather, an organization should identify the important business processes for which agile rules will make a difference in business success, compliance, or competitive differentiation.
There is a quiet revolution underway. It involves a shift toward a business rules (BR) approach for understanding decision-rich or rule-rich business processes and implementing corresponding automated systems. This quiet revolution reflects a pent-up need for business people to play a more prominent role in stewarding business rules from their inception potentially to automation.
A BR approach can help you build better, easily changeable systems faster than any previous approach. Real-world experience proves not only that business rule projects are completed faster, at less cost, and with less risk, but they continue to deliver substantial savings in time and money because rule maintenance is significantly accelerated.
What are Business Rules?
A business rules approach involves a formal way of managing and automating an organization’s business rules so that the business behaves and evolves as its leaders intend.
Loosely speaking, business rules are the collection of your organization’s business policies, constraints, computations, and reasoning capability. Your organization runs by these rules whether or not it automates them, puts them in a business rules engine ( BRE ), or explicitly states them somewhere so that people actually know what they are.
In reality, not every business rule is worth explicitly stating or even automating. And, while business rule engines are extremely valuable, not all business rules belong in one. To be faithful to a BR approach, it is important to assess the value of specific business rules to the business, how often they change, how quickly the change is needed, and how much the business people need or want to control the business rule changes, from start to finish.
Business rules represent important organizational knowledge assets. Organizations should identify the important business processes for which agile rules can make a difference.
The following are examples of business rules or business policies as a business person might initially express them:
- A premium customer is every customer whose credit rating is A or B.
- If a premium customer requests a loan for greater than $500,000, we allow for a delay in the first payment date by 30 days
- The formula to compute students’ cumulative grade point average is on page 6 of the student policy manual.
- If a loan applicant’s outside credit rating is marginal and the applicant also has a credit card balance greater than $5000, then we consider the applicant to have a high probability of default on a loan.
- An employee who has completed five years of full-time employment with the company is entitled to four weeks of paid vacation.
- Stock options vest one-third each year over three years.
- A customer with outstanding payment due must pay in full prior to a new order being shipped.
- A preferred customer automatically receives free express shipping on all orders.
Why is a Business Rules Approach Important Now?
Despite advances in software engineering, the rules of most businesses remain lost, unknown, and inconsistent. They are a hidden liability to the business itself. Today, organizations are liberating and leveraging the most important business rules by following a BR approach.
The BR approach aims to enable business people to confirm that the right rules are guiding the business in all of the right places. This occurs by identifying rule-rich business processes and understanding the importance of the rules that are to guide those processes. Redefining the relationship between business and technical roles is also important. This means defining a business rule change cycle that safely shifts more business rule responsibility to the business itself, as appropriate.
The Roots of the Approach
The BR approach provides the opportunity to manage the most important rules of the business, no matter what kind they are, or what kind of technology they belong in.
The business rule industry today has its roots in two different and previously unconnected heritages. On the one hand, some concepts and techniques arise from data professionals and their discipline for data architecture and database design, which deal with a structured approach for discovering, analyzing, and modeling a set of requirements in a standardized manner and targeted at specific database technology. As the discipline behind data architecture and database design matured, data analysts and designers began not only to create stable data structures, but to incorporate simple data constraints into logical data models and subsequent database implementations. These simple constraints include limits on data values for certain fields, cardinality limitations across database tables, and referential integrity constraints across database tables that determine corrective action for inserts, updates, and deletes.
However, data professionals have long recognized that there are many more constraints relating to databases than those, including limits on data values for certain fields based on conditions of other fields, and more complex constraints based on conditions of fields that span database tables. An example is a constraint that limits the value of a customer’s total order dollar amount based on the total amount still due by that customer on past orders. These more complex constraints are one of the kinds of business rules that today are included in the BR approach. Most of these constraints are the kinds of rules that typically guide business transactions in processing input, applying logic to the input, and eventually updating a database with persistent information about a successful or unsuccessful transaction. For example, the business transaction of placing an order over the Internet is likely to be guided by constraints on product availability, shipping location, inventory availability, and perhaps the buyer’s credit information. People with data architecture backgrounds perceive these constraints as limitations placed on data stored in a database upon attempting to insert into the database the new order and all of its related information.
The data-oriented perspective of the BR Approach is evident in the availability of commercially available data-change-oriented rules engines (sometimes referred to as event-driven business rules engines) and the prevalence of many data professionals now working as BR practitioners, speakers, and authors.
On the other hand, the BR approach has even older roots in the field of artificial intelligence and knowledge engineering. Though these phrases conjure up unpleasant memories for some, it’s important to acknowledge the valuable contributions to today’s BR approach. The field of artificial intelligence attempts not only to understand how humans think, but also to build intelligent entities. With this purpose, the vast expertise emanating from the field of artificial intelligence helps us understand and automate certain human problem- solving approaches, knowledge acquisition, reasoning, knowledge representation, and the role of uncertainty in making decisions. Knowledge engineers began gathering and automating inference rules as a mechanism for simulating certain kinds of human thinking processes. And there is a lot of history here to carry into today’s BR approach.
The discipline of artificial intelligence and knowledge engineering actually has its original roots in early philosophy. The field includes the basics of reasoning, first-order logic, probabilistic reasoning, and the making of complex decisions. Today, inference rules are another kind of rule that is part of the BR approach, whether they are simple and disconnected inferences, or complex inferences related through long inference chains. Not only are inference rules of interest to the BR approach today, but the aspects behind a decision-making capability provide approaches and techniques for harvesting complex rule chains, understanding them in a process context, and automating them in guiding intelligently-intensive business processes. An example of such a business process is that of determining the qualifications of a loan applicant. This may involve computation rules, constraint rules about data in databases, complex inference rules that may not relate directly to persistent data in a database, and other advanced knowledge engineering techniques.
The artificial intelligence and knowledge engineering roots of today’s BR approach are evident in commercially available inference engines. This heritage is also evident by the number of excellent BR white papers available on these vendors’ Web pages and by the prevalence of knowledge engineers working today as business rule practitioners and speakers.
It is important to understand these two heritages of the BR approach because they explain the wide diversity in types of business rules, types of business rules engines, and types of professionals that support and drive the BR approach. At times, these two heritages can seem disparate. In fact, the technical BR center of excellence in some organizations is comprised mostly of data-oriented professionals, working as business rule analysts while the technical BR center of excellence in other organizations is comprised mostly of knowledge engineering professionals. The constituency of these centers of excellence depends on the types of business rules the organization is managing in a formal way and the kinds of techniques and software that assist in doing so for those kinds of rules and related business processes.
The BR approach today needs yet another perspective. With the growing importance of business process management (BPM), it now becomes critical that business process professionals not only become knowledgeable in the BR approach, but also contribute to it the relevant business process pieces and interfaces. The BR approach will continue to mature and will do so successfully as a true integration of multiple disciplines. The breadth of the BR approach is an opportunity to manage the most important rules of the business, no matter what kind they are or what kind of technology they belong in, if any.
So, while the BR approach has wide applicability, it always begins with the business itself. Business rules are really about business concepts and business directions, not about databases or engines. In fact, business rules existed long before we had databases or electronic files.
Stay focused on the business and on the business people who may become business rule authors. Don’t become consumed too early by arguing over different types of business rules, having emotionally charged debates over how best to express each type, and whether to deploy a business rules engine and of what kind. Instead, start by understanding your business’s objectives and letting those objectives drive your BR approach. In particular, identify those objectives that are enabled by better management of underlying business rules, regardless of what kinds of rules they turn out to be, what kind of rule authoring techniques will work best, and what kinds of technology evaluations might be relevant. By first understanding the business benefits of managing specific rules (and the business processes that rely on them), the details of the BR approach that best fits your organization’s needs will become apparent. This is precisely the role of the Knowledge Partner Inc.’s Rule Maturity Model (KPI RMM ™).
What is the Rule Maturity Model?
Simply put, the KPI RMM is a tool for setting realistic BR expectations and designing a practical roadmap for getting there. The KPI RMM maximizes chances of success in five ways. First, it assists in correlating each level of the model to the business benefits most likely to be achieved by organizations aiming for managing business rules at that level. Second, it starts with business objectives and correlates these to matching business rule benefits, methodology pieces, organizational roles, and technology. Third, it provides insights into how to achieve early successes at low risk, keeping expectations realistic. Fourth, consulting with the KPI RMM allows an organization to keep a longer-term vision of strategic business objectives in sight. Fifth, current and future industry-wide surveys will continue to provide practitioners with hints, tips, and lessons learned–that is, best practices–as organizations move up in the KPI RMM.
The KPI RMM can be applied to any organization or project of any size, complexity, and maturity and is simple to use. The basic KPI RMM structure is shown in the sidebar. It provides guidance in three vectors for each level: the business value of the rules, the technical state of automated rules, and the business’s involvement in controlling the rules from inception to automation.
The Levels of the KPI RMM
Like other maturity models, the KPI RMM has 6 levels, starting from 0 and leading to 5. At level 0, people are unaware that business rules have a value worth contemplating. At level 5, organizations are utilizing business rules as proactive and predictive levers for change and compliance, while gaining momentum over their competition. Each level represents an organizational goal with respect to business objectives and business rule management, supported by corresponding roles, techniques, and software requirements. Each level represents a major change in an organization’s culture and its ability to reach for higher goals. Skipping levels ought not to be taken lightly.
Organizations at Level 3, 4, and 5 exhibit progressively mature characteristics, particularly relative to the sharing of business rules across the enterprise. However, there is nothing inherently good or bad about any particular KPI RMM level. The primary purpose of the KPI RMM is to guide an organization from its business objectives, business benefits, and estimated tangible ROI to the KPI RMM level at which the organization is likely to achieve them.
From here, the purpose of the KPI RMM is to provide details on adopting methodologies, appropriate organizational roles, and software aligned with that level of the KPI RMM because those are the pieces that will be necessary to get there. To aim too low is to put the ROI in jeopardy. To aim too high is equally dangerous. To pick an initial target level, aim for it, and get there is the safest journey. Then, evaluating the success and re-evaluating the business objectives to determine where the organization can and should go from the first target state is the most strategic journey.
The KPI RMM, because it is based on many real-world experiences across many industries and for many business objectives, provides the vision for adopting a BR approach one realistic step at a time.
An organization at Level 0
- No special attention is given to business rules.
- No rule repository for business people is in place.
- No BRE is utilized.
- Business rules are buried everywhere in various forms and sources, such as peoples’ minds, documents, code.
An organization at Level 1
- Business rules are documented on a project-by-project basis in spreadsheets, requirements tools, or simple databases consisting of free-form rule statements indexed by various kinds of metadata.
- Business people know where to find the documented rules and are, therefore, able to find out where those rules are executing in the business processes and systems.
- A BRE product is used on a pilot or first project.
An organization at Level 2
- Business rules are managed in a rule repository used by business and technical people.
- A process, starting with authoring or changing rules, testing them, simulating business processes, and automating the rules is defined formally.
- Structured methods, parsed rule syntax, and manual analysis of rule groups (for correctness, completeness, etc.) are possible.
- Rule-related roles are defined.
- Project-level rule stewardship exists.
- There are possibly multiple BREs in place.
