Traditionally, getting business intelligence has required significant upfront planning, preparation, and design. Even if the reporting system is ad hoc, chances are it hits against a defined data source – either a data warehouse, mart, or transaction system – using data models designed in advance. Not surprisingly, BI has customarily been associated with the reporting or analysis of historical trends.

Made possible through an integration middle layer that abstracts the transformations, operational BI does away with the need to plan all the data preparation up front. Or does it?

Obviously, operational BI requires planning, but instead of designing the data infrastructure, you plan the events that the BI system must "listen" for and design the analytics that must be performed. The end goal remains the same: Identify what your organization needs to know in order to operate or compete better. But instead of defining it based on what data you have available and what you have to do to that data, you look at what processes are occurring and how those processes should be analyzed.

For instance, in a manufacturing environment, the system listens for EDI messages from a supplier. When a message indicates a late delivery, the system automatically notifies the procurement manager. In this case, you didn't prebuild a data warehouse or define the data source or transformation; you targeted an EDI process.

But let's up the ante. Maybe you need to know not just whether there's a delay, but whether the supplier's performance is falling below par. Here, you'd design the system to listen for the late delivery event, parse the EDI message to identify the supplier, then run a query against a data mart that tracks supplier history. You have an algorithm that rates the frequency and severity of the supplier's performance and, bingo, an alarm is triggered. If you have the chance, you can yank the order, void their contract, or put the supplier on probation.

Now you've designed the system to listen for an event. However, to deliver the operational intelligence you need, you still ended up going against a data mart where the data was previously staged according to traditional means.

Consequently, operational BI requires a different approach to application design. Thanks to new integration technology, data can be transformed on demand rather than in advance. The result is that you view planning a BI application through the eyes of the event rather than by the pool of data that is immediately available. But, if you leverage the intelligence that you already have, prestaged data likely continues playing a key supporting role.

There's an obvious reason why data warehouses (or data marts) have grown popular with BI users: You don't want to overload live production systems with analytics or queries. Not surprisingly, the vast majority of WebFOCUS installations go against warehoused data.

With the trend toward extending BI from historical to operational data, it's fair game to ask: Does it now make sense to drill down to production systems, since that's where the action is?

The short answer is, anything's possible, but in fact you'll find yourself contending with the same problems that data warehouses were designed to avoid. If you're still considering crossing that chasm, you'll need to set significant limits as to how heavily your BI users can hit the transaction system. For instance, you'll probably want to limit the number of rows that can be accessed by any query or live report, factor in the priority of the requestor, and limit the scope or complexity of the query itself. You'll probably also need to institute rules prohibiting analytics or access by time of day or traffic level.

There are other solutions, of course, such as trickle-feeding the data warehouse, where transactions are gradually fed to the data warehouse shortly after being posted, or using an event-driven architecture that intercepts significant application events or messages "off the wire" before they are stored in any transaction system.

The bottom line is whether such draconian measures are worth it. For instance, when monitoring staffing levels at a call center, does it make sense to analyze call traffic patterns every 60 or 90 seconds, or would it pay to wait 15 minutes so you can filter temporary spikes out of the big picture?

Etta Levine is editorial director for Information Builders' Insights and editor in chief of Information Builders Magazine. To provide feedback go to www.informationbuilders.com/insightstalkback

If you received this message in error, or wish to unsubscribe from this newsletter, please send a blank e-mail to stopinsights@informationbuilders.com.

Information Builders, Two Penn Plaza, New York, NY 10121