Applying a Business Rules Approach – When and How Much?

At its heart, a business rules approach involves delivering the rules of the business back to the business itself, not merely burying them in automated systems.  This means separating business rules from process and data as distinct components of business system specifications and managing them as a new kind of business or technical asset.

Separating out and improving management of business rules has been shown to:

•  Improve completeness and remove ambiguity from business and system specifications
•  Increase business-control of and business-visibility to its own policies and business logic
•  Increase business and systems agility by introducing a shorter change cycle for rules than for other aspects of the business or system (such as data or process).

Separating and managing business rules as a new kind of business asset implies organizational change and investment.  To accomplish this, some organizations have adopted rule technology and sophisticated methods along with stewardship programs.  Other organizations decide to be less formal.  With the current increase in organizations pursuing the Business Rules Approach (BR Approach), two important questions surface early:

1. What kinds of projects are most appropriate for a BR Approach?
2. For those projects, which aspects of the BR Approach are most appropriate?

In truth, while all projects can benefit from applying a Business Rules Approach, there are some projects that are not the most ideal candidates because the management of business rules is not a critical success factor.  For example, a formal separation and management of business rules may not be high priority for projects with the following characteristics:

• The task at hand is a maintenance, enhancement situation with little process or system redesign.
• The business policies and rules are well documented in another format.
• Planned improvements are primarily technology and not business related.
• Potential impact of an error in specifications is acceptable.
• Lowering the total cost of ownership not a major driver.
• Project is isolated; functionality does not tightly integrate with other processes/systems.
• Project is small, departmental.
• Changes are infrequent or long lead times are acceptable for responding to a given change.
• The business rules are not complexly inter-related or voluminous.
• Project does not represent a core, mission critical business area.

A formal Business Rules Approach for projects with the characteristics below may not be high priority, but need to be evaluated carefully for the risks of not doing so:

• Business and project team knowledge of the area is high (How do you evaluate this?).
• There is little risk of knowledge loss, e.g. through attrition (How can you be sure of this?).
• Existing system specification methods have been successful and are well established (Where are the rules in these methods?).

On the other hand, projects that have one or more of the following characteristics are ideal candidates for the BR approach:

• Project involves many, complex rules.
• Business policies and business rules are not well documented.
• Many rules are buried in code, unknown to anyone, especially the business.
• Many rules are common to several business areas and applied differently by each, with sometimes serious, possibly legal, consequences.
• Project represents core business functionality that differentiates the company from its competition.
• Project support is heavily dependent on long time knowledge workers that are retiring  or otherwise being lost (outsourcing, off-shoring).
• Task at hand involves business process or system redesign.
• Business behind the project needs to be more agile.

Target areas meeting these criteria have already created fundamental rule management problems that may be current liabilities to the business.

This brings us to the second question.  For those projects, which aspects of the BR approach are most appropriate?  At least two different levels of rigor can be applied in terms of rule specification and analysis.  For minimally complicated rules that are not very dependent on each other, you may only need to carry out a qualitative examination of the rules (written in free-form), checking for precision and clarity, along with careful identification of the standard terms.  (This is consistent with the goals, tasks, and deliverables that are part of Rule Maturity Model Level 1. It is sufficient just to know what the rules are within this project’s boundary).

But, for more complex pockets of rules, you will want to recast the initial business expression into a formal grammar, conduct formal analysis of inter-rule dependencies, and create a formal model of the standard terms to ensure rules are precise, complete, and consistent, and correct. (This represents the need for the goals, tasks, and deliverables that are part of Rule Maturity Model Level 2. It is important not only to know the rules, but to analyze them for integrity, again within this project’s boundary).

For rules that should be consistent beyond the project’s boundary, you will also need more sophistication in cross-project rule stewardship.  (This brings you to Rule Maturity Model Level 3).

In summary, how much of  a Business Rules Approach to apply to a particular project or within an organization is not always a straight-forward decision.  Although some rigor around business rules is applicable in most cases – as is the case with process and data – the same level of formalism of approach may not be called for in all situations..  Because you can apply the Business Rules Approach in a simple, less formal way or in a sophisticated, formal way, organizations should understand the benefits and costs of each approach.  In addition to project specific characteristics, overall organizational maturity needs to be considered.  Organizations just getting started in a BR Approach should recognize where they are starting from and the benefits they can achieve with BR management.  With this knowledge, these organizations can move slowly or aggressively up the Rule Maturity Model, both has applied to individual projects and to the organization as a whole, learning how to reap the greatest ROI from the BR Approach.

The following chart is a preliminary guide.