QlikView is for sure an interesting tool, which, as any other BI platform, has its own area of applicability. The goal of this post is to examine some popular myths about QlikView and help those who are choosing BI platform and considering QlikView. At the end of the day, the less is disappointment from unrealized expectations -- the higher is satisfaction.
Myth1 #1: QlikView is extremely fast
This is true -- QV is indeed very fast. Its in-memory engine, which stores all data in RAM indexed and compressed, eliminates slow disk I/O operations and therefore all selections and filters are processed extremely fast. Not to forget to mention high utilization of multi-core CPU architectures and not so widely known QlikView's feature -- precompilation of selections.
At the same time, as data volume becomes larger the response time increases proportionally. However, QlikView can't scale horizontally and split processing of a query to several nodes (thus reducing query time inversely to number of nodes). At the same time, relational analytic DMBSs with horizontally scalable MPP architecture can achieve similar to QlikView response times on relatively large data sets ( >1bln. of rows ). One of my customers has got similar response times for QlikView on 64GB server and two-node Vertica cluster (32GB each node) for 200GB data set.
Myth #2: Rollout time for QV is weeks not months
This is also true. Due to absence of sophisticated metadata layer and use of automatically pre-joined tables (so called associative model) developing not complex analytic applications is fast and easy. 1-2 weeks from requirements specification to first working prototype is not a nonsense. Good set of charts with very flexible expressions engine also make life easier.
However this has its back side of the moon. Primitive metadata layer means that you wouldn't be able to operate with hundreds of measures and dimensions in one model. At the same time QlikView combines cumbersome and overloaded forms for object properties with surprising inability to easily adjust basic visual settings like background color or font size of a table header row. For me QlikView is the first BI tool where I can spend more time adjusting visual appearance of a report than building a data model for it. I wonder -- is it really necessary to have a separate checkbox (!) for rainbow-colored borders (see the screenshot below) when it's not possible to easily adjust the above-mentioned basic visual settings?
Myth #3: With QlikView you don't need a Data Warehouse
Well, if you don't need data warehouse with QlikView then most probably you don't need it in any case. In another words -- for the majority of cases this is not true. First, QlikView by design deals with star-schema models only. Second, volume of data stored in QlikView is strictly limited by RAM capacity. Even with typical compression rate 1:3 this may very soon become an obstacle. Third, despite QlikView has its own ETL engine its data cleansing possibilities are very basic. So in case of need for good data quality processing a dedicated ETL/DQ tool will be necessary. Forth, the mentioned above lack of good metadata model limits capabilities for metadata management, lineage and impact analysis.
At the same time, good fit for star-schemes, fast response time and quick prototyping make QlikView very attractive choice for data marts built over a corporate data warehouses. Not to forget QV's wonderful capability to merge Excel spreadsheets and text files with data from RDBMSs in a few mouse clicks which makes enhancing DWH data with Excel data very easy for non-technical users -- an important use case. (UPDATE 23/6/2015 - with my new ETL tool EasyMorph you can do it even easier).
Myth #4: QlikView is an enterprise BI platform
Briefly -- no, it's not. While QlikView is a very advanced dashboarding tool with some nice query & analysis capabilities it wouldn't cover the needs for heavy reporting, ad hoc analysis across hundreds of measures and dimensions, balanced scorecarding, data mining etc. which a large enterprise might have. Lack of single, easy manageable and scalable security model also limits areas of applicability for QlikView. Currently, in order to manage user access rights one should set them up in 4 (!) places -- load script, document properties, visual object properties and QlikView Publisher. While it's more or less bearable for 50-100 users, I guess you wouldn't want to go through all of this for a few thousands of users.
Myth #5: QlikView is inexpensive
As of price-list, QlikTech offers a pricing model which is rather attractive for small businesses when compared to offerings from its larger rivals -- IBM, Oracle or SAP. However, when it comes to larger deployments, the difference in cost per user becomes smaller and sometimes not in favor of QlikTech.
According to Gartner:
"QlikView is increasingly seen as expensive — almost a third of its customers surveyed (31.4% vs. 26.1% in the whole sample) see this as its main barrier to wider use. Its pricing model often does not sit well with larger deployments to more users, nor does the investment in RAM required to support the increasing numbers of concurrent users." (Gartner's MQ for BI platforms 2011)At this point you might think that QlikView isn't worth its money. Well, while QlikView is definitely not what QlikTech's marketing propaganda is trying to tell us, it's still worth consideration. Short time-to-production, good capabilities for data manipulations by non-technical users, very interactive point-and-click user interface and high-speed query processing -- all of these can definitely make QlikView a good fit for some people in your organization.
Read also: Really, is QlikView a BI tool?
