Business Rules and Business

of 5 Business Rules and Business Intelligence Information Management Magazine, April 2007 Robert Blasum Business rules represent an essential part of any performance management system and any business intelligence (BI) project. They allow reporting applications to automatically interpret data, to define purposeful key performance indicators (KPIs) and to suggest remedies for problems. BI projects often start out with a minimal or nonexistent set of business rules. For example, in a customer service environment, the head of customer service might initially request a report showing how many customer service calls have been made to each service center per day. Assuming the data is available, this kind of report could be readily implemented with standard BI tools. Generally, all that needs to be done is to aggregate the base data, summing up the number of calls. ADVERTISEMENT However, once the head of customer service receives this report, he or she might then ask for the number of service requests not processed by a call center in due time. At this point, potentially complex business logic comes into play. One must identify the start and end of a request, follow up on a request reassigned to another service center, measure the time between the start and end, take holidays into account and compare it to a target response time. That is, the resulting report is no longer a straightforward presentation of the base data: it depends heavily on rules that define how to interpret the data. BI experts use the term "business rule" in a variety of meanings and contexts. Definitions of the term can focus completely on a business point of view or, in other cases, be geared toward an IT perspective. Ronald G. Ross provides a description of a business rule that encompasses both sides. From the business point of view, he says, "Business rules are literally the encoded knowledge of your business practices." And from an IT point of view, "A business rule is an atomic piece of reusable business logic."1 Business rules form such a crucial part of performance management and BI because they give meaning to the numbers. Business rules allow one to interpret raw data, to come up with insightful reports and to use the information to propose actions. They are an absolute must for root-cause analysis and operational BI. With BI becoming more and more process-oriented, this is of increasing importance. But even classic BI systems,

of 5 i.e., strategic or tactical BI, almost always contain dozens if not hundreds of implicit business rules. From an IT perspective, business rules are often encoded in either the extract, transform and load (ETL) processes of a data warehouse or within BI tools during the design of specific reports. Both of these variants are less than optimal. A better way to encode business logic is through an independent description of rules in a separated module. This software component is solely dedicated to the implementation of business logic. Such a structure bears four major advantages. First, if designed well, the business logic module can be transparent to the business users. If business rules are buried deep inside ETL or BI tools, the business user cannot review the implementation. He or she has to trust the programmer that all rules have been implemented correctly and work according to the documentation. Furthermore, when questions arise, the original programmer might need to get involved in order to answer questions. For example, if a customer service request is considered to be resolved late - is it late if it took three days, or if it took more than three days? An independent business logic module, in contrast, can be constructed to combine specification, implementation and documentation of business rules. This allows business users to turn to one central module in order to see which business rules are implemented and how they affect reporting results. Secondly, during the course of a BI or performance management project, business rules are modified frequently. This is mainly due to two reasons: 1) the underlying business processes are modified, e.g., because of insights gained from reports of the performance management project; and 2) again possibly due to reports from the BI project, the understanding of the underlying business processes improves, and more detailed rules are discovered. In both cases, the business rules need to be adapted. This is greatly facilitated if they are kept in their own module, without interfering with other IT components. Thirdly, independence of business logic from the rest of the IT infrastructure cuts down on duplication: if the IT department decides to replace one ETL or BI tool with another, the already-implemented business logic does not need to be implemented again with another tool. As the Business Rules Group puts it in their manifesto, "Business rules should be organized and stored in such a way that they can be readily redeployed to new hardware/software platforms."2 Finally, a centralized business logic module allows for cross-functional, corporate-wide usage and management of business rules. Consider the initial customer service example. A marketing and sales department of an organization might want to build a KPI for customer satisfaction. Part of this KPI might be how many customer service calls a specific customer makes and how many of those are processed in due time. It is important that marketing and sales has the same understanding of "processed in due time" as customer service. That is, marketing and sales needs to apply the same business logic for its reports as customer service does. This can be achieved by a central repository of business rules that every department can review, understand and use for their own reports.

of 5 Related to this last point is the growing interest in master data management (MDM). At present, an increasing number of organizations believe a central MDM is essential to their business in order to have a consistent definition across individual departments. The awareness has grown that 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. As such, master data can be seen as a simple and specialized version of business rules. A survey about the status of master data management conducted by The Data Warehousing Institute shows that among the responding companies, only 20 percent of organizations practice MDM as a separate solution.3 The number of companies practicing business rules management as an independent solution can be assumed to be even lower. However, the same needs that demand corporate-wide MDM also apply to business rules. Companies will likely look for ways to develop corporate-wide business rule management systems in the future. What should an independent business logic component look like? In general, business users as well as IT users should be able to define business rules with it and to share these definitions with other business departments and software systems. By design, the component provides an interface between business and IT. In fact, the idea is to directly interface the business users with reporting or operational IT systems, eliminating, to a large extent, the need for IT developers to write programming code. The programming code should be generated by the business logic component itself. Experts commonly call such a component a "business rules engine." Unfortunately, two different schools of thought use this term, which frequently leads to confusion. For some this term denotes a software application that can be used to capture know-how about business practices and processes and then allows application of this knowledge to operational data in order to gain insight into specific instances of an operational process. The article follows this understanding of a business rules engine. Others use this term for so-called "expert systems," an expression coming from artificial intelligence that infers implications of given business rules on a set of data. Both types of applications encode business rules; however, they are used in rather different settings. It is crucial that businesspeople can administer or at least review the encoded rules of a business rules engine. Therefore, the business rules have to be encapsulated in such a way that they are easily understandable to a business user. This is why business rules experts frequently postulate that business rules should be declarative and formulated in natural language. "Declarative" in this context is used in opposition to "procedural." A common concern with business rules engines is that, over time, the language that is used in order to encode the business logic degenerates into just another programming language, defying the original purpose of the engine. The postulation that rules be declarative helps avoid this trap. It separates the management of business knowledge from its employment during a business process. However, in a BI environment, especially in an operational BI environment, business users tend to think about business rules in a procedural way. That is, instead of a declarative rule such as "a service center has three days to resolve a request," one

of 5 frequently finds rules like "a service center has three days to resolve a request except if the request has been transferred from another service center, in which case the service center has three days to resolve the request minus the time that has already been spent in the previous service centers." The latter statement contains more detailed knowledge about the underlying business process: that requests can be redirected from one service center to another. In such an environment, it is useful to allow business rules to describe procedurally a process or subprocess. Such a description can be efficiently formulated in the form of workflow diagrams. Many business rules experts disagree with this interpretation of the term "business rule." In fact, from their point of view, this is exactly what a business rule should not be. But in an operational BI environment, it often represents the most natural way for business users to formulate the business logic underlying their operational processes. Workflow diagrams can be understood by both business and IT users and are able to efficiently encode the typical if/else logic that forms the core of most business rules. Business rules engines can then derive executable program code from these diagrams and apply it to operational data, either on request or during batch processing. 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 example, an SOA service can answer requests such as, "Please show me if this specific customer service call has been processed by our service center in due time and provide me with the precise logic of what 'in due time' means in this context." The business rules engine can retrieve the definition of "in due time" and apply this logic to the provided call data on the fly. For reporting purposes, it is often beneficial to apply the business logic during batch processing ahead of time and to store the results directly with the operational data in an enterprise data warehouse. This way, the results are readily available for BI applications and cross-functional purposes. Thus, centrally managed business rules enable BI projects to draw from the business know-how of a company and to work with consistent sets of business logic - they are what add the intelligence to business intelligence. References: 1. Ronald G. Ross. Principles of the Business Rule Approach. Boston: Addison- Wesley, 2003. 2. Ronald G. Ross. "The Business Rules Manifesto, Version 2.0." Business Rules Group, 1 November 2003. 3. Philip Russom. "Master Data Management." TDWI, October 2006. Robert Blasum is CTO for BusinessCoDe in Germany. He may be reached at rblasum@business-code.de. For more information on related topics, visit the following channels: Business Intelligence (BI)

of 5 Business Rules Governance, Risk and Compliance Corporate Performance Management (CPM)