Article is authored by Peter Warde. (peterwarde@rulearchitect.com)

Overview

One of the main challenges for a team delivering IBM Operational Decision Manager solutions is rule authoring. If the rules are not authored by business users they remain part of the standard delivery model and are specified as requirements and passed to developers. Deliveries become focused on rulesets with a business vocabulary close to technical decision inputs and outputs in Rule Designer and rule authoring in Decision Center is an add-on to be done after delivery.
One consequence of not focusing on rule authoring as a deliverable from the outset is that it becomes a challenge. During analysis and development insufficient attention is given to the business vocabulary and its implementation in ODM. The rules are often written in IT and not business speak. They are developed by developers, not authored by authors. As a result of this when rule authoring is attempted in Decision Center by non-technical users it is neither easy nor intuitive. Often rules remain in the hands of developers and do not pass into business ownership.
This reduces the value that can be obtained using ODM, where business and IT can have a common business vocabulary and work together on rule authoring in the most appropriate way for their business.
This article provides tips and techniques to allow you to overcome these challenges and establish rule authoring and business vocabulary at the centre of your ODM delivery from the outset.

The Context

It is in the context of a simplified Lending scenario that this article will discuss ODM with the intention of uncovering the issues and possible solutions for rule authoring. Other business scenarios will be different and the choices and decisions made along the way may also be different, but this scenario is intended to get you started thinking along the right lines. The principles and steps applied here can be applied to other domains.
A customer applies for a loan or overdraft to a lender.
Figure 1 Lending Use Case

The loan or overdraft is processed by the lender according to the following criteria:

• Annual income of the customer
• Whether the customer has outstanding debts
• The amount of the loan applied for
• The limit on the overdraft
• Whether the customer can provide assets as security for a loan

A loan or an overdraft are characterized as a lending product. For example a loan can be a short-term loan, a personal loan or a mortgage. An overdraft can be a fixed-rate overdraft. A customer who applies for a lending product is classified as a borrower. The lending products available to a borrower depend on a combination of factors such as amount applied for and the reason given by the borrower taking out the loan or overdraft. In some circumstances the borrower can make a single application for a borrowing need consisting of a mixture of products.
For each loan and overdraft the lender applies for an appropriate set of conditions are applied to evaluate whether the application should be approved or rejected. The lender also applies additional conditions to the overall mix of loans and overdrafts applied for by the borrower. For example if certain types of loans are applied for together with an overdraft then the customer request must be rejected.
This Lending scenario is to be developed by an ODM team. In an ideal world there would be a single unified team, but in real world scenarios it is common to have highly segregated divisions such as Technology, Change and Business, with well-defined responsibilities.
Figure 2 – ODM roles across the division

Approach to ODM Rule Authoring

For rule authoring to be successful from the outset both the vision for ODM based decisions, rules and the ODM operating model must be in place to avoid the projects going off-course, and tasks and activities falling between 2 stools and getting lost.
The vision must formally define what success will look like and have agreement from all stakeholders. It should embody a model of engagement between Technology, Change and the Business in which business rules and decisions are owned, managed, tested and authored by business users using ODM tools.
It should be established from the outset where there is an agreement that Business users have a key role to play in rule management that:

• Rule architects and developers from Technology will provide and own the ODM platform, including the design and build of the rule authoring capability which provisions the authoring, testing and management of rules for non-technical users
• Business rule authors, analysts and testers from Change will carry out rule authoring, testing and management of rules supported by and using the means provisioned IT. This can be where business only makes small changes to certain parts of the rules or business owns the changed rules.
• Business policy managers are the ultimate owners of rules. They approve the business vocabulary and validate the correctness of authored rules and decisions.

Engage the Change and Technology together in a new model of engagement in which change will take the lead in owning and managing their own logic and IT will provide the infrastructure for rule authoring and support. Ensure the continuous involvement of business users and sponsors.
This use of ODM is not particularly new as it is defined in the ODM documentation (see ODM documentation Roles and activities ), but failure to put it into practice from the outset is one of the main causes of rule authoring failure.
Figure 3 – Rule Designer and Decision Center

Phasing the Approach

The approach to establishing rule authoring should be a phased approach based on tasks performed in an iterative and incremental manner.
Agile Business Rules Development (ABRD) is a proven business rules methodology that provides an overall template for business rules development. It defines an iterative life-cycle development based on two requirement phases (rule discovery and analysis), a single design and development phase, and two subsequent phases for authoring and validation. At the end the rules are deployed.
Within the ABRD template we can define and elaborate the specific tasks and activities that are needed to establish rule authoring and business vocabulary from the outset.
Figure 4 – ODM Role mappings

Define the Structured Business Vocabulary

The Lending project will begin with the Rule Discovery phase which identifies business decisions and decomposes them into policies and rules. Rules are usually articulated in the early stages by policy managers and SMEs as perceptions of what a rule or a policy might be. It is the role of business analysts to formally capture and gather these raw rules together and improve and formalize them using a defined business vocabulary before they can be authored in ODM.
Figure 5 – Rule improvement stages

One of the most successful techniques for doing this is Fact Modelling as advocated by business rules experts and articles such as IBM Developer Works: Term-Fact Modelling, the Key to Successful Rule Based Systems .
Fact modelling defines the business terms and their relationships as graphical model from the viewpoint of business people. It avoids IT speak and adopts business speak to build a structured business vocabulary as defined in SBVR . Using a structured business vocabulary a raw rule can be converted to a formal rule expressed in the language of the business and will all ambiguity removed.
Figure 6 – Fact Lending Model

The Fact Model is the foundation for the business vocabulary. Business terms, together with the facts about them, support the creation of business phrases such the borrower applies for a loan or the loan is secured by an asset. These business phrases are the building blocks of rules. For example the two previous phrases allow the construction of the following rule:
If
the borrower applies for a loan less than 180k
and the loan is secured by an asset greater than 250k
then …..
This rule can be checked for completeness and validated by a knowledgeable business person as being business correct.
At this stage it is a good idea to produce a more formal diagram with additional details such as the number of times a fact can be applied to a business term, the primary and secondary business nouns (using an underscore) which are the principal business things that rules are about.
Figure 7 Lending Fact Model

Further elaboration of the fact model is needed to produce the full structured business vocabulary of business terms, their characteristics and the facts about them. This is done using a document.
Figure 8 Lending Business Vocabulary

Map Vocabulary to Datasources

Whilst the fact model and structured business vocabulary ensures that rules can be defined by rule analysts, the data over which the rules will reason is often more complex.
Data models are designed for data persistence. Entities have relationships based on keys, not facts. They do not easily represent the fact model category of relationship. They are designed for data integrity and the efficient persistence and retrieval of data. Rule and data analysts have the task of making sense of and reconciling the two worlds of data and facts, and mapping them together.
For each business term and fact in the vocabulary the analysts must ask themselves the following questions:

• What is the data source for the business term?
• What is the data type of the business term? What are its valid values?
• Is the business term reference data? Is it flat or hierarchical? Does it consist of very long lists of codes?
• Is the data for the business term optional or mandatory?
• What data needed by business terms does not exist? Can it be inferred, or derived, by other data and rules?
• How do business facts map to data source relationships?

In the Lending business scenario the data source is represented by the following entity relationship diagram (ERD) of tables, attributes and relationships:
Figure 9 – Lending ERD Model

In the above diagram at a structural level:

• A borrower is defined as a Party entity differentiated by the Party Role key.
• A loan and an overdraft is a Product entity and differentiated by the Product Type key.
• Application is a table with a many-to-many relationship with Party and Product, but in the fact model is the business facts borrower applies for and product is applied for by.

With respect to data types:

• Product and Reason types are reference data organized in a hierarchy of categories.
• Application Status and Currency are flat reference data structures.
• Field APR_Percent is percentage type and is optional.
• Field Amount is a money type whose currency is defined by the filed Currency

Design and Build the BOM

The design and build of the business vocabulary in ODM is one of the steps that will tie ODM to the Lending domain and the requirements of Lending use case.
It will be done by the rule architect and developers using the information gathered from the previous phases of vocabulary definition and data analysis to carry out the following three main tasks:

• XOM design and implementation
• BOM design and verbalization
• Creation and verbalization of variables.

Figure 10 – XOM, BOM and Vocabulary

From a rule authoring perspective the key artefact is the BOM and its vocabulary. Getting the design of the BOM correct will to large part determine the success of ODM rule authoring and yet in the standard delivery model approach where requirements are handed to developers it is often ignored with the consequence that the task of rule authoring in Decision Center is not accepted by the non-technical people and the rules are not owned by the business.
So what is the best approach? In many real world situations it is common to see a BOM design derived directly from a data model resulting in vocabulary that is cumbersome and data-centric.
For example using the Lending ERD model as the basis of the BOM will force rule authors to use the language of product and party types:

This approach must be rejected. A better approach is to base the rule on the business vocabulary of the fact model which allows the above rule to be more intuitively and naturally expressed as follows:

For this kind of rule the structural design of the BOM must be based on the Lending fact model allowing rule authors to write rules directly about borrowers instead of parties and party types, and loans and overdrafts rather than products and product types.
Figure 11 Lending Business Object Model

In this initial first cut design of the BOM the data types of each BOM member matches the data type of the corresponding attribute in the ERD. Data type definitions in the BOM can then be given further precision in the following way:

• All flat reference data types in source systems can be defined as Domains
• All hierarchical reference data, and very long flat lists, can be defined with Value Editors
• Specialized data types such as money, percentages and units of measurement the can be defined in the vocabulary with the correct symbol or descriptor (for example 500 GBP, 5% and 72 months)
• All acceptable values for use in rule authoring can be defined as ranges.

Using domains and valued editors constrain the vocabulary choices available to authors avoiding the errors that occur when values are represented as free text. They can also be directly integrated with source system reference data ensuring they can be synchronized directly with the source system and dynamically represent values during rule authoring. Doing so will ensure the ruleset using the values executes correctly as both rules and application are bound to same data.
Figure 12 Application Rules and Reference Data

To use symbols and descriptors the in-built BAL rule language needs to be extended to provide them. Specialized data types such as currencies, percentages and quantities are meaningless to rule authors and business people without the symbols and units of measurement that describe them. For example a rule authored as follows:

can be authored as the following when a rule language is extended:

This also has the benefit that calculations such as percentages are no longer displayed inline in the rule.
A considerable amount of work can be carried out to shape the BOM and its vocabulary to support rule authoring. For instance rule authors should not have to traverse a large number of business terms when authoring the conditions or actions of rules. This can be achieved by the addition of methods that de-normalize the object graph of the BOM and flattened it.
Rule authors must be presented with the correct choices of business terms when authoring a rule as they will be overwhelmed when presented with too many choices when selecting the vocabulary. To achieve this:

• Only BOM classes and members that are needed in the rules are to be verbalized.
• Verbalizations must follow business vocabulary of the fact model as closely as possible.
• Terms used only in rule conditions must be defined as read-only in the BOM, whilst terms used in the rule actions part must be write-only.
• ODM feature of categories should be used for BOM business terms and the rules that use them.

To illustrate some of these points we can return to the Lending BOM. The domain classes Currency, Reason Category and Product Type are created in a separate BOM and applied to the corresponding attributes of the Lending BOM.
A value editor is created for Reason Type that allows the selection of reason types from the reference data source system according to their categories:
Figure 13 – Custom Value Editor

One of the main ways of building an intuitive and simple business vocabulary is by enriching BOM business classes with additional methods beyond the default getter and setters that generated when the BOM is created.
Figure 14 Getter and Setter BOM member

These produce simple navigation and action business phrases that can be used in rules:

but they are rarely sufficient to provide the rich palette of business phrases needed to support complex business rules.
For example whilst the current BOM supports the business phrase “a borrower applies for a loan”, it does not support the phrase “a loan is applied for by a borrower”. This bi-directional relationship can be achieved in 2 ways: by creating virtual methods on the BOM or the following Java helper methods on the XOM.

The above 5 lines of code in the XOM and mapped and verbalized in the BOM allows rule authors to write the following rule:

In fact Java helper methods created in the XOM and mapped to in the BOM can create the vocabulary that cannot be achieved directly by attributes. For example the below method supports the business phrases “the loan is secured” and “the loan is unsecured”.
This allows the rule to be simply expressed as follows without having to use collections terminology to test the number of the securities of the loan in the rule:

Many other helper methods can be created to support rule vocabulary. For instance the following method supports the business phrase “the borrower has applied for an overdraft”:

The BOM business class Borrower, which is the primary business noun in the fact model, is declared as the ruleset parameter IN variable allowing authors to write rules about the borrower:

To avoid using collections terminology in the rules, the secondary business nouns of the fact model – loan and overdraft – are also declared as variables. This allows rule authors to write rules directly about a loan or an overdraft without being overly concerned about them being part of a collection.

This simplifies the business vocabulary and avoids the use of definitions in the rules. To avoid iterating over the loan collection in the ruleflow we can declare the business class Loan as automatic variables in the BOM (see IBM developerWorks article: Iterating over Input Parameters – Pattern matching against working memory ).

Test the Rule Authoring Capability

Decision Center is the ODM web-based browser platform for the authoring and management of rules. Developers synchronize Rule Designer with Decision Center and determine if the design and implementation effort has come to fruition or otherwise. It is the most challenging phase because it is at this point the handover from Technology to Change and the Business begins.
The mindset and culture of the two worlds of Technology and Change are very different. Developers are used to picking up a new technology and running with it. Analysts and authors are more reluctant. Often the outcome is that analysts and authors feel they have acquired additional responsibilities and ownership which they are not equipped to deal with.
To overcome these initial resistances it is necessary to support Decision Center users. This can be achieved by any of the following:

• Decision Center training, hand-holding, mentoring and guidance
• Production of user manuals and example sets of rules
• Tuning and the timely resolution of issues by developers and architects.

Training purchased from an external provider can help users understand the general Decision Center concepts and provide hands-on instruction of authoring, testing and deploying rules, the use of branching, baselines and governance.
Hand-holding, mentoring and guidance can reinforce the above whilst providing specific experience of the implemented rules application in Decision Center. Walkthroughs, guided tours and hands-on exercises are useful learning techniques. User manuals with examples support and provide reference material for the rules application.
A good approach to mentoring is the adoption of junior and senior rule authoring roles. This will help establish good practices and ensure quality gateways for rules. It is also a good approach when facing a large number of rules.
Figure 15 Rule Authoring Roles

For tuning the rules developers and architects should leverage some of the following features of ODM:

• Rule templates to create partially formed rules and provide controls over what can be changed in a rule
• Decision table column locking.
• The ODM categories feature which act as filters on the vocabulary available to an author and can be applied to rule templates.
• BOM refactoring tools which are powerful and can be used to fine tune the vocabulary by updating the verbalizations in the BOM and in the rules that use them.
• Removal of technical phrases from the vocabulary such as is null and is not null by overriding the in-built ODM boot.bom and removing unwanted terms from the vocabulary.

With each iteration of the ABRD model the BOM vocabulary should be updated to produce additional and more natural ODM phrases in Decision Center aligned to the fact model and the structured business vocabulary. Business vocabulary development is a key part of establishing a stable and steady practice of rule authoring under continuous improvement and is both art and engineering.

Validate the Vocabulary and Decision Runner

An important part of rule authoring is validation in which business owners confirm the correctness of rules. A rule can only be validated by a business owner if it is written in the language and terminology of the business so before rule validation can take place the BOM vocabulary must be approved. One approach to vocabulary validation is to produce a sample set of rules covering all areas of the vocabulary and perform a review with policy managers and analysts.
The second important part of this phase is to test the rule testing capability. It is important that rules can be easily tested by testers. The usability of ODM test framework Decision Runner relies on the BOM design which generates the test Excel spreadsheets. Rule testers should check the usability of the test spreadsheets and get their approval by business owners. In particular stage they should:

• Check for deeply nested generated Excel spreadsheets and make any adjustments to the BOM to improve their usability.
• Ensure readability of Excel spreadsheet column headers.
• Ensure drop-down lists are correctly generated in Excel for all domains.
• Remove any unneeded BOM attributes by marking them with the BOM property “Ignore for DVS”.

Summary

Developing the business vocabulary and establishing rule authoring should be done iteratively and incrementally following the ABRD cyclic model with both business and IT roles. Early iterations of the cycle establish the foundations of the business vocabulary and the rule authoring capability before rules are actually created and deployed and tested.
A rule that is business focused is intelligible to not only to its business owner, but to all people across the business spectrum and even beyond:

It can be understood and validated by business people, used as the starting point for business conversations, and the building and planning long-term business strategies using ODM simulations .
By contrast the same rule that is IT focused can be a mystery to business people and often remains firmly in the domain of IT.

One response to “Successful ODM Rule Authoring for Business and IT”

1. […] View the full article […]

   Reply