This article originally appeared on the BeyeNETWORK.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Business intelligence (BI) helps an organization make more informed decisions and become more agile in solving business problems and satisfying business requirements. It is generally accepted that there are three types of BI: strategic BI, tactical BI, and operational BI. Vendors and analysts, however, now seem to be talking about embedded BI. This is not really a separate type of BI, but an implementation approach for building certain types of operational BI applications. In this article, I want to examine the role of embedded BI and its relationship to operational BI. Before doing do, however, let’s first define operational BI.
What is Operational BI?
Operational BI is concerned with optimizing daily business operations. Other terms associated with operational BI include real-time BI, near-real-time BI, and right-time BI. There is considerable confusion in the IT industry about what all these terms mean. Part of the problem here is that the term BI is used to describe not only the way data is analyzed and the results delivered to users, but also to describe the processing involved in monitoring, capturing, and integrating the business transaction data to be used in the analysis.
When using an unqualified expression like real-time BI, it is unclear whether this means real-time data capture and integration, real-time data analysis and result delivery, or some combination of the two. This is why it is better to think in terms of operational BI being used to optimize daily business operations, and avoid expressions such as real-time BI. In some cases this optimization may require close to real-time (or low-latency) transaction data, and in other cases it may not. Often, a combination of different data latencies is required. Similarly, close to real-time data analysis and delivery may be required, and in other situations it may not.
Operational BI processing can therefore be broken down into two main tasks: 1) monitor, capture and integrate the transaction source data, and 2) analyze the captured data and deliver the results of the analysis to the requesting user or application. Like strategic and tactical BI processing, the transaction data used for operational BI can be captured and integrated in a data warehouse before it is analyzed. If lower-latency data is required for the operational BI analysis, then the data warehouse is updated more frequently based on the data latency requirements of BI applications.
Types of Operational BI Applications
Operational BI applications can be demand-driven or event-driven. Demand-driven BI applications are run when requested by a user or another application. These applications read the input request, read and analyze the appropriate data to satisfy the request, and then return the results to the requestor. This processing could be described as real-time analysis, but a better expression would be on-demand analysis. The latency of the data used in on-demand analysis will depend on the data sources being analyzed. If the source is a transaction data store then the data will be current or real-time. If the source is a data warehouse, then the latency will depend on how often the data warehouse is updated.
Event-driven application processing is triggered by an event occurring in the IT system. This event could be an update to a database or file, an application message, a notification from a hardware device, and so forth. In the BI environment, event-driven processing can be used to do close to real-time data validation and data warehouse/data cache updating. It can also be used to trigger BI analytical processing or event-driven analysis. An example of event-driven analysis is examining a credit card transaction for fraud. The use of a credit card causes an event that runs a BI analysis. The analysis can use business rules, models, and data from a data warehousing system to evaluate the credit card transaction for potential fraud.
As companies move toward the use of a service-oriented architecture (SOA), the BI processing triggered by an event can be encapsulated in a service. In an SOA environment, instead of directly triggering data validation, data updating, or a BI analysis, the event instead calls the appropriate service to do the required processing. This not only provides a more flexible distributed architecture, but also enables the service to be shared by multiple applications.
It could be argued that demand-driven BI is simply a special case of event-driven BI. After all, the issuing of a request to a demand-driven BI application is itself an event. This latter type of event, however, is different from the events that trigger event-driven BI processing. These latter events are the result of a change in state in business operations.
What About Embedded BI?
By its nature, event-driven operational BI is able to react much faster to changing business circumstances than demand-driven BI. When close to real-time operations are required, the best way to implement event-driven BI is to embed it in operational business transaction processing. In an SOA environment, this can be achieved by placing BI service calls in the business transaction workflow. BI services called in this manner can do data validation and cleanup, update a data store or cache, send a message to a message queue, perform in-line BI analyses, or update an operational BI dashboard.
We can see then that embedded BI is not really a different type of BI processing, but rather an approach for implementing event-driven operational BI. This style of implementation tightly integrates BI with operation processing, while at the same time proving a flexible development environment. It also enables organizations to use BI to make rapid decisions and, in some cases, to fully automate the decision-making process.