Since its founding in 1994, Qlik has believed that a business could improve its processes and product quality by empowering employees and encouraging them to engage in lifelong learning. And Qlik meant all employees—we saw everyone as a decision-maker, not just managers.

Although some things have changed since then, much remains the same. Users are still often in a situation where they are unable to analyze their data—data that they have the right to see, or should have the right to see, in order to do a good job. Rigid systems, technical limitations, and poor user interfaces are usually the culprits.

However, people's expectations of software have changed dramatically during the last decade. Applications from Google and Apple invite users to interact with simple, friendly interfaces. Search bars, Like buttons, and touchscreens have transformed the way people explore, consume, and share information. Today, people want the same ease of use from their business tools as they get from their consumer tools at home.

The current trends such as the consumerization of software, performance improvements of hardware, usability improvements of software, mobile devices, social networks, and so on just accelerate this change. All these trends are reshaping user behavior. Yesterday, a user was a passive end user, but the user of tomorrow will be both able and demanding. They will demand tools that are fast, flexible, and dynamic. They will demand tools that they can use themselves. The empowered user is here to stay.

The classic picture of business intelligence is that the user has one or several questions, and that the data holds the answers. So the problem boils down to creating a tool where the user can enter their questions, and the tool can return the answers.

However, this picture is incorrect. The truth is that the user does not always know the question initially. Or rather, if the user knows the question, they often already know the answer. So, the first thing the tool should do is help the user find the questions.

Finding the questions is a process that involves exploring the data. It involves testing what you suspect but don't know for sure. It also involves discovering new facts. Further, it involves playing with data, turning it around, scrutinizing the facts, and formulating a possible question. You use your gut feeling as a source of ideas and use the data to refine the ideas into knowledge; or to discard the ideas, if facts show that the ideas are wrong. You need to be able to play with the data, to turn facts around and look at them from different angles before you can say that you understand the data, and you need to understand the data before you can talk smartly about it.

When you have found a relevant question, you also need to be able to conduct an analysis to get a well-founded answer to the question.

Finally, the process involves presenting the answer to the question to other people as a basis for a decision or an action. The tool must support the entire process of going from ignorance to insight.

Hence, one major difference between data discovery and the more old-fashioned tools is that data discovery software supports the entire process—the process of coming from a blank mind, not knowing what you are looking for, all the way to attaining knowledge and taking action.

This is what data discovery is all about—helping you to prepare before you speak, act, or make a decision. It is the process of going from the darkness to the light, from the unknown to the known, from ignorance to insight. It is the process of going all the way from a blank mind to a substantiated argument.

It is quite clear that users representing the business want the ability to ask and answer questions on their own so that they can make better decisions, but traditional business intelligence solutions aren't well suited for user demands. Instead, it is common that the systems are created in a report-centric manner, where governance and system demands set the goals, rather than user demands. The solutions often have preconfigured dashboards, fixed drill-down paths, predefined queries, predefined views, and very little flexibility.

With traditional BI, the creation of the business intelligence solution often belongs to the IT organization, which has to do the following: create data models, establish a semantic layer, build reports and dashboards, and protect and control the data. Often, the creation of business intelligence solutions is not driven by user demands. The following figure depicts the traditional BI architecture:

When analyzing data, you might want to set filters so that you can make selections, but with traditional tools, you often need to start at the top of predefined hierarchies. So, instead of selecting a customer directly, you may need to answer this question, "Which market does this customer belong to?", then the country the customer belongs to, and only then can you specify the customer.

Further, in the drill-down hierarchy, you are often limited to the choice of one or all. For example, you can look at either a single customer or all of them. The possibility of choosing two or three specific customers doesn't exist, unless this has been specifically predefined by the data model developer.

Numbers are often precalculated to ensure short response times, but this has a drawback that if the developer hasn't anticipated a specific calculation, the tool will not be able to show it.

Further, the architecture of the tool is often made in three layers—referred as the stack. The first layer is the Extract, Transform, Load (ETL) layer, or the data load layer. The second is the Data Store / Engine layer, and the third is the User Interface (UI) layer. The three layers are different pieces of software, sometimes delivered by different software vendors.

These three layers also demand different skill sets. Often, the ETL expert knows little or nothing about the UI software, and the UI expert knows little or nothing about the ETL.

The product stack in traditional BI

This architecture also leads to problems. When an application is built, the feedback comes from users trying to use the application. It could be that KPIs are incorrectly calculated or that dimensions or measures are missing. It could also mean that the user realizes that the initial requirements were incorrect or insufficient. The feedback could imply changes in the UI, or in the data model, or even in the ETL component.

This type of feedback is normal—it happens with all business intelligence tools. It only means that the development of applications is a process where you need to be agile and prepared. The expectation that you should be able to define an application completely and correctly prior to a prototype or an intermediate version is just unrealistic.

This is where the architecture leads to problems. In order for a project to be successful, you need to be able to implement change requests and new user demands with short notice, and this is extremely difficult since three different pieces of software and three different groups of people are involved. The distance between the user and the ETL component is just too great for efficient communication. Hence, the traditional architecture leads to a broken process.