Columns

Disposable data marts?

• By Tony Baer
• June 26, 2001

Must every information technology system be built to last? At first glance, posing that question to a CFO might seem like a career-limiting move. But, if the project at stake is a data mart, look very serious and determined, and then reiterate the question. Maybe, just maybe, you might convince your CFO that you're onto something.

First, you will have to dig yourself out of the rhetorical hole you've just created. Look at who uses data marts -- business and finance -- and why, and then note that their needs differ markedly. Financial organizations require budgeting and forecasting tools to analyze expenses and profitability, using apples-to-apples comparisons between different quarters. Better build lasting data mart infrastructures here.

But for sales and marketing groups, the answers could be quite different. Remember, these are the folks who wear the loudest ties and are paid to think "outside of the box." These people are hired not for their consistency, but for their insights into attacking markets. If the market is changing, does it make sense to conduct analyses with last year's benchmarks? In a presentation at the TDWI conference last summer, a speaker from MCI described a fast-and-loose data mart strategy: Create marts that solve pressing marketing questions immediately, then move on. The rationale is that, in a field as volatile as telecommunications, who knows what the market will look like next month. Or, in MCI's case, who would eventually buy the company.

As noted in our May feature ["Who's minding the meta data?," p. 39], MCI uses an enterprise data mart strategy that provides the solid, back-end infrastructure to generate marts fairly quickly. Behind all of those perishable data marts is a huge enterprise warehouse and a meta data repository that avoids the need to reinvent the wheel each time a new mart is rolled out.

However, most organizations don't have the patience or budget to build sophisticated, back-end, terabyte warehouse infrastructures. Until now, building marts without solid back ends was considered shortsighted. But with Microsoft about to make Olap so cheap [see "Plato vs. the republic"], could that legitimize such strategies?

Maybe eventually. For now, behind every Olap cube there remains nothing but the grunt work of building the extraction routines that load and periodically refresh the mart. Throwing Olap in gratis won't change this equation immediately, especially if the source data comes from a virtual mishmash of poorly documented legacy systems.

But what about all those fresh, new enterprise resource planning (ERP) systems, where the source of the data, and the quality and consistency of the content, are already known quantities? Even with current applications, such as SAP's R/3, it still takes lots of tape and baling wire.

Not surprisingly, the SAPs and PeopleSofts of the world are packaging their own data warehouses as add-on modules, while integrators such as Hewlett-Packard are building their own ERP data mart practices. On the surface, an ERP data warehouse should be as easy to package as ERP itself. The notion of the data warehouse as a package has spread to Oracle, which has developed a canned sales and marketing data mart, as well as to Arbor and Hyperion, firms that are merging to make data marts an applications business.

In fact, packaged data marts should be perfectly fine for firms that get by with canned reports. For the enterprise whose market dynamics are constantly in flux, however, canned decision support is as useful as last year's competitive analysis before your rivals merged or were acquired, or before your product added new features that opened new potential customer bases.

In the long run, that's where "el cheapo" Olap -- à la Microsoft's Plato -- will fit in. The idea is to make Olap so inexpensive that organizations can "just do it." These disposable marts won't be the last word in decision support. Instead, they'll be the first.

But Plato alone won't do it. Just as Microsoft's Access or SQL Server are just databases that require data models and Visual Basic front-end applications to make them useful, Plato will require a new breed of tools for the back end to do what Crystal Reports did for the front. Namely, build tools that power users can use to quickly create Olap cubes from scratch. Then, your company can rapidly build disposable marts to generate quick answers to new product marketing issues. More importantly, in the future, the person who asks the question of why information technology systems must last may be none other than the CFO.