Stepping Up BI ExpectationsA jumbled array of disjointed analytic, reporting, and alert tools exists in most enterprises, unconnected to a unifying enterprise BI architecture. The situation has to, and will, change.
by Neil Raden It's a good news/bad news story. The BI industry is poised for a giant leap forward. The bad news is, many of the incumbents are going to be left behind. In its first 10 years, BI evolved from a replacement for mainframe reporting to the essential tool for disseminating and analyzing information. In that same time period, the dramatic expansion of data warehousing, combined with the widespread adoption of enterprise solutions such as ERP and CRM and the overall increase in computer literacy fueled the expansion of BI demand and BI companies. Today, most of the leading tools are in release 6 or 7, indicative of a mature market. Despite this relative maturity (some of it admittedly just version inflation) BI has a long way to go before it can take its place at the table with other enterprise solutions. At a time when the urgency to innovate is as its greatest, however, many leading vendors have chosen not to. Instead of perfecting and expanding their architectures, most BI vendors have turned their attention to computing cul-de-sacs and management fads like dashboards and balanced scorecards. To be truly effective, BI needs to rise to the level of other enterprise-class software in the same way that, say, accounting software did. General ledger/accounts payable applications used to be implemented by division but were eventually supplanted by ERP. Most didn't make the cut, adding modules such as activity-based costing instead of ramping up the architecture. By not addressing the architectural problems IT faced when supporting 30 different instances of the application around the world, these vendors ended up in the dustbin. A similar fate awaits BI vendors who don't follow the trend, listen to their customers, and make investments in their core technology. Why Most BI Isn't Enterprise-ScaleThe gap between true enterprise software and where BI stands now is wide. In most instances, BI isn't even a divisional effort. Instead, it's a departmental decision. The selection process is often a beauty contest, not based on sound architectural criteria. It's not uncommon to see two, three, or more BI tools installed in a single division. Although some cite the best of breed approach as the rationale for this smorgasbord of software, making the claim that each instance is more productive because the software is the best fit, the claims can't be substantiated. More productivity is lost to duplication of effort and resources than is potentially gained by such a fine-grained selection process. In addition, if new business processes cause changes in the data warehouse, the impact of not one but two or three BI implementations has to be considered, negotiated, and implemented, stultifying agility and speed. And perhaps most dangerous of all, the lack of commonality violates one of the central tenets of data warehouses: arrival at "one version of the truth." Actually, this notion is simplistic, since the "truth" in disciplines such as accounting, for example, is highly subjective anyway. To be more precise, data warehousing was designed to largely eliminate, or at least make unlikely, vastly different results being reported from the same set of data. Because the data warehouse doesn't contain all calculated, derived, and summarized data, the accuracy and consistency of these calculations falls to the BI environment. It's impossible to ensure accuracy and consistency with multiple BI tools. For simple queries and rollups, it may not matter. But for more complex models, just keeping the calculations in sync across different tools is hard enough. Reflecting those changes that occur upstream in the data warehouse is likely to introduce delay and error, even if it's only a timing error. No BI tool performs well with a data warehouse schema out of the box. Most require you to physically modify the data warehouse design. Managing multiple demands on the database as a result of multiple BI tools is tedious work for the data warehouse designers. Conflicting demands can also arise. All these factors make the multivendor approach to BI ill-advised. But things don't usually happen without a reason. In the face of all the drawbacks, why would organizations choose to use more than one BI tool? It might be that no better option exists. Perhaps there are some core features and functions in currently available, non-enterprise BI tools that no one tool can satisfy:
In fact, the first definition for enterprise BI is that it must provide all these BI functions. And it must do so within the single, integrated framework of its architecture, metadata, and APIs (at the level of the software, not the box that contains it).
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
|
|