Ó EBG Consulting, 1999

Abstract of the Article

Explicit business rules are often documented and known. Implicit rules, which are also used in the operation of the business, are more flexible and ‘soft’, like heuristics and guidelines. Business rules, whether explicitly known or not, are the basis for an organization’s knowledge. This knowledge is used as input to decision making. It tells us WHY we act.

Business organizations are beginning to become aware of the power of explicitly capturing, cataloguing, retrieving, sharing and testing their business rules. Rather than focusing on the business process – tasks, flows, functions -- or even business data or objects -- the primary focus has shifted to the reasoning aspect of the business: motivation, justification, reasons, a guidance system for its underlying behavior: the WHY.

This paper summarizes the use of business rules in theory and practice and how facilitated workshops may be used for the iterative and incremental discovery of business rules - the hidden strategic knowledge of the organization.

What are Business Rules?

Commercial enterprises are comprised of thousands of combinations of such rules, which work at an operational level running the business. Business rules define and control the lifecycle of products and services and the supporting infrastructure. Business rules are from many sources: corporate policy, industry policies or rules-of-thumb, generally accepted practices, experience, and heuristics, and physical laws. These rules direct how enterprises buy, create, sell, cultivate, conform, employ, manufacture, research, report, and plan. As such, they are the core of the enterprise. Many businesses have awakened to the fact that its’ business rules are often unknown, used inconsistently with other rules, are applied in non-standard ways, are difficult to measure, and archaic.

Business rules have emerged in both the business and Information Technology (IT) community as a promising approach to discovering, refining and designing both business and technical requirements. A business rule approach has dual value: as a business methodology and as a software engineering methodology. In the latter case, a business rule approach is needed to enable business rule automation through a ‘rules engines’. From the business perspective, business rules are the foundation of business knowledge and are therefore tightly linked with the "knowledge management" movement.

Rules at the Core

A business rule is independent of a methodology, modeling paradigm or technology. A rule is defined and owned by business people. To summarize, business rules are:

• Declarative (i.e. non-procedural)
• Atomic (indivisible yet inclusive)
• Expressed in natural language
• Distinct, independent constructs
• Business, not technology, oriented
• Business, not technology, owned

The Business Case for Business Rules: An Example

To maintain and enforce those business rules, business rules stewardship would be established. Therefore, the first step was to define the business rules – terms and connections among them (also referred to as terms and facts) -- for all data requirements dealing with materials and products. Next, a stewardship organization was put in place.

To define the rules in a standard manner, a series of intense facilitated workshops involving a cross-functional team of business experts representing the different aspects of the material and product value chain were held. This required a large breadth of business knowledge, which no single person possessed. Thus, the cross-functional workshop team was critical to defining the business rules.

A decision-making framework was established to make the business case. It was based on a combination of solid business insight based upon devising scenarios (stories) for the improved state of the business, a visual map of benefits and costs called an influence diagram, and the ROI (Return on Investment) approach called Economic Value Added.

Economic Value Added, or EVA, is an approach to ROI which evaluates an investment opportunity by calculating the ROI in terms of all the economic components of the business enterprise, capital expenditures, human resources, plant and equipment as well as other financial aspects. (This is derived by starting with a cash-adjusted operating profit and subtracting the cost of the capital needed to produce the earnings). For this, a $165 mm EVA over 15 years (a positive EVA) was derived. This was then validated via risk analysis and reviews by the project Steering Committee, a cross-functional group of business and IT senior managers. This company now understands the costs, benefits and risks of business rules standardization and has made a decision to implement the business rules standardization effort.

Linkage to Enterprise Architecture

Business rule are analogous to the ‘Why" column of the Zachman framework, providing the motivation, ends and means, goals and strategies for each perspective of the framework. In a business rule project, the Zachman Framework is useful to categorize project deliverables. Deliverables from a business rule project can be depicted in terms of this Framework.

Business Rule Methodology

KPI and EBG focused ERAD on the following ideas as foundation:

• The entire methodology is independent not only of automation platform but of preferred modeling bias (data versus objects/components)
• The emphasis is on collecting business rules as a better way of capturing requirements and of providing traceability of the business rule as a fundamental piece of automatable business logic
• The approach lends itself to being customized to client culture and objectives, without losing the rigor needed to manage rules as a new asset
• The approach aims to extend current practices and deliverables familiar to the client and to include the new missing pieces; it does not aim to introduce major cultural change to the client’s environment

• Objective analysis
• Decision analysis
• Use case analysis
• Sentence analysis
• Workflow analysis
• Process analysis
• Data analysis

Business Rule MetaModel

The ERAD methodology uses a model of a model, or metamodel, as the basis for assisting business to define what is important to capture and validate about its business rules. Some elements of the metamodel include: source of the rule, owner, jurisdiction (e.g. local, corporate), source documentation, actors in the business who use the business rule, volatility, priority and more. All business rule-related deliverables are validated against the requirements set forth in a business rule metamodel which have been customized to client objectives.

Need for Precision

For example, a business person might state: "the total number of regulated products sold in a country must not exceed the threshold defined by the regulatory limits of the country of origin". This statement is more like a ‘business rambling’. This ‘business rambling’ statement contains many discrete business rules. There are implied definitions (‘regulated product’, ‘country’,); derivations (‘total number of..’; ‘threshold’, ‘regulatory limit’); facts (‘products sold in a country’; ‘limits defined by country of origin’); and constraints (‘total’ not exceeding ‘threshold’).

Business rules must be defined and cataloged in a standard manner to form the basis of truth. This begins with defining terms of importance and using a standard format for writing business rules. Several templates are available to accomplish this. The key is to pick one, and use it consistently in business rule discovery and validation.

Facilitating Business Rule Workshops

• Project vision
• List of impact organizations
• List of stakeholders
• Decision on sponsor
• Decision on sponsorship organization
• Business case
• Business subject matter expert roles
• Project Decision Rule process

• Goals
• Objectives
• Scope:
• Functional
• Financial
• Temporal
• Organizational
• Business Rules
• Related projects
• Staffing with roles and responsibilities
• High-level project plan
• Knowledge management, knowledge transfer, training requirements
• Project organization
• Project metrics
• Risk management plan
• Business Rule metrics
• Project control (change control and management, communications)
• Project plan

• Object-oriented models
• Data oriented models
• Component oriented models
• Event oriented models

Business Rule Workshop Guidelines

These guidelines are derived from experience. Detailed explanation of each guideline is available from the author:

1. Orient participants early and continually.

2. Nail down definition early.

3. Bring rules to life.

4. Have your tools at hand.

5. Iterate the group process.

6. "From Tribulation Comes Knowledge"

7. Be prepared to battle with scope.

8. Make participates speak using the meaning behind the language of the business.

9. Conduct rule-writing tutorials.

10. "Why are we doing this, again please?"

11. Get the right participants.

12. Use solid facilitation process skills.

Conclusion on Using a Facilitated Workshop Approach

Enabling Better Questions with Business Rules

References

1. Business Rule conferences: Technology Transfer Institute, http://www.tticom.com/ and Database Summit conference: www.dbsummit.com/.
2. Crawford, Anthony, Advancing Business Concepts in a JAD Workshop Setting: Business Reengineering and Process Redesign, Yourdon Press, 1994.
3. Data to Knowledge Newsletter, http://www.brsolutions.com/newsletter.html
4. Gottesdiener, Ellen, "Business RULES (Show Power, Promise)", Application Development Trends, March, 1997, vol. 4, no. 3.
5. Gottesdiener, Ellen, "Facilitated Business Rule Workshops: 12 Guidelines for Success", Database Newsletter, Jan/Feb, 1997, vol. 25, no. 1.
6. Gottesdiener, Ellen and Bruce, Jim, "The Value of Standardization of Business Rules", Object Magazine, March. 1998, 8 (1).
7. Gottesdiener, Ellen and Barnes, Michael, "Best Policy: Consistency", Information Week, Information Week, December 22, 1997, Issue 662.
8. Gottesdiener, Ellen, and von Halle, Barbara, "Breaking the Rules On Purpose: (An Introduction to the ‘whys and hows’ of facilitated rule breaking)", Database Programming & Design, September, 1996, pp.9-12, vol. 9. No. 9
9. Guide Business Rules Project, Final Report, 11/95. Go to: http://www.guide.org/ap/apbrules.
10. Hurwitz, Judith, "When Rules Meet Development", DBMS Magazine, January, 1997.
11. Kara, Dan "Rules-based tools: business rule specification is job 1", Application Development Trends, November. 1996.
12. Moriarty, Terry, "The Next Paradigm", Database Programming & Design, February, 1993.
13. Odell, James, "Business Rules", Object Magazine, republished in Wisdom of the Gurus: A Vision for Object Technology, Charles Bowman, ed., Sigs, 1996.
14. Ross, Ronald, The Business Rule Book: Classifying, Defining and Modeling Rules, Database Research Group, Boston, MA, 2^nd edition, 1997.
15. Seybold, Patricia, "Start Your Business Rules Engine", Computerworld, December 9, 1996.
16. Sobieski, J, Krovvidy, S, McClintock, C., and Thorpe, M. "KARMA: Managing Business rules from Specification to Implementation", paper presented at American Association of Artificial Intelligence Conference, Innovative Applications of AI track, Portland, Or, 7/96.
17. von Halle, Barbara, "Data Architect" column covering business rules, Database Programming & Design, Miller Freeman, http://www.dbpd.com
18. Wright, David, "Business Rules", Data Management Review, December, 1996, http://www.dmreview.com
19. Zachman, John, "A Framework for Information Systems Architecture," IBM Systems Journal, vol. 26, no. 3, 1987. IBM Publication G321-5298.
20. Zachman, John, "Getting Beyond the "Legacy" ", Database Programming & Design, January 1998.

The Presenter