Exploration views is exactly what its name suggests: instead of having just a single view of the data in Explorer as you have in the current product, you can set up several different views at the same time, with user-defined alerts, and the ability to define filters that act on multiple views at the same time.

Here’s a quick walk through of some of the basic functionality. For more information (and a longer, more complete explanation of the features), you should consult the Exploration Views prototype User and Admin Guide (part of the download from the SAP BusinessObjects Innovation Center)

You first log on to the system, then either open an existing Exploration View or create a new one:

Each view has several “sheets’”, and each sheet can contain several charts or tables of data. To create a new chart, I choose the measures, dimensions, and type of representation.

It immediately shows me the requested data set:

To create an additional chart, I simple repeat the process, dragging the chart icon from the toolbox to the right-hand window (above, below, left, or right of the existing chart), and choosing a different measure, dimension, and representation:

At any time, I can use the “Explore” link in the top right to change any aspect of a chart (data choice, formatting, etc.)

In addition to charts, I can define a table view of data, or a “filter control”. I can define a new filter control simply by dragging it to where I would like it to appear in the workspace and choosing a dimension and type:

I can also add personalized alerts by choosing one of the charts, and adding the alert details:

As I change the values chosen in the “Year” filter at the top, all the charts and alerts change to reflect this:

I can also use the top bar to access and change the global set of filters at any time, which change all the charts on the sheet by default (I can “lock” individual views so they don’t change, if necessary).

Once you have the view, you can hide the toolbox, and freely change the sizes of each pane of the window.

There are some lovely touches in the prototype – for example, it’s very easy to select a value (such as “Alberto Ascari”, above), and then simply drag it to create a new window focused on that single value (which can then be easily modified to change to a different view, include a different dimension, etc.):

Using these basic building blocks, business people can quickly provide a customized view of the data, then share it with others using the “share” button in the top right, which allows you to create a “bookmark” URL for your view and send it to others (subject to security settings).

Exploration Views is currently a prototype. SAP is taking a 2.0 approach to innovation, by providing early prototypes that can be downloaded and installed by anybody who is interested. Anybody who has feedback on the ideas and interfaces is encouraged to contact the Innovation Center team. Once the feedback has been gathered, SAP will then work out how best to include these features in future versions of the product.

I view the new Exploration Views prototype as element of the next leap forward in analytics, and it is different from existing approaches in two important ways:

1. Exploration Views is designed from the ground up to take advantage of the in-memory processing power of Explorer. As in-memory infrastructures become more widespread, there is less need to separate the “design” and “consumption” aspects of the data access. Because each change to the data view is more or less instantaneous, we can give more power to the users to customize and control their own view of the data, without having a separate, complex “design” interface.
2. Exploration Views are focused on personal customization, and should be considered a complement to existing approaches that provide a shared “dashboard” view of data.

I’ll explore these (important) themes in more detail in a future post.

The term OLAP or Online Analytic Processing was coined in 1993 by relational database technology pioneer Ted Codd (my claim to fame: we went to the same high school, Poole Grammar).

The term was chosen to contrast with OLTP or online transaction processing, and was prompted by some clever marketing folks at Essbase, who wanted to promote their multidimensional database product. Codd was famous for his twelve rules defining the relational model and duly came up with twelve rules for analytic systems.

The term was quickly taken up by the rest of the industry, and spawned new definitions (Nigel Pendse’s FASMI test) and multiple variations (MOLAP, HOLAP, ROLAP, Huey, Dewie and Louie, etc.).

Over time, these multiple definitions started muddying the meaning of the term (was it a technology? a user interface? an approach to analysis?), and Gartner decreed that it was ‘just’ part of a larger market called business intelligence. The result has been a long slow decline of the use of the term OLAP, as the Google Trends chart below indicates.

Only Nigel Pendse of the OLAP Report tried to side-step this trend, and continued producing OLAP-specific analysis for many years, but “business intelligence” was clearly the mainstream industry term. A few years ago, Nigel sold the OLAP Report to the German BARC group, who initially continued under the same name, and tried vainly to convince everybody that OLAP was still a “hip term”, but finally succumbed to the inevitable and announced last month that they would be changing the name of the report/site to The BI Verdict.

(Sadly, at some point in this process, BARC decided to lock one of Nigel’s best articles — “How not to buy a BI product” – behind their subscription firewall. All I can find on the web is a far-less-entertaining summary of the main points here. [UPDATE: thanks to a tip from Florian Bahr, I can point you to the full article on the WayBackMachine: How not to buy an OLAP product)

Since BARC were the last group using the term with any frequency, it’s now fairly safe to say that OLAP’s days are over, but interestingly, the group seems to have chosen to shift to the wrong term. The chart below shows that the search trend for “business intelligence” has been slowly drifting down over the last five years.

And the decline is even more pronounced for another standard industry term, “performance management”

Since BI and performance management remain fast-growing markets, this trend is a little surprising – until you look at the search figures for the term analytics. Starting in 2005 (perhaps prompted by the introduction of Google Analytics?), the term has skyrocketed in use.

Possible reasons for this may include:

• Popular books and articles aimed as business people tend to use the term, such as Thomas Davenport’s 2007 book “Competing on Analytics”. This is perhaps because there’s more ambiguity for a business audience, who associate the term “business intelligence” with industry data vendors like Reuters and Thomson (now both part of the same company).
• The acquisition of the mainstream BI vendors by larger organizations (Hyperion by Oracle, Cognos by IBM, and BusinessObjects by SAP) has meant that the industry has been increasingly using other, more generic terms, such as “embedded analytics” and “analytic applications” to explain the same functionality. And the largest remaining independent vendor, SAS, has proclaimed themselves the leader in “business analytics”

My conclusion? By the time you read this, this blog might well be called “Analytic Questions” instead of “BI Questions”…

Hasso Plattner, SAP’s co-founder, chairman, and “Chief Software Advisor” has been giving a series of talks including his keynote at SAPPHIRE 2009 on why in his view “disk has become yesterday’s tape”, and why column storage and in-memory techniques are the future for both data warehousing AND enterprise applications, displacing the 20-year reign of relational databases.

Experts have advocated column databases such as Sybase IQ and LucidDB for data warehousing for many years.

But now, based on research done at the his Institute (and a lifetime of trying to get the best performance possible for enterprise applications), Plattner is advocating basing both OLAP and OLTP systems on column storage in order to eliminate the need for the cumbersome ETL process, and reduce system complexity and the number of database tables.

More details are available in his white paper A Common Database Approach for OLAP and OLTP Using an In-Memory Column Database and a related presentation. The research was conducted using SAP’s TREX technology and real customer data (to see what the technology can do in a business intelligence context, check out SAP BusinessObjects Explorer).

Given that the vast majority of relational databases are used for OLTP transactions today, this would represent a radical change for the enterprise application market.

And although data warehousing will still need to exist, because of master-data management, data synchronization, data quality, etc., it would certainly be a lot simpler, and a lot faster, since much of it could be done directly on the “transactional” data source.

While nobody has promised that SAP will develop the concept as a product, Plattner has presented his views widely to SAP employees, and leaves no doubt that he thinks this is the way ahead.

Here’s the last slide of Hasso’s presentation at the recent SIGMOD 2009 conference for database researchers – this is  certainly something that we’ve been looking forward to for a while…