This Tuesday the QlikView Business Discovery World Tour pulled into London town. With no new QlikView version immediately available and attendees who almost universally seemed to be existing QlikView devotees there was perhaps a feeling that the event lacked purpose. But there was one big reveal.
The first session opening with ‘street’ style dancers performing to a slightly bemused room did little to raise the expectations. Fortunately a keynote address by Wired editor David Rowan on ‘future predictions’ gave some good food for thought and set the scene well for looking forward to the future of QlikView.
Donald Farmer was, naturally, the person to deliver this and unsurprisingly the focus was the themes of QlikView.next. My thoughts on the future platform were captured in the blog post Whatever .Next, and remain largely unchanged. There are however a couple of points I want to look at here.
A video presentation of what .Next could potentially look like showed elements being dragged from a repository and automatically positioning themselves on a web page. The repository functionality is in no way new – but I don’t think it has been given this level of exposure before. The line between the developer and business user is being further blurred (part of the Consumerisation of IT theme, I guess). My big concern with this is that many QlikView applications have data model designs that are so flawed that encouraging users to drag and drop dimensions is likely to cause incorrect analysis and even server strain if non related dimensions are used in the same object. I’ve blogged quit a bit on Good Data Model Design and it now seems more important than ever to get this absolutely right.
Another drive in .Next is towards further collaboration and sharing. This is all well and good – but the type of features being discussed were rolled out with QlikView 11 and as far as I am aware remain largely unused. I have quite a number of Version 11 clients and as yet have not left a note that doesn’t say “This is a note” or shared my session with anyone who could not physically reach my mouse if they wanted to. Perhaps I am behind the curve here? Who knows, perhaps these features will become compulsive to use as new users discover QlikView and these features are to them as much a part of the product as List Boxes are to us seasoned users.
Thinking of it as I write now – maybe the thing I am noticing is the continuing divergence of the marketing spin of QlikView to the way that it is being used at the coal face by the majority of users?
This leads nicely to my next point – what I saw as the big reveal. With all the talk of the way things are headed in the future – the now (well, two months hence) was only given a casual mention. Direct Discovery is a feature that is arriving with QlikView 11.2 in December (now in beta). What this feature will allow you to do is fire a new data retrieval query off to a data source as user’s selections change. This could be data from a source with far too many values to hold in memory, to drop a buzz-word, Big Data. An example was given in the Google Big Query session where data from every UK hospital admission and prescription for the last four years was queried using this functionality – and still felt as natural and responsive as using QlikView on an in memory source (this demo was implemented on QV11.0 with extensions – but we were advised QV11.2′s native functionality will be very similar). The ability to chart and analyse on aggregated data then drill down and reach out to retrieve row level information with notes fields previously never pulled into QlikView is something I can see delivering real value right now. In fact, I have clients that will be wanting to get this working almost straight away. The fact that talk of 11.2 and Direct Discovery was only briefly touched on seems strange to me.
The version number move to 11.2 rather than 11.5 seems to me to be allowing space for more non .Next releases (as version 8.0 went to 8.5) so this may say something about when we can expect to start seeing .Next appearing.