Business intelligence or BI was initially meant to mean the applications that could be accessed by business users. However, the term has morphed into a catchall term which covers a variety of technologies which include reporting, OLAP, analytics, data mining, among others. The BI field is filled with different technologies and subdivisions, which makes it one of the more confusing software categories to drive to clarity on. This even complicated our software selection packages and software project planning analysis because while other software categories will have a single product name, most of the BI solutions offered are a variety of suites, with differently named suite applications.
The term BI had its origin in a 1958 paper by an IBM researcher where he employed the definition of intelligence. Therefore, it is data that leads to insight – which, of course, is an inclusive term. Everything that we now think of as BI has developed from that original idea, but it how encompasses specific types of applications. A BI application may or may not rely upon a data warehouse, and in fact, may rely upon a data source.
BI is one of the faster-growing categories of enterprise software. However, the growth is very different depending upon the category of BI software vendor. The large BI software vendors (Oracle, IBM, SAP and to a lesser extent Teradata) are seeing moderate growth, and with newer and more self-service software vendors (QlikView, Tableau, Birst) seeing very rapid growth. The growth leader currently is Tableau, an application that is quite deserving of this growth.
Our Approach to Analyzing BI
As part of our research process, we perform a literature review, which means reading the reports of other analysts. In these reports, we have noticed these use of many descriptors related to the data technologies employed. For instance, there is a lot of discussion of whether an application uses an in-memory database. For us, the particular approach used by the vendor is simply the input to the output of the analytics, reports, etc. There are software vendors like SAP and Oracle that are putting data into in-memory databases to make a splash at conferences, that don’t have anything to do with improving reporting outcomes. SAP has made a great deal of marketing noise about its HANA in-memory database while having one of the weakest overall BI platforms and while buyer after buyer complains to us about reports that are late or never appear. Therefore, our analysis does not spend much time quoting the underlying technology as this is, in our view, a distraction to presenting the analysis of how these applications perform in real environments.
Heavy Versus Light Solutions
There is a great deal of debate within the BI market as to which applications fit into which categories. If we got into all of the sub-areas of BI, we would have to explain statistical analysis tools, predictive analytics, data warehouses, etc. And so we needed some shorthand to categories BI solutions. Some applications pull from other data sources and do not offer a data warehouse. This means they cannot be compared in terms of price or broadness of functionality with tools that can pull from data sources by are not data warehouses. However, on the other hand – there is a debate as to how necessary a data warehouse is. We know many buyers for which a data warehouse is an overkill. The data warehouse philosophy has been prevalent for decades, but it generally did not lead to the availability of information that was predicted or promised. It essentially creates a heavy infrastructure load, which regardless of whether one is pro or anti data warehouse it is difficult to see how the following should not at least be acknowledged that
- The data warehouse was never able to achieve the productivity necessary to meet the promises that were made for the approach to managing data (now the debate begins as to why which is where all the arguments begin).
- Data warehousing projects are incredibly time-consuming and expensive.
- Many buyers have currently saddled data warehouse software and an overall set of BI applications that they are unwilling to staff sufficiently to get the value out of these platforms.
One of the tricks to getting a well priced and suitable performing overall BI solution find BI Heavy and BI Light applications that can work well together and that are efficient to run. This point is critical because so many BI Heavy applications or suites of applications are inefficient to run, and too many buyers end up with BI Heavy applications, which overwhelm their ability to support them. (Our estimations for resourcing BI Heavy applications/platforms are significantly higher both for support as well as for the implementation over BI Light applications/platforms)
Debates on the topic of data warehousing are eerily similar to a group of people who have a great deal of their career invested in philosophy and are reticent to admit that it has not done what it said it was going to do. Centralized “single source of truth” data warehousing indeed makes sense as a principle, but technology merits are not the only thing that counts. Data warehousing also means getting agreement from many different entities in companies that are self-centred and can easily lead to a tragedy of the commons – which as much as technology is why data marts became prominent. Furthermore, an Inmonesque data warehouse is a high standard requiring a high level of planning and discipline, and not every buyer is up to the task. These factors, which goto the limitation of the Inmonesque data warehouse was behind the growth of several areas in BI, including the analytics appliances like Exadata and Netezza.
Because we cover so many areas in enterprise software, we can see similarities in the argumentation over various technology debates, and other areas such as service-oriented architecture (SOA). This was heavily hyped and did not have any impact on how IT. This is the strong tendency ever to declare any approach to be invalid or flawed, and in particular, companies that have a revenue stream, which is derived from one, or another approach will never admit that approach has not worked. They will argue instead that the approach has not been implemented correctly – and this can go on for decades. We refer to this as the Evergreen Syndrome. That is no IT idea – if it is profitable for some parties — ever dies, it naturally fades from view.
BI Becomes More Responsive
In the last few years, and for probably the first time as a broad trend (one of the historical exceptions being Crystal Reports), software vendors have developed applications that are just as focused on ease of use as the technology. Before this, BI vendors have been developing challenge to use products, and then buyers have been wondering why they have low report development productivity and low user adoption and satisfaction. This shows in which BI software vendors can satisfy buyers. The prominent software vendors with “complete” solutions like Microsoft SQL Server, SAS, SAP, Oracle and IBM all score poorly in satisfaction. This leads to a critical point.
There is No Single BI Vendor which is a One-Stop-Shop
For many years, having a complete solution has been presented as a reason to by from one vendor over another. These software vendors have made large numbers of acquisitions and attempted to integrate these various technologies into a coherent offering – and it has not worked. The BI Heavy vendors that offer “total solutions” such as IBM, SAP, MicroStrategy are overbearing in their insistence that their solutions be used in their entirety. They declare their unwillingness to be used in conjunction with other applications that are all, of course, inferior to theirs. Buyers that engage any of these vendors will be beset by condescending BI consultants and sales reps that will drone on – in a difficult to monotone and interrupt manner about how their solutions have been designed from the ground up to work as a complete suite. Except for just a few vendors like Actuate and SAS, the other BI Heavy vendors are intent on employing account control techniques to take over a buyers’ overall BI spend.
The logic for attempting to find a one-stop-shop is not there. All of the BI Light software vendors can connect to any data source. And software vendors that propose they are providing some primary value add by combining front and back end BI elements to buyers are practising make-believe. They are cutting off options for the buyer under the rubric of “adding value.” This is why buyers should not attempt to get all of their BI needs from a single vendor. The more significant BI vendors as a group have a long history of misrepresenting how much training and effort is required to use their applications effectively. This is a feature that generalizes across enterprise software categories, but it has been a particularly problematic issue large vendor BI.
Heavy and Light BI
There are a variety of terms that are often used to describe different categories of applications in the BI software category. However, we categorize all BI solutions as either “BI Heavy” or “BI Light.” In many cases, the BI Heavy solutions contain a data warehouse. Below we have assigned each vendor that we have classified as one of the other.
Beyond this simple graphic, there are still important distinctions between the applications. For instance, some vendors like Teradata, which makes one of the most heavy-duty data warehouses would debate if other software vendors that we designate as BI Heavy should be categorized as such, so there is a level of debate even among this basic segmentation. BI tends to be a contentious software category with many firmly held opinions. For decades there was a sharp disagreement between two different philosophies of data warehousing called the Inmon (Corporate Information Factory and Top-Down) versus Kimball-Bottom Up debate (hint the Kimball data mart approach proved more attainable by most companies).
Companies need to decide what they are buying, and should not merely be based upon conventional wisdom, or the investment one has in one or the other approach. Not all companies need BI Heavy applications. And how one evaluates a BI Heavy versus BI light application is quite different. For instance, IT holds most of the decision-making power when it comes to which BI Heavy application to choose, however, the business users should have most of the decision making power when it comes to BI Light applications. As with ERP, the tendency in buyers has been to try to consolidate requirements into one software vendor; however, this is a failed strategy for BI software selection.
Most of the suites from the prominent BI vendors are just a jumble of applications from acquisitions. A perfect example of this is Business Objects, BI/BW and Crystal Reports (in this case, two of the applications were acquired by SAP, and one developed internally). SAP frequently makes the case that these acquisitions were strategic and create synergy. In the case of Business Objects, this was a competitor that was beating BI/BW in head to head competitions. SAP was able to remove this competitor through acquisition – thus enabling it to increase the price of both applications. SAP has done very little to integrate Business Objects into their BI “solution.” It’s just a product that is owned by SAP to enhance its monopolistic power. Is the fact some mega vendor needed to eliminate a worthy competitor and to reduce the price pressure a reason to buy an application? We don’t think so.
“Self Service” BI
One of the biggest trends in BI has been the move to so-called “self-service.” The efficiency of IT with regards to report creation has been well understood to be weak, with literal applications like SAP BI and IBM Cognos pulling the life force out of business with late reports, or reports that are provided that do not meet the business requirements. The support ratios for many applications in business intelligence are so high that they are driving buyers to applications with lower support ratios. IT is in a problem concerning BI. They have a natural inclination to want to control BI, to choose the solution, but on the other hand, they are tired of being beaten up for reports being late – a perpetual issue at most buyers that we interact with. However, the term self-service is a heavily marketing laden term. None of the applications that are often called self-service is self-service to the extent that they do not require significant training and hand-holding. Applications which are described as self-service by the business press and by software vendors and IT analysts like Gartner – are lower support requirement applications. It is no coincidence that applications of this type, such as QlikView and Tableau, have the highest buyer satisfaction levels as well as the highest user adoption levels in BI. We have an example from one of the main self-service applications, which is Tableau.
Software vendors tend to show complete reports like the one above. This provides a misleading impression as to the skill necessary to create these reports. Tableau is a great BI Light application. However, there are a ton of options. Tableau simplifies some of the decisions with its Show Me option in the upper right-hand corner, which greys out chart types that do not apply to the data. Another significant functionality which encourages self-service is the back button in the upper left corner. This allows a user to experiment and then return to the earlier state. It is also a multi-back button so that multiple changes can be made to a report and then all of these adjustments can be undone returning the report to its earlier pristine state.
However, In addition to deciding what measures or dimensions are pulled to the row and column, each measure and dimension has a drop-down which changes how the application uses it. Another factor to be adjusted is whether the data will be summed, counted, etc. All of this takes considerable experience, and that is to create the report – there is more work in knowing what data to pull into Tableau.
Self-service applications make a big splash about how easy it is to pull data into them. Tableau does offer many different connections to different data sources; however, have these already been set up by IT? Will IT connect to the proper IT sources? Will the business need to do some of this work themselves if IT is slow to do so?
Notice in this report the AVG Health Care and Average Life Expectancy is assigned to the Columns, Rows, as well as the Filters and the Marks area.
We can adjust this by placing the AVG GDP in $ measure into the column and removing the previous entry. This changes the relationship shown but keeps the overall chart the same. This was easy for us to do. This is probably the better application of self-service applications – that is having an overall report structure created, but allowing the users to make changes to what is shown in the report.
We consider Excel to be a true self-service application, and by that measurement, all BI applications we have evaluated fall short of that. These applications are much more powerful than Excel. However, it is undoubtedly worth it. This report shows that the United States pays an excessive amount of money for its life expectancy and that this the overpayment has very significantly increased since 2001. But one can’t have it both ways. One cannot expect BI applications that can produce sophisticated and nuanced report output, and then, on the other hand, expects this output to be entirely self-service.
While in the past, BI Heavy applications were the most widely purchased, this is beginning to change – as is explained in this quotation from Forrester.
“However, anecdotal evidence leads us to believe that with the proper BI application portfolio classification, no more than 20% of all BI applications should fall into this restricted category. We maintain that in an ideal BI environment, 80% of all BI requirements should be carried out by the business users themselves.”
When we evaluate new implementations, it is incredible to us how often the reports come in 6 months to 12 months after the application has been live. For all the talk of advanced techniques and data warehousing, it is incredible to us how poor the selection of reports is and many buyers. We have to question why this is not more widely understood. Why do so many journalists and IT analysts accept the promise of BI over the reality of BI? The primary software vendors have significant investments in BI Heavy applications/platforms and notable consulting companies have substantial investments in resources, toolkits and training in BI Heavy applications. The consulting companies and IT analysts are doing a thorough job of hiding the apparent productivity enhancements that are being provided by BI Light solutions from their customers.
Reporting is the ultimate example of “selling the future.” In our observations, BI only meets its potential when IT is taken off of the train tracks for creating reports, and maintains the backend, allowing the business users to build their own. There are several reasons we believe this, but one being a study of the history of BI, and a second being our participation in the gathering of reporting requirements for numerous projects.
Applications like QlikView and Tableau have the fastest implementation timelines in the BI area. These implementation timelines are so fast that it is curious why this is not more obvious and more embarrassing to many of the old-line BI companies. Again, we have to assume that the major consulting companies have a hand in keeping their clients from knowing about QlikView and Tableau as they would severely cut into their BI consulting business. IBM does not want its customers to benefit from these new approaches, but instead intends to sell Cognos. And then spend many months billing its clients so its consultants can talk in circles about dimensions and keys, and dicker with one of the lowest productivity BI environments in existence.
Another interesting feature that is not discussed enough is due to these fast implementation timelines how quick the applications begin earning returns for the company. Presently, there is a narrative that is employed by BI Heavy software vendors, and it is to dismiss the implementation accomplishments of the Light BI software vendors. It goes something like this..
Sure you can buy Tableau and bring up some reports quickly, but pretty soon you will find that the application does not scale.
We have heard quotes like this so many times. It is becoming a cliché of how to try to distract buyers from the clear advantage these new applications offer. This is simply false information. Tableau and QlikView are currently implemented in companies and providing analytics for substantial data sets. Furthermore, the feedback that we are receiving on the applications is hugely positive. Moreover, the adoption level of several of the Light BI applications is the highest in the BI and by substantial margins. This is the most compelling story in BI, and buyers should not accept these attempts to poison the well by the Heavy BI software vendors, or their partners in crime, the major consulting companies.
Therefore, we have the evidence the BI Light software offerings as the best values in the market – our TCO analysis of all of the BI vendors bears this out. One strategy that we have been proposing is that companies with a BI Heavy solution already buy a BI Light solution and begin to replace some of the functionality in which the BI Heavy solution is weak, and the BI Light solution is reliable. Due to the low productivity of BI Heavy solutions in precisely the type of things that BI Light does well, companies should be able to recoup the cost for these solutions in IT and consulting costs, as well as delivering much more satisfied business users.
Estimating The “Live” Duration for BI
One of the complicated factors concerning BI is how long to set the duration the application is “live.” This is the time between the go-live and when the application is decommissioned. Unfortunately, BI Heavy versus BI Light applications have different average live times, because once a buyer commits to a BI Heavy application, it is more reticent to switch to a new BI platform. This is not a positive, because high application switching costs mean a higher potential of being trapped in an application that is not meeting the requirements. Plenty of buyers that we talk to are currently caught in low productivity BI platforms/applications that were purchased without having sufficient experience with the application – often at the recommendation of a major consulting company. The reports that were promised by IT are slow to arrive, and it is a serious point of contention in many buyers. This is of course, also a common problem with the number one “lock in” application in enterprise software, ERP systems.
BI Heavy applications not only take longer to go live but take longer to provide higher percentages of the buyer’s reports/dashboards etc. BI systems are a bit different than other enterprise software categories in that the output is delivered more over time, with an increasing number of reports/dashboards becoming available as time passes. Many software vendors propose a much faster go-live than we have listed in our calculations. But producing a small number of reports quickly does not mean that the BI system has met “requirements” if the vast majority of reports are still outstanding at the point of measurement. Currently, we use ten years as the lifespan of BI Heavy applications and seven years for the lifespan of BI Light. However, the longer implementation timeline of BI Heavy applications as well as this slow rise of BI Heavy output should be considered so that when a BI Heavy application is at full strength is often considerably postponed after the go-live date.
The Growth of SaaS BI
SaaS BI is proving to be so efficient that companies must now decide whether they want a high-cost on-premises solution and lose out on a host of features and the productivity gained from having more and better reports. With solutions like Birst, companies are in a better position to make better decisions than in the past. Birst is a strange bird; it is a data warehouse but is also in the cloud. This is another example of how the BI landscape is changing from the old rules that it used to follow.
The Growth of Mobile BI
Related to SaaS BI, mobile BI is the ability to show reports on any number of mobile devices. This is still an emerging area, and it’s unclear to us how prominent this will be versus the hype. There are several areas of industry, such as the medical industry where mobile BI is already deployed, and where its benefits are unquestioned. However, for most other industries, the PC is still the dominant form of report consumption.
Future of BI
This space is ripe for more acquisitions. Oracle, IBM and SAP made significant acquisitions in 2007. As these companies do not invest in acquired products and are incapable of innovation due to their size and bureaucracy, these acquired applications are seriously out of date and are headed towards being sunset-ed. As is covered in the individual BI MUFI ratings available from the following links, several of these applications should no longer be sold. These conglomerates can easily purchase a prime target such as QlikView, Tableau or Birst and have leading technology for a few years. It will also allow them to kill competition and then talk about their dedication to innovation to the business press.
Our MUFI Rating and Risk rates the application and applies a risk analysis or risk factor.