Business Rules And Business Intelligence

Business Intelligence projects start out as a simple report or request for an extract of data. Once the base data is aggregated then the next request usually is about summing data or creating more reports that have different views to the data sets. Before long complex logic comes into play and the metrics coming out of the system are very important to many corporate wide citizens. "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."(pg14)

Once reports are no longer a straightforward representation of base data they begin to depend more and more on business rules. The term itself "business rule" has a variety of meanings. In our text it is defined on page 87 as "a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the businessÐ'... rules prevent, cause, or suggest things to happen" (Guide Business Rules Project,1997). Ronald G Ross provides his version in this article as "Business rules are literally the encoded knowledge of your business practices" (pg14) from the business side and "an atomic piece of reusable business logic"(pg14) from the IT side. They are so important that this needs to be understood to go farther because the rules give meaning to the numbers. They allow us to come up with insightful reports which give us a useful interpretation of raw data. Ultimately we can act on this information and save time not only for operational BI but also for root-cause analysis.

For the IT side these rules are the ETL (Extract, Transform, Load) process side of a data warehouse or within BI tools themselves. "A better way to encode business logic is through an independent description of rules in a separated module." I work in the finance industry and many trading compliant systems work exactly that way for speed, efficiency and audit purposes. This kind of structure has four advantages: transparency for business users; modifications can be made without interruptions; independence of platform and portability; and lastly cross functional usage with a central repository.

Transparency for business users is provided through an independent business logic module that "can be constructed to combine specification, implementation and documentation of business rules."(pg15) This allows the business user to look in one place for the business rules in contrast to the old method where a programmer might bury nested rules all over a system making the environment so complex that anyone could not verify the rules or be sure of the output.

During a BI project the rules will change constantly because as new information is revealed additional rules will be needed as the understanding of data changes. This means that the business rules need to be adapted or modified throughout a lifecycle and you need to maintain separation from the other IT components so there are no negative impacts and the system can scale as needed. As the processes are better understood additional business users will add new dimensions and loads so that a system may always be evolving.

Business logic independence from the rest of the IT infrastructure reduces duplication and as decisions are made favoring one tool vs. another the core structure does not have to change, an interface from the new system to the old can be created. "Business rules should be organized and stored in such a way that they can be readily redeployed to new hardware/software platforms."(pg 15)

A centralized business logic module would provide consistent rules that can be cross-functional a managed at the corporate wide level. Efficiencies can be driven and duplication can be reduced. For example Marketing, Sales and Customer Service areas need to know how many customer issues are reported and how those customers' issues were dealt with. How timely? How