In-Depth
EII: The Prototype for a Killer App?
Some folks tout an intriguing, if esoteric, use case for EII: as a tool to help prototype the design or expansion of a data warehouse.
Sometimes, it seems as if enterprise information integration (EII) is a technology in search of a compelling use case. Call it the Caine (of Kung Fu fame) of the enterprise business intelligence (BI) technology-scape: it’s a helpful (if frequently transitory) tool that has the potential to benefit many organizations in many very different situations. Some folks, for example, tout frequently refreshed reporting—i.e., real-time (or right-time) access to time-critical information—as one of EII’s killer apps. Others say that data federation itself is the thing.
Still others tout an even more intriguing, if esoteric, use case for EII: as a tool to help prototype the design or expansion of an enterprise data warehouse. In this scenario, users say, EII can help give data warehousing adopters a kind of clairvoyance into what the end result—i.e., an enterprise data warehouse—might look like in their unique environment six, twelve, or even 18 months down the road. An epiphenomenal use case for EII concerns ongoing data warehouse management: organizations can also tap it as a means to prototype proposed expansions to existing warehouses, proponents say.
“We’ve come across customers that are ... either looking to build a data warehouse, or they want to see what one will look like, … [and] you can almost get a virtual data warehouse-like look of what something’s going to look like by combining data from various sources, well before you build the data warehouse,” says Tom Villani, vice-president of global alliances with MicroStrategy Corp. “So whether it’s a true federated approach or a glimpse into something six to 12 months down the road, we now have a unique environment that lets them do that.” Villani made these remarks in the context of MicroStrategy’s recent accord with Sybase Inc., whose Avaki EII technology the company certified for use with its MicroStrategy 8 BI platform.
He thinks this is one of the cases for which EII is tailor-made. “We can actually say to the customer, ‘How would you like to actually see what that [data warehouse] might look like ahead of time, six or twelve months ahead of time, actually get a better idea of what it’s going to be like?’” he concludes. “We now have the capability to actually shrink the time frame from when the customer has the conception to do something to actually show them something tangible.”
Analysts aren’t completely convinced, of course. Or—to put it another way—industry watchers inevitably urge restraint when it comes to assessing both the promise and the potential pitfalls of EII. Take Mike Schiff, a principal with data warehousing consultancy MAS Strategies and a member of TDWI’s extended research collaborative. There’s a lot to be said for tapping EII to help prototype a proposed data warehouse, Schiff says, or even to model (in the most nonchalant sense of the word) proposed data warehouse changes.
“EII can also be used by IT to produce ‘quick-and-dirty’ prototype reports for the business community and, if [EII prototyping shows that] the report is requested on a regular basis, then [data warehouse administrators can decide] to load—and rigorously cleanse—the required data into a data warehouse,” Schiff writes.
He’d like to stop there, Schiff says, but the danger of EII is that it tempts proponents, and potentially adopters, to ever more ambitious designs. In this respect, Schiff cautions, adopters must avoid the very natural temptation to deploy EII as a quick-easy-and-painless data warehouse replacement—in other words, as a virtual data warehouse, the age-old pipedream that simply won’t die.
Phil Russom, TDWI’s senior manager of research and services, and a close watcher of the data integration space, elaborates on these themes.
“Users have for decades applied EII-ish capabilities to BI, not just those of enterprise reporting platforms [like MicroStrategy’s Villani has in mind] but also database views, as in materialized views [Oracle], materialized query tables [DB2], linked servers [SQLServer], and so on,” Russom points out. “And these are today still a part of the mix in a well developed BI environment, not as disposable prototypes, but as permanent fixtures. Whether real EII—as seen in modern tools from Composite, Ipedo, Metamatrix—or EII-ish capabilities of other platforms [such as report platforms or databases], these things have a place.”
Russom isn’t quite as sold on the idea of data warehouse prototyping as Schiff. On paper, he concedes, the idea makes sense. In practice, however, the prototypes of today all too frequently become the we-started-using-it-and-couldn’t-afford-to-back-out-of-using-it mission critical applications of tomorrow.
“[As an analyst at] Giga and Forrester, I handled hundreds of inquiries, and a common background comment from a user would be ‘We cobbled together a prototype to prove that our concept is sound, but the prototype works okay, so our management will not let us start over and build a solution based on what we learned.’ So, even if you intend to dispose of a prototype properly, your management may allow you the time and expense. As a Russian friend of mine says: ‘There’s nothing more permanent than a temporary solution.’”
About the Author
Stephen Swoyer is a Nashville, TN-based freelance journalist who writes about technology.