Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

September 17, 2003

Breaking Out of the Warehouse

To many, BI is equivalent to data warehousing. Although data warehouses are important, they're not the total solution. To deliver all the BI capabilities business users want, we need to create a BI grid

by Michael L. Gonzales

Continued from Page 1

What's Missing

Data warehouse applications provide an important source of strategic data necessary for prediction, forecasting, and trend analysis. But while the definition of BI includes strategic analysis, it by no means is limited to that type of application. BI must also offer solutions for zero-latency analysis, business activity monitoring (BAM), business rule inference, key performance indicator (KPI) reporting, and even some straightforward, tactical reporting.

Limiting the enterprise's BI efforts to the established standards of warehouse-centric technology and techniques guarantees that an organization will never be able to effectively address all BI requirements. In fact, many warehouse efforts fail to deliver on the BI promise. At least 50 percent of BI projects won't reach their full potential or will be dismal failures during 2003. Project planners and BI architects who insist on overlooking the fact that there are multiple layers that form the BI fabric of their organizations risk being part of this failure rate.

The Layers of Business Intelligence

Let's first examine the raw materials of BI applications — the framework of BI layers — before I explain how a fabric of agents can close the existing gap between expectations and implementations. There are at least five distinct BI layers in any large organization: technical, data, application, touchpoint, and geographic. (See Figure 1.)

Each layer affords a unique perspective and is a source of exclusive information. These layers should work as a cohesive whole but, unfortunately, they often do not. BI planners and architects must consciously consider all these layers when designing BI applications. Table 1 defines the layers and cites examples of representative objects within them.

This article concentrates on the objects in each layer and the architecture of the layers themselves without discussing the data, information, or value within each object. The rationale is simple: Any BI effort must move through the lattice of BI layers and objects to gain access to the data, information, and value sought.

What organizations need in order to remain competitive is a fusion of traditional and advanced technologies that, together, support a broad analytic landscape, efficiently serving up a rich blend of real-time and historical analytics. Business intelligence must drape over the enterprise like a fabric, covering all the relevant information sources and critical touchpoints.

In other words, we must learn how to navigate across the breadth of the enterprise, traversing the necessary layers, while monitoring, collecting, or otherwise interacting with specific objects within each layer. Figure 2 illustrates a cohesive network of agent-based technology. This network provides the means to react (signified by the "Action" icons) to the changing landscape of your environment. Simply put, this network of agent-based technology allows you to target specific data and system events throughout your enterprise by monitoring, collecting, analyzing, notifying, and otherwise acting upon data and system events as necessary.

Many user communities spend their entire "analytic life" focused on the informational insight found by combining a few, specific objects of only one or two particular layers. For instance, the budget and forecast officer may be concerned with only the online analytic processing (OLAP) tool that performs what-if analysis (the application layer) and the cube that contains the data being analyzed (the data layer). That's it. The work performed by this office may be invaluable to the organization; nevertheless, the work is based on a rather straightforward BI requirement — essentially two objects, one residing on the data layer and the other on the application layer.

Of course, other requirements aren't so simple. For example, if you're the VP of marketing, you may need to monitor Internet advertising campaigns. For this task, you might collect clickstream data from your Web site and filter the interest points of users who entered the site via a banner ad and ultimately bought something. Then, you would blend these identified customers with third-party demographics to get a perspective of their income level, tastes in automobiles, and even reading habits. Finally, you'd bind sales history to this composite view of an Internet buyer who was attracted by the banner ad. You can now run data mining applications against this information to glean insight. The point is that this requirement is a complex BI effort. Gathering and analyzing just the clickstream data may require traversing applications, touchpoints, and geography, as well as the data and technical architectural layers. And I haven't even addressed the third-party data, sales history, and mining application!