Introduction

A Business Rules Management System (BRMS) bridges the gap between business and IT by giving direct control for adding and managing the business policies and strategies implemented as business rules to the business.  This is fundamentally different from traditional development approaches, where developers isolate an application's business logic from its data validation logic and from its flow control.  While the business is empowered by the BRMS Technology, it remains mandatory to put these business rules under a strict IT and business governance process.

This article provides details of the custom Business Rules Governance solution built using one of the major BRMS products.  The first section explores the importance, features, and theoretical approach for business rules governance in general.  The second section focuses specifically on the DAASL Business Rule Governance Framework.^[1]

1.  What is Business Rules Governance?

Business rules governance relates to the establishment of team structures, roles, and process/communications permissions, to ensure consistent decisions and management of business rules in production systems.  Governance primarily relates to the activities to support the authoring, change management, validation, and deployment of the business rules so that they meet company business requirements.

The First Steps

Identify all the stakeholders and their roles and responsibilities — i.e., identify key people, the roles and responsibilities of all the stakeholders, and fit them into a predefined list of roles.  Note that a role does not necessarily equal a position (or a person) in the organization since one person can actually play multiple roles.  Typical roles could look like this.

Roles	Responsibilities
Developer	Works on maintaining and creating business rules
Approver	Reviews and approves the changes made by a developer
Deployer	Deploys the approved changes
Admin	Manages all the administration activities involving users, roles, and permissions.  This is a super user who can perform all the tasks of developer, approver, and deployer combined.

Lifecycle of Business Rules

Rules have a life of their own — from creation to retirement, rules go through different states.  The lifecycle of a business rule starts with rules harvesting, where new rules are identified for creation.  Once the rules are created, they go through rigorous testing before they are deployed and executed to support the business.  When a rule does not make sense any more, it needs to be retired from execution.  A governance framework handles the lifecycle of rules from creation to retirement, going through the intermediate states like requested for approval, rejected, approved, and deployed.

Figure 1.  Business Rule Lifecycle.

• New — The rule is newly created and editable, or it is being modified by the Business Analyst.
  
  
• Requested for Approval — This rule edition is complete and has been sent for approval.
  
  
• Rejected — The rule has been rejected as a part of the review process.
  
  
• Approved — The rule has been approved by the approver and is ready for the next action.
  
  
• Deployed — The rule is deployed into the production environment.
  
  
• Retired — The rule is no longer effective and is set up for archiving.

Rights Management

Commonly called Authorization and Authentication, Rights Management plays a vital role in implementing business rules governance by providing the ability to restrict users to certain roles and responsibilities.  A governance framework allows the administrator to define the permissions for a role at various levels:   at project, Line of Business, folder, or entity levels.  The processes and lifecycle of rules (states and transitions) might require that only people with specific roles are allowed to perform specific operations.  A user role can have any one of a number of permissions, such as no access, read, or write for any given entity.

For example, all users might have the right to read all the rules, but only users from the specific Line of Business (LOB) can change the business rules related to that LOB.  When there are multiple product lines, you might want to limit access by product line.  You might even want to break access down to an entity (or entity instance) level within a LOB.  This all depends on your organization's needs, the size of the team you are dealing with, the organization of work related to business rules, etc.

Change Management

Change management needs to take into account many situations and is probably one of the processes that will require the most work.  One key point to remember is that not all changes are created equal.  Some changes will require a very light process to implement whereas other changes will need a much more involved process because of the type, scope, or complexity of the change.  A change management framework shall encompass the following:

• Tracking the history of changes — who changed what and why;
• Attaching readable comments that move through the rules lifecycle;
• Providing a workflow to rely on for managing the approval process;
• Supporting visual comparison of versions;
• Reporting all the change requests in the system;
• Providing a visual log for a given change request/change;
• Providing for multiple rule changes within a single change request;
• Supporting the automated deployment of approved changes;
• Checking the impact analysis of the changes.

2.  Custom Business Rules Governance Framework

Most BRMS systems do not provide out-of-the-box implementations for user groups and roles management, authentication/authorization services, tracking rule changes to change requests, and a release management process for the rules.  In this article, we will be discussing the Governance Framework we built with FICO Blaze Advisor as the BRMS Technology.  Our Governance Framework is a pluggable module that can be installed on any version of Blaze and provides the following functionalities on top of the Rule Builder IDE (Integrated Development Environment) or the RMA (Rule Maintenance Application):

• User Groups and Role Management;
• Authentication & Authorization;
• Change Management, Rule Lifecycle & Release Management.

Administration Interface

The administration interface, which is tightly integrated into the RMA UI Framework, enables the users to manage the team and change management dashboard.  The list of options provided is based on the logged in user role.  This diagram displays the case of administrator for "Team Management."

Figure 2.  Administrator for Team Management.  

High-level Block Diagram

Our Governance Framework block diagram provides the higher-level overview of the different components that support this solution.  The Framework provides the custom components for integrating with the Advisor Security Framework, RMA server APIs, and the Custom UI extension to the RMA.

User Management

The User Management component provides the interface to create and manage user details.  A user can be assigned to multiple roles, in which case the user will have the combined permissions of all the roles.  A user management table provides flexibility to modify the user roles and status, and to unlock the locked users.

A user can be associated with any of the active roles in the system.  This interface interacts with the data store to persist the user information.  Our system currently supports different data stores, such as database and XML.  The Framework provides the flexibility to add new data stores easily

Managing Groups & Permissions

The Framework provides a User Interface that is accessible to the administrator to manage the groups and their permissions.  It provides the functionality to create and modify group details such as status and change management role.  The change management roles are developer, approver, deployer, and administrator.  The Framework also provides the interface to manage the projects and permissions.  The Manage Projects section allows the administrator to assign the projects that the group can access. 

This interface provides the permissions such as no access, read, and write, which can be assigned to a group at any given folder or entity level.  If the permission is not set at any given level it inherits the permissions from the higher folder within the hierarchy.  The configuration of groups helps the change management framework handle the accessibility of different actions.

Figure 3.  Manage Groups & Permissions.  

Change Management

Change Management helps with the management, auditing, and coordination of simple and complex business rule changes across the IT environment.  The flow of activities in a change workflow can be fully customized, ensuring that tasks are completed in the right order by the right people.

Change Management is a process-based tool that addresses the domain of change management for business rules.  Using these flexible capabilities, change can be managed in an orderly, efficient way.  It supports the following:

• Creation of a new Change Request (CR);
  
  
• Ensuring that the CR entities that are being changed are traceable and auditable;
  
  
• Use of a pre-defined process workflow that contains the specific steps required for managing business changes;
  
  
• Assigning roles to ensure that a change process workflow is started, managed, and implemented by the right people in the organization;
  
  
• Coordination (by the Release Process Manager) between the change and release processes to assign changes to releases;
  
  
• Planning change implementations to include specific tasks that are appropriate for each change;
  
  
• Viewing a timeline of the change for every CR that is being changed, along with information about the associated entities and the impact of the change on business systems;
  
  
• Verifying change history for audit and compliance purposes, thereby achieving complete visibility into which CRs have changed.

Figure 4.  Change Management Process Flow User Interface. 

User Interface

The Framework provides an extension of commands like Associate, Disassociate, and Submit for Approval to the out-of-the-box RMA commands.  The commands are enabled or disabled based on the user roles and the selected context.  Commands are provided both for project explorer and instance editor components.  The supporting entities (such as queries and filters) are excluded from the Change Management process.

From the Administration menu, a user can view all the change requests in a single view.  The Change Management table displays all the details of change requests such as number, status, description, date created, and the associated changes.  A Change Request can be used to handle multiple instance changes, hence the table shows the status and actions that could be performed on a particular change.  At a given change level, a user with appropriate roles can perform actions such as review changes, log viewer, reject, and return.

A context-based toolbar is provided for managing the change requests in the table.  The list of commands displayed in this toolbar is based on the selected change request and the user roles.  It has several commands to support table filtering, log viewer, creation of new change request, editing a description, submitting for approval, rejecting, return, and approval.

The log viewer displays the actions that are performed on a change request or an instance change.  It displays a table with date of action, user, and the comments during the execution of action.

Review Changes

The Review Changes command action at the instance change displays a visual difference dialog with the listed differences.  This uses the comparison query component of the BRMS, with added extensions to support the comparison between the entities changed in the developer workspace to the previous version in the master repository.  This helps the approver to review the changes before approving the changes.

Figure 5.  Visual Differences.  

References

[1]  DAASL Business Rule Governance Framework, URL:  www.daaslinc.com/en/brms.html  

# # #