The Business Intelligence Guide

Business rules are a vital part of defining and managing any performance management system. For this reason, they are central to defining business requirements used to configure business intelligence (BI) solutions.

Business rules are the basis upon which BI reporting applications:

• Automatically interpret data
• Define meaningful key performance indicators (KPIs)
• Suggest remedies for performance problems

In this way, BI projects use business rules to calibrate the BI tools used by the business to the specific way the business operates. It enables the tools to be aligned with the context of the business behavior.

For instance, instead of a report simply showing the standard 'Number of Inbound Service Calls' by aggregating all the base data, summing up the number of calls, the rules around how quickly Inbound Calls must be answered will provide the Service Manager with more information by providing:

• Total Number of Calls
• Percentage Calls Not Answered in Required Time

This information will likely directly relate to the performance of the Customer Service team to SLA targets.

By adding in futher rules around escalation of calls, further insight can be gained into both the performance of the Customer Service team, HR resourcing, performance to SLA and customer satisfaction ratings.

Thus, base data depends heavily on rules that define how to interpret the data.

BI Business Rules Perspectives

BI experts use the term "business rule" in both a business perspective and an IT perspective, depending on their current objective.

Business Perspective

Business rules help to encode normal business practices into reusable business logic that can be accessed by multiple applications.

Business rules enable the meaningful interpretation of raw data, into insightful reports that support planned business actions. They are an absolute must for root-cause analysis and operational BI.

As BI becomes more process-oriented, capturing of business rules is becoming increasing importance. Strategic or tactical BI typically contain multitudes of implicit business rules.

IT Perspective

From an IT perspective, business rules are typically encoded in either the ETL processes of a data warehouse or within BI tools during the design of specific reports. This is less than ideal.

A better way is to use an independent Business Rules Glossary solely dedicated to the capture and management of business logic. This independent business logic module combines specification, implementation and documentation of business rules.

The advantages of using a discrete module are:

The business logic can be transparent to the business users - this is not possible if business rules are buried deep inside ETL or BI tools. This ensures that rules are assessible when questions arise - to determine whether a breech of rules has occurred or if rules support new business initiatives. Business users can readily see which business rules are implemented and how they affect reporting results.

Business rules are more accessible to technical developers - to enable use of or modification of business rules when the underlying business processes are modified or new business needs or insights require change in business rules.

Typically, as BI tools help businesses improve performance management, the users learn more as time passes. This leads to improvements in underlying business processes, where more detailed rules are often discovered. This means the business rules can be adapted without interfering with IT components, and rules will be applied to ALL applications accessing the Business Glossary.

Abstraction of business logic from the IT infrastructure reduces duplication of both IT work and business requirements gathering for multiple projects, across all business functions.

Hence, if sales and marketing now wish to to build a KPI for customer satisfaction, they can include the customer service calls performance component outlined above.

This greatly assists communication across the business - as everyone is referring to the same metrics, with the same meaning.

Also see: Master Data Management [MDM]

Master data can be seen as a simple and specialized version of business rules.

Master data heavily influences the interpretation of data across different IT systems and that this interpretation should be consistent throughout the whole enterprise. Master data encodes business logic.

MDM depends on the same business rules.

Business Rules Engine [Systems]

A Business Rules Engine is a System that houses the business rules and technical logic to share these definitions with other business departments and software systems. This acts as an interface between business and IT, greatly reducing the need for IT developers to write programming code. Instead, the programming code is generated by the business logic component itself.

More advanced business rules engines are called "expert systems" where artificial intelligence infers implications of given business rules on a set of data.

Bottom Up BI Projects

If the BI Project is being driven from the data model up, it is crucial that the encoded rules of a business rules engine are readable in business terms, so businesspeople can administer or at least review the rules before configuration of reports and dashboards.

For this reason, business rules should be:

• Declarative - short and concise, not long procedural explanations, separating the management of business knowledge from its employment during a business process.
• Formulated in natural language

Business Rules for Operational BI

In spite of business rules deemed to be 'declarative', in a BI environment, especially in an operational BI environment, business users tend to think about business rules in a procedural way.

For example:

• A declarative rule would be "a processing center has three days to provision a service order"
• A procedural rule would be "a processing center has three days to fufill a service order except if the request has been transferred from another processing center, in which case the processing center has three days to provision the order minus the time that has already been spent in the previous processing centers."

Thus, the procedural rule contains more detail about the underlying business process: that service orders can be redirected from one processing center to another.

This leads to the need to have a hierarchy of business rules, where they can describe a process or subprocess. Worflow diagrams are typically used for this purpose.

This type of business rules definition is essential for the capture of the process details to be used in an operational BI environment. If automated decision making is to be embedded into a process, then all rules and subrule dependencies need to be clearly defined.

Business rules engines can derive executable program code from workflow diagrams and apply it to operational data.

Business Rules in SOA

In a service-oriented architecture [SOA], business rules engines can provide both the business logic calculation as well as business rules definition via Web services. For instance, if a request includes the term "In Due Time", the business rules engine can apply the logic from the rule definition.

To optimize reuse, business logic can be applied during batch processing and store results directly with operational data in an enterprise data warehouse. This makes results immediately available for BI applications and reporting tools.

Next: Data Management

Back To Top