May 4, 2012

Really, is QlikView a BI tool?

The more I work with QlikView the more I question myself -- really, is QlikView a BI tool? We all know that QlikTech markets QlikView as a BI tool, or, more precisely, the BI tool :). We know that Gartner, Forrester and many other analysts consider it as business intelligence application/platform and it looks like nobody questioned this fact (or did somebody?). But what if we look at it from a different angle.

Difference between QlikView and other BI tools is so vast that it makes any head-to-head comparison barely reasonable. In terms of classic BI, QlikView is rather limited -- no decent ad hoc Q&A, static reporting leaves a lot to be desired and drill-down is nothing but a joke here. BI with poor drill-down? You must be kidding me.

Let's look from the other side -- traditional BI suites usually offer rigid and often counter-intuitive UI which requires week of training just to get started. They inherit all curses of SQL, can't boast with more or less powerful expression syntax, comparable with Excel (which is crucial for anything that calls itself "analytic"), and actually are nothing more than just a visual front-end for databases. Okay, with some trendy smart caching added recently.

Not that the difference wasn't obvious earlier -- the same year when Gartner praised QlikView, they  coined term "Data discovery" as the market niche for QlikView and some other tools. While it's not the best term in general (didn't traditional BI tools do a data discovery, at the end of the day?), due to intention to fit QlikView into existing BI landscape, I suppose one important point has been missed -- QlikView's superior user interface customization capabilities, which actually make it a "Lego for analytical applications". Let's elaborate on this a bit more.

Every application designer (we're not talking about BI, but about software applications in general) knows that user interface is event-driven and the events are of 2 types: user-generated and application-generated. This is a known fact which eventually led to appearance of Model-View-Controller (MVC) application development pattern, where Views reflect Models and Controllers process events that make changes to Models and then Views. Lots of application are built using this pattern, especially web-applications (we're all going there, right?).

Traditional BI platforms don't fit into MVC concept. They offer developers models and views, but they don't offer controllers -- that's why they are just a fancy overpriced DB viewers. QlikView does. Poorly, but does. And that's the core difference between them -- with QlikView you build event-driven applications.

Poorly, because it looks like QlikTech people don't realize this consciously (otherwise they would make UI events as accessible objects and overall UI event management much more centralized, e.g. introduce global event dispatchers). But what they do fits MVC approach quite well, even if they never thought about it this way. Object extensions and recently introduced document extensions reinforce need for MVC-based design even more, because extensions actually are controllers (sometimes with own views).

Therefore, in my opinion, QlikView belongs to a separate class of analytical applications. I have no idea how to call them correctly (definitely not "AA Lego") but that's for sure not "Business Intelligence" as we know it. May be QlikView is only one representative of this class, may be not, I don't know. But that doesn't matter -- I'm sure that sooner or later there will be other players, and maybe someone will do it better than QlikView (it might be not that hard).

Do you know any other analytical application development tool/platform/suite that fits this class? I would appreciate to hear your comments on that.

Read also Busting 5 myths about QlikView.

UPDATE (2012-May-6):

As this blog caused a lot of confusion for my fellow colleagues and criticism, I suppose I need to bring some clarity into it:

  1. I've updated pictures -- now they visually show difference between traditional BI architecture and QlikView's one. This difference is the ground for the claim that QlikView is a different animal.
  2. QlikView does utilize MVC-pattern. For instance, there are triggers that can cause various actions, including calls of Visual Basic macros. However, I would love to see, for instance, centralized event dispatching and custom events, unified across QV's native and non-native UI objects.
  3. My belief is that more conscious following to MVC-pattern would eventually lead to analytical applications that look more like industry-specific and tailor-made, than customized out-of-the-box, which would give more value to customers. Kudos to Roman for mentioning SAS, which is famous for its industry-specific analytical applications. By the way: 1) SAS usually isn't considered as BI, 2) SAS collects more money than any BI vendor which may be an evidence of higher added value provided.
  4. I like QlikView :) In my opinion BI industry is stagnating, so being "not BI" is actually a compliment here.
My apologies, if something in this blog sounded offensive.


I've posted on QlikCommunity an Idea "Custom events for UI and global event dispatcher". Feel free to upvote it if you like it.