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 Continued from Page 1 A House DividedBI implementations that employ just one of these tools create fragmentation. For example, many BI tools are based on "cube" technology, storing data on fat clients, or both. Therefore, their scalability is limited in a few directions. BI tools can't scale up to manipulate the vast amounts of data in today's data warehouses. They can't scale up to large numbers of employees (or other stakeholders outside the organization), because the administrative burden of updating all that data and software is prohibitive. Although some tool vendors offer more than one product marketed together as a "suite," integration between them may be, at best, limited. Some tools haven't made a substantial investment in SQL engines, which should be capable of issuing SQL that's tuned for the target database at the instant the query is issued. This shortcoming forces you to build downstream structures of data marts, cubes, and other workarounds. These provisions add latency to the data warehouse, limit the usefulness of the detail in the data warehouse, and so severely constrain the range of possible analysis that the whole investment becomes questionable. The result of all this fragmentation is that effectively sharing data among groups becomes impossible, managing changes becomes too laborious to be efficient (at a time when enterprises are gearing up to become more "agile"), and ensuring consistency in models, definitions, and even the data itself becomes difficult. BI's fractured landscape adds a huge hidden cost to organizations, a so-called "shadow IT." This unrecognized job function comprises mainly non-IT workers in finance, marketing, human resources, or sales administration, who spend a significant amount of time, up to 60 percent of it, wrangling data. With the effort of manual keying; building and maintaining spreadsheets and personal databases; and filing, searching, and disseminating data, these professional people spend only a fraction of their day doing their real job. The rest is consumed by data activities that should have been largely eliminated by the data warehouse and BI. Operational systems are moving away from stovepipe architectures, the very phenomenon that led to the invention of data warehouses. Ironically, BI now has become a series of stovepipes — virtual islands of integration. The largest and most sophisticated organizations in the world, the ones with both the resources and prerogatives to do so, are vigorously pursuing agile architectures that will free them of these operational system stovepipes and allow them to configure and reconfigure business processes on the fly. This type of initiative demands the implementation of agile components or, in other words, the "desilofication" of operational systems. But in many of the same organizations, the downstream data marts and cubes from the large, unreachable data warehouse are completely walled off from each other, often built with many different, incompatible technologies. While the very silos that led to data warehousing in the first place are disappearing, data warehousing and BI is becoming increasingly mired in its own silofication A few vendors have devoted real attention to this problem and are dramatically progressing toward delivering truly enterprise BI. For other vendors, this is an ominous sign: To move to the next level, they will need to jettison and rebuild most, if not all, of their underlying constructs. For a BI platform to be truly enterprise, it must have the following qualities A complete API. In fact, more than one API is preferable, such as Java 2 Enterprise Edition and .Net together. The APIs must expose 100 percent of the functions of the entire package, enabling transparent integration of the platform into the full set of operational software. Powerful SQL engine. Because no viable alternative for deriving the latent value of massive data warehouses exists, other than SQL, enterprise BI must contain a powerful SQL-generating engine. The engine must be able to resolve analytic queries entirely within the relational database engine (embedded OLAP engines and extensions to SQL reduce the difficulty of this requirement over time), using multipass logic and SQL tuned for the target database. Adequate performance. Enterprise BI must be able to provide adequate performance against the largest databases. Schema openness. It must be able to deal with a variety of database schemas without needing to physically alter them. Scalability. It should easily scale from hundreds to thousands — or even millions — of users. As BI applications become embedded in business processes, they're gradually becoming transparent. In many cases, they are invoked, not by a knowledge worker interactively, but by an automated agent reacting to conditions in real time, by an interactive Web commerce application or by almost anything at all that requires analytics.
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
| ||||||||||||||||||||||||||||||||
