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)
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
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
- 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
Thus, base data depends heavily on rules that define how to interpret
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 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.
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
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
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.
- 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
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
The World's Leading Guide To BI Strategy, Program & Technology
Data Index | Data Defintion
| Meta Data | Data
Management | MDM | Data
Governance | Data Cleansing | Normalization
| Data Integration | Data
Growth | Data Solutions