The way QlikView has evolved, it has become much more than a data visualization tool. It has become almost an application development platform. All of us have used QlikView to do application things - show/hide objects, run macros, actions, etc. - and have built some excellent applications for our customers. But was this the right thing to be doing? Did we do it in QlikView because it was the right place to do it, or because we could and QlikView made it easy for us to do?
Let's think for a minute about the strengths of QlikView 11. For me, they are:
- A really good ETL script to allow us take data from lots of different places and combine them in different ways - including using best practice dimensional modelling.
- A best of breed analytics engine that calculates fantastically well across large data sets.
- Associative logic - the green, white and grey, awesome functionality for data discovery.
- A good (but not awesome) data visualization tool.
The first 3 are, for me, the magic that makes QlikView the fantastic tool that it is, the one that really differentiates it from its competitors.
You will notice that I don't mention "application building" as a strength in QlikView - that's because it isn't a strength. If I want to build an application, I will use Visual Studio, JDeveloper, or even Notepad++, but I am not going to use QlikView. If I want something that is going to have application functionality - like writing to a database for example - I am not going to think of using QlikView for that, even if I could hack something together.
I can include QlikView data in another application, and I have built several such applications. I can also create an application inside of QlikView using an extension. I can do both of these even easier in QlikView.next, but still using my usual application building tools.
So, from my point of view, QlikView.next still has all of the great things that QlikView 11 has - except it is even better as it now is an AWESOME data visualization tool, one that business users will love using.
I think that for new customers, this will be fantastic. I think that they will start out building QlikViews that are designed around data discovery and their users will love it.
For existing customers, there is a different perspective. Many will have invested a lot of money in building what they have. My thinking is that it is an excellent opportunity for them to evaluate what they have done and revisit the design decisions that were made to see that they can do it better - while knowing that their existing platform will be supported for several years to come.
I think that if you look at the beta (note *beta* - not shipping product) and dismiss it because it can't do this or can't do that, then you might be missing a trick. Think instead of what you can do - there is a wonderful world of opportunity opening.
Stephen Redmond is author of QlikView Server and Publisher and the QlikView for Developer's Cookbook
He is CTO of CapricornVentis a QlikView Elite Partner. We are always looking for the right people to join our team.
Follow me on Twitter: @stephencredmond
I like your perspective, Steve! It is easier to get involved in micro, feature based comparison rather than looking at a bigger picture.. I think QlikView's best days are ahead with this major release.ReplyDelete
Hiii Steve, I must first of all appreciate the wonderfull efforts put in writing this concise information on Qlikview.next. I found it really informative. I have a blog and videos related with Qlikview. You are requested to go through it and kindly share your valuable feedback.ReplyDelete
Well articulated. I often see people stuffing QlikView into a box it should not be in. It seems QlikView is taking a step away from that which helps focus the core competencies of the platform that you mentioned.
When we talk about "missing features" in the new product, we should be sure we are only focusing on features that add analytical currency for the user or as QlikView puts it, "Does this feature enhance Business Discovery?"
We need to be careful how we define ETL as I wouldn't class Qlikview as having true ETL capabilities, otherwise why would Qlik have purchased Expressor?ReplyDelete
QLikview has a powerful scripting language which can provide some form of data transformation, but it can be cumbersome and not as seamless as standalone ETL tools such as Expressor, ETL-TOOLS etc