QlikView's Rapid Time dash to dash Implementation Improves Business Intelligence Value
QlikTech believes its QlikView product will benefit disproportionately from a projected surge in BI spending
- By Stephen Swoyer
- December 10, 2008
Despite a global economy in turmoil and business and IT-related business spending in question, Anthony Deighton, senior vice president of marketing with business intelligence (BI) pure-play QlikTech International Inc., says he wouldn't have it any other way.
Deighton, whose company markets a BI product called QlikView, says the economic-boom-cum-bust will force many companies to slash spending.
At the same time, he argues, it creates a climate in which savvy companies will funnel or redirect existing spending (or adjusted spending) into new revenue-generating efforts. Few efforts have more ROI-related cachet than BI, Deighton argues.
What's really at issue, he says, is which vendors are going to reap the benefits of a (still-hypothetical) surge in BI-related spending. Will it be established BI vendors (the BI elite, if you will), or will a new, upstart class of BI players -- represented, Deighton argues, by QlikView and others -- snag a disproportionate share of the spoils?
Deighton, not surprisingly, likes the second proposition. The BI elite has had its shot, he argues. Few would deny that traditional BI has been successful in practice; likewise, Deighton contends, few would deny that traditional BI typically comes at a price -- chiefly in the form of long implementation times and higher project costs. The latter, Deighton argues, is basically a function of long implementation times: traditional BI almost always entails a sizeable services commitment, ostensibly to help grease the skids for implementation.
It's for this reason Deighton contends that the QlikView model -- which promises rapid (days or just a few weeks) implementation times and a negligible or nonexistent services component -- is poised to benefit disproportionately from 2009's projected BI spending stimulus.
"As the economy is in trouble, a lot of our customers are looking at the IT projects that they have out there and are saying, 'Which one of these is going to deliver value quickly? Which one of these is going to be deployed quickly? [Which of these is] something that people can use?' Long, multi-month -- what I like to call 'intergalactic' -- IT projects are falling on hard times," he observes.
Intergalactic IT projects are passé, Deighton continues, not just because of their protracted time to return value but because of their exorbitant costs.
"If you take the [SEC] 10K [filings] of all of our competitors, even when they were [BI] independents, every one of them had services revenues that were greater than 50 percent of their total revenue. Every one of them. The real question is, if I'm running Cognos and I just developed a product that's so quick and easy [to deploy] that it only lets me [derive] 5 percent of my revenues from services, would I ever allow that product to go to market? Never," he contends.
"That's the real issue. The traditional BI vendors have a model that is a services-based model. I'd say that hasn't changed with the acquisitions [by Oracle, SAP, and IBM]. Their model is built on the idea that people will have this long-winded services-based approach to building BI, and that's something that [in the current economic climate] customers just don't have the patience for."
It's a tendentious argument. But these are tendentious times, says Deighton. QlikView claims a rapid time-to-implementation because it's an in-memory technology. The typical QlikView implementation scenario smacks of the agile approach to software development: IT starts by immediately loading data into QlikView; data management groups don't first develop data models or build cubes, Deighton maintains.
"We hold all the data in memory at all times. This eliminates the need to build the cube and reduces the time it takes to deploy the solution," he explains. "The kind of analysis that you do depends more on the kinds of questions that you want to ask and less on having to prebuild the cubes."
The agile parallel is strongest on the customer side. Like agile programmers -- who regularly meet with business customers to both test an application's progress and to evolve that application (chiefly in response to feedback from customers) -- IT starts by letting BI end users simply bang away at QlikView.
"We work the way your mind works. It doesn't matter if you get the thing perfect the first time. Let your mind go the way it wants and ask the questions that you want to ask. Your can customize [QlikView] based on the kinds of questions, the kinds of analysis, that [your users] want to do," Deighton says.
He contrasts this with what he dismissively calls "traditional BI" -- an approach that (to again invoke a comparison to agile software development) smacks of the conventional "waterfall" approach to application development.
"With QlikView, because it has this high-velocity cycle time, you can change it that week -- or maybe even that hour. The user could say 'I'd really like to be able to do it this way.' Life and business aren't static. It's a fallacy to say if you just got the requirements right the first time out, you could build everything just right in a traditional BI tool. As soon as you have [the finished product] deployed, the requirements change. It's inevitable. It happens every time."
QlikView's adaptability is a function of its in-memory underpinnings, Deighton maintains. "Traditional business intelligence was designed 20 years ago … when memory was very expensive and processors were very slow. The way people achieved multidimensional analysis is that they would prefix the analysis and store it on disk in a structure that was referred to as a cube. This idea of building cubes was a very good one 20 years ago, but it had some negative results -- the most obvious of which is that you had to think about the kind of analysis you were going to do prior to building the cubes. That isn't an issue with in-memory."
If that's the case, however, can't IBM-Cognos -- which claims a best-in-class in-memory OLAP technology of its own, thanks to its acquisition 14 months ago of the former Applix Inc. -- and a few other players (such as Oracle) claim technological parity? If an in-memory capability is the chief ingredient of a rapid time-to-implementation, and if IBM, Oracle, and others now tout in-memory capabilities, mustn't QlikView concede the point?
Deighton demurs, suggesting that the issue boils down to a couple of factors: a need to support both traditional, cube-based OLAP and in-memory capabilities and what he describes as a kind of internal bias (on the part of the BI powers-that-ee) against in-memory architectures.
"There are some very real technology differences between our approach and these [in-memory] competitors, the most important of which is that we always have operated from an in-memory perspective, so there's no debate in our R&D department [about which approach is better]. Whereas if you started from the perspective with a traditional OLAP approach and you layer on top of that [an] in-memory [capability], while that can't hurt, it [the in-memory feature] is always seen as the ugly stepchild, so that causes some challenges for them."
QlikTech recently celebrated its 10,000th QlikView customer. This summer, it announced version QlikView 8.5, with a version 9.0 release slated for next year. Deighton is optimistic that his company's growth -- QlikTech was recently recognized by services giant Deloitte LLP as one of the 500 fastest-growing technology companies (at number 235 on the list). The company likes to bill itself as the world's "fastest growing" BI vendor.
An economic crisis is just the kind of environment that can test QlikTech's mettle, however. More to the point, it's the kind of crucible in which the best-laid-business-plans of the big BI vendors -- which QlikTech claims are premised on the generation of sizeable chunks of services-related revenue -- are tested, found wanting, and refined. If that's the case, isn't it likely that traditionally hard-to-implement BI players will significantly deemphasize their services dependencies and get rapid time-to-implementation religion?
Notwithstanding Deighton's critique, don't most BI players already tout rapid (or increasingly diminishing) times-to-implementation? Deighton says it's possible -- but unlikely. Even the most optimistic time-to-implementation claims of competing BI platforms don't surpass those of QlikTech and QlikView, he argues.
QlikTech isn't sitting still. "We act paranoid and … it's actually our expectation that essentially everybody will copy us perfectly and execute perfectly. We're certainly prepared for that. We've been building this product since 1993. We have a fairly long and rich history of what we're doing here," he concludes. "We have features and even products in development which we will release over the coming five years which will significantly enhance and extend on our lead here. Our competitors certainly can't copy the business model and the trajectory we're on in terms of customer acquisitions."