Slowly, more and more analyst firms and vendors draw a more differentiated picture and accept that there is a large range of user situations and needs which ask for a range of appropriate technical answers.

One of the most important goals of the data warehouse is to provide a single version of the information. In order to avoid potentially different data selections or transformations it would only be sensible to also have just one tool to access the single version of the information, eradicating the problem of different numbers for the same question once and for all. This might be the strongest motivation for BI professionals and business users who seek a universal BI end user tool that answers all business needs and widens the access bottle neck. The growing market opportunity for BI tools motivates the software vendors to promise technological breakthroughs and even miracles where required.

The challenge becomes apparent when taking a closer look at what different users need. At least three use cases need to be distinguished and give rise to different and conflicting software requirements:

• „Most data warehouses will probably form the basis for a stream of ready-made reports being send out to many users across the organisation. Usually no interactivity is provided with the reports and most users would more likely become confused by features allowing for customisation. What is needed are capabilities to automatically and repeatedly generate reports combining several tabular and graphical elements.
• „Senior management wants the convenience to oversee the entire business and drill down into subject areas when indicated. This need can be answered by information dashboards providing basic flexibility via an intuitive GUI. The bigger challenge here is to select and define the pieces of information to be displayed in line with the rest of the organisation.
• „Follow-up questions triggered by the two first user groups and all other analysis give rise to non-standard or ad hoc queries. They involve not only tools with full query flexibility but most importantly data analysis skills and knowledge of the data sources restricting these queries to a small minority of the users for most organisations.  Data warehouse thought leader Ralph Kimball wrote in 1998: “Ad hoc query tools, as powerful as they are, can only be effectively used and understood by about 10% of all the potential end users of a data warehouse. … The very best ROLAP-oriented ad hoc query tools improve the 10% number to perhaps 20%.” ^[1]
  Also data discovery tools, data mining workbenches and even plain SQL tools fall in this broad category.
  See also Stephen Few’s article Big BI is Stuck: Illustrated by SAP BusinessObjects Explorer (his Blog is highly recommended in general).

These three use cases could be further broken down, for example, by distinguishing between being OLAP focused or not, and vendors tend to showcase certain capabilities (such as data search) as constituting a whole new category.

It shows that a unified tool for all users and situations could probably only be developed at the expense of too many compromises and would probably satisfy no one in the end.

The even more utopian plan of BI delivery by pure self-service could only work with a complete data warehouse presented by a clearly documented user interface layer and in situations where queries are limited to simple look ups of stored facts. I’m not sure that the three conditions are fulfilled anywhere.

But from time to time one or more of these disposable graphs turn out to be nuggets — valuable discoveries or insight that deserve being shared with a wider audience. So the graph — say a histogram comparing numbers of contacts for a few segments — is already there. Capturing this by-product should not slow us down on our way towards the model we are heading for. Unfortunately the histogram’s layout, axes and captions are not in compliance with the visualisation standards and rules we have been preaching and teaching before^[2] . The histogram with tick marks for 0.8  1.8 and so on until 19.8 for these difficult to be more integer data is simply not presentation ready. Too bad.

Now starting up another tool reproducing the selection, the little transformation and the histo itself will likely take a few minutes and distract us from our core task, the model to be built.

So after all, we might be inclined to limit the celebration of the nugget to showing it to their colleague who happens to take a coffee 2 meters away. But anything more would be too much hassle and not as target oriented as we ought to be. At least as long as data mining suites and presentable graphics remain two different stories.

PS: This hold actually more for Clementine and KNIME which have the aspiration of being exhaustive and fully integrated. SAS will often require the use of two tools (Guide and Miner) anyway, depending on where the data come from.

[2] See for example http://www.perceptualedge.com/blog/ or various publications on data visualisation for guidelines how presentable graphs should look like.