News

The Next Front in the Build-vs.-Buy BI Debate

• By Stephen Swoyer
• August 10, 2005

Owing to a variety of factors, enterprises will increasingly give up their homegrown ETL solutions in favor of more sophisticated commercial ETL packages.

Right now, many organizations migrate from homegrown operational reporting or business analytics to commercial BI solutions, bringing their ad hoc ETL tools with them. In some instances, there’s little incentive for them to do otherwise: Even in cases where organizations need to reformat source data—in other words, the T part of the ETL acronym—their requirements are often relatively simple (converting text to numeric, text to date, or merging two or more fields and concatenating names), and can be accomplished by scripting.

This will almost certainly remain the case in many companies. After all, even for more complicated transformations (looking up data in another table and replacing it, splitting one field into many), many developers opt to use scripting, programmatic SQL or some combination.

That was the case with PerkinElmer, a health sciences research, development and manufacturing company that recently transitioned from a mostly home-cooked BI stew to a shrink-wrapped BI suite from Business Objects SA. For the present, says Bernie Kalmbach, PerkinElmer’s director of IT, ad hoc ETL is an at least functional solution, given the kinds of data integration issues his company is trying to solve. “We’re able to get by with it,” he deadpans.

PerkinElmer CIO Matthew Datillo, for his part, says he feels Kalmbach’s pain. “I think ETL is something that Bernie and his team would love to have, but we just can’t justify the cost at the moment,” Datillo concludes. Barring a Business Objects, Oracle or another vendor deciding to give away its ETL technology—Datillo and Kalmbach say PerkinElmer will remain an ad hoc ETL shop for the foreseeable future.

Datillo has a point about cost. Enterprise ETL tools from market leaders such as Informatica, SAS and the former Ascential Software Corp. (acquired by IBM) are highly complex software deliverables, and they’re priced accordingly.

In addition, each of these tools presupposes some degree of familiarity or expertise with their respective (and often highly idiosyncratic) programming conventions. Ad hoc ETL, on the other hand, is invariably premised on the coding strengths (Oracle’s PL SQL or Microsoft’s T-SQL; Perl script or VBScript; Java or C#) already present in an organization.

Enterprise ETL tools do boast connectivity into a dizzying array of different data sources. And, having covered most of their bases in terms of data-source connectivity and service enablement, the market leaders are increasingly focusing on ease of use. The idea, these vendors say, is to bring ETL programming down from the mountain, such that the unlearned (enterprise programmers, IT managers and business power users) can use their tools.

This is welcome news to the PerkinElmers of the world, which have an avowed interest in shrink-wrapped ETL. Nevertheless, Kalmbach (and probably many of his peers) would like to see ETL market leaders focus on another issue, too. “[An enterprise ETL tool is] something we’d like to have, no doubt about it,” Kalmbach says. “Now if we could just get [the ETL vendors] to lower their prices.”