"Comparing the Total Cost of Ownership of Business Intelligence Solutions"

If you receive errors when attempting to view this white paper, please install the latest version of Adobe Reader.

"Birst is Cloud BI. Also known as "SaaS BI" or "on-demand BI," Cloud BI simply means that Birst is offered as a subscription service delivered over the internet instead of as an on-premise software installation. As a Cloud BI solution, Birst is faster to get deployed, lower cost, and demonstrates a far more rapid time to value than an on-premise solution."
Source: Birst

Resources Related to The Nine Substantial Benefits of Software-as-a-service Business Intelligence:

• Business Intelligence (BI) (Wikipedia)
• Software as a Service (SaaS) (Wikipedia)

Comparing the Total Cost of Ownership of Business Intelligence Solutions

Table of Contents

• Executive Summary
• Elements of a Business Intelligence Deployment
• TCO of Traditional BI Solutions are Dominated by Staffing Costs
• Open Source Software Lowers Software Costs, While Raising Others
  • Open Source Challenges: Lack of Product Integration
  • Open Source Challenges: Programmering Complexity
• SaaS BI: Reducing TCO by 70% through Automation and BI Virtualization
• A Detailed Breakdown of Costs
  • Initial Build
  • Annual Management and Staffing (Three Years)
  • Hardware Costs
  • Software Costs
  • Downtime
• Conclusion

Executive Summary

Business Intelligence (BI) solutions provide organizations with the insight required to make critical business decisions regarding how they market and sell their products, manage their customers, deliver goods and services and manage their financial results. Unfortunately, providing this insight using traditional BI software has proven to be costly and resource intensive and in many cases fails to meet project and end user expectations.

Open Source business intelligence has emerged over the last several years as a potential way to address the cost issue. However, while Open Source BI may save money on license costs, it does not achieve the expected reduction in Total Cost of Ownership (TCO). This is because Open Source does not address the staffing costs associated with deploying and maintaining a BI solution, which according to IDC can constitute 60% of a three-year TCO [Include Reference.]

Specifically, Open Source BI generally requires more configuration and integration, as the solutions are typically far less integrated and require general programming skills to configure - thereby resulting in higher staffing costs. Because of these factors, Open Source provides little more than 10% savings on a three-year TCO versus traditional on-premise BI vendors [Include Reference.]

In contrast, Software-as-a-Service (SaaS) delivery model is predicated on automation and pre-integration, directly targeting the largest areas of cost for BI solutions. Software-as-a-service completely alters how software is provisioned, configured and deployed and offers significantly greater TCO advantages. Comparing the TCO of SaaS BI with both traditional and Open Source solutions reveals dramatic cost reductions - as much as 70% or more.

In this paper we first review the three primary delivery models for BI: traditional, Open Source and SaaS. We then build establish a TCO model by which we can evaluate the three offering types. Finally, the three BI offering types are evaluated at a summary level against this model. A more detailed TCO analysis can be found in the appendix.

Overview of the Three BI Models

Traditional BI
Traditional license software vendors sell software for an initial, up-front license fee (along with a smaller, annual maintenance fee.) It is the responsibility of customers of that software to purchase hardware, install the software, integrate various sub-components required to make the software function and configure the software for use. Given that these license fees for several categories of software may be very high, Open Source has emerged as an alternative source for software.

Open Source BI
With Open Source, communities of developers agree to collaborate, for free, on "projects", submitting code to online forums. This software is free to download and install, but requires all of the same non-license expenses as traditional software vendors. Given that Open Source vendors are for-profit institutions, a revenue model for these firms has emerged in which the software is typically divided into two versions: free and commercial. The free version is readily downloadable, but is missing key enterprise-class features. The commercial version is licensed using a traditional license software model from the Open Source vendor and, while offering lower license costs, the solutions similarly require the customer to buy and manage hardware and install, integrate, configure and manage several distinct software components.

SaaS BI
In contrast to traditional and open source solutions, Software-as-a-service enables a completely different software delivery model. SaaS vendors sell software, but also maintain responsibility for hardware, installation, provisioning and integration in a hosted environment. Consumers of SaaS solutions typically require nothing more than a browser. SaaS solutions are also typically purchased using a subscription pricing model so it avoids the big up-front costs of traditional and open source on-premise solutions. But which approach is most cost effective?

More than half of the total cost of a BI solution over three years is staffing related. According to IDC, project staffing costs account for approximately 60% of the 3-year total cost of ownership of a typical BI project.

Elements of a Business Intelligence Deployment

The process of converting raw data into useful business intelligence suitable for business decision making involves significant investment throughout the BI process; from development through implementation, deployment, and maintenance. Broadly speaking, IDC groups BI costs into 5 major cost categories (source: IDC, 2007): initial deployment costs, ongoing management costs, software costs, hardware costs and downtime. For a prototypical BI project (50 users, 10-15 data sources, with modest levels of data transformation), the costs break down for traditional BI over three years as below:

More than half of the total cost of a BI solution over three years is staffing related (initial build and annual staffing.) In fact, for larger deployments, the percentages skew even more towards staffing costs. According to IDC, project staffing costs account for approximately 60% of the 3-year total cost of ownership of a typical BI project.

In this model, initial deployment costs include the costs of designing, scoping, installing, configuring, implementing, quality controlling and training related to a BI deployment. Ongoing management costs include continued application evolution (new end-user reports/dashboards, new calculations, new data sources, etc. ), system management and administration and general system maintenance. Infrastructure costs include the costs of the physical hardware as well as any software licenses. Lastly, required system downtime for hardware and software updates which result in lost productivity costs. In addition to the IDC and Birst TCO models, companies have continually validated that staffing costs are the highest percentage of the TCO of a BI solution.

According to a white paper by Business Objects and Crimson Consulting Group on TCO:

• In addition to Initial Build and Ongoing Maintenance staffing costs, on average each physical server requires 0.25 Full time employees (FTE) to manage
• An average Business Objects deployment of 25 reports takes approximately five FTEs 90 days to deploy

According to a recent report from the Aberdeen Group entitled "Managing the Total Cost of Ownership of Business Intelligence":

• Most BI deployments take between 45 and 140 man-days to complete
• Making a single change to an existing BI report takes on average 3.2 days man-days

In a white paper by Nucleus Research which highlighted a best-in-class Microsoft BI implementation at Superior Propane, the project costs totaled $480,161 and took 10 months to deliver to the finance department and a few power users in other departments:

These examples illustrate the intensely manual nature of on-premise BI solutions, which are extremely resource intensive. As a result, the total cost of ownership of any BI deployment is dominated by staffing costs.

Traditional BI solutions are labor intensive to set up and maintain.

TCO of Traditional BI Solutions are Dominated by Staffing Costs

As shown repeatedly in the studies above, the total cost of ownership for traditional business intelligence solutions are dominated by staffing costs - but why is that? Traditional BI solutions are labor intensive to set up and maintain because for each project the team must:

• Procure, set up and maintain hardware and software
• Develop the logical model for the data to be analyzed and the metadata that describes it
• Create a physical schema for the data that supports the logical model's dimensional analysis as well as the specific ETL routines required to populate and update that data
• Develop the reports and dashboards that provide the resulting insight to business users
• Continue servicing business user requests for custom reports tapping new data sources

Developing the logical model is the central task in any business intelligence implementation, so all approaches require this step and it is, by its nature, labor intensive. However, this high-value exercise is dwarfed by the labor required to accomplish the other steps in the deployment. That the other primary tasks are disproportionately expensive is due to the fragmented architecture of traditional BI solutions - many of which are comprised of several disparate tools, each with a specific purpose and all of which must be manually integrated to create a complete solution for every project. This requires purchasing, setting up, configuring, and maintaining multiple products and then declaring the same logical entities in each of them - and making sure those defined objects work together as expected across all the products. Given the time required to get that right, it is not surprising that staffing costs easily outstrip the license cost of the software in the TCO for traditional business intelligence solutions.

Open Source provides TCO relief only for software license costs.

Open Source Software Lowers Software Costs, While Raising Others

Similar to traditional BI solutions, Open Source BI platforms are comprised of multiple, disparate products that require significant effort to install, integrate, configure and manage. As a result, Open Source BI solutions require similar staffing expenses to traditional approaches. Because the TCO for BI solutions is dominated by staffing costs, this means Open Source can deliver only a fraction of the expected overall savings compared to traditional solutions despite being able to provide software licenses at a steep discount. In a study by Rustam Aliyev comparing open source versus traditional BI vendors, the difference in TCO after five years was only around 10%, despite using free software:

As suggested by this study, Open Source provides TCO relief only for software license costs. Given that open source products suffer from the same challenges (separate tools, different metadata, and complex integration) as traditional on-premise solutions, they do not generate any savings in terms of productivity. In fact, compared to traditional BI solutions, in most cases the staffing or consulting expenses increase for Open Source BI deployments. Why? First of all, open source BI has been traditionally focused on embeddable components which means that the toolsets often require configuration with Java and Java Server programming. This translates to increased complexity and more advanced technical skills, exacerbating the human capital costs of a BI project and negating any advantages in licensing costs.

Never has Open Source been able to channel multiple independent projects into a single, coherent solution

Open Source Challenges: Lack of Product Integration

One of the core challenges of BI is that the industry grew up as a collection of point solutions that were slowly acquired by larger organizations who attempted to assemble them into "integrated" suites. Despite being able to purchase these suites from a single vendor, the products are generally not well integrated thus requiring significant effort to integrate and maintain those components over the project's lifecycle. This problem is even more acute in the Open Source community where solutions are assembled from distinct, independent Open Source developer communities and have little to no common direction. It is challenging enough to guide a single Open Source project towards a common goal once it reaches a certain size, but never has Open Source been able to channel multiple independent projects into a single, coherent solution.

To illustrate this product fragmentation, consider Pentaho, whose Open Source solution is comprised of more than 5 distinct components, the primary of which are:

• Mondrian - which is a ROLAP server and is shared among several different Open Source vendors and therefore cannot be completely integrated into any particular one
• Kettle - another project designed to allow for low-level, data transformation and movement. It can be used for analytical ETL, but is designed on the Informatica model of generalized data movement (much more complex to setup than more focused solutions)
• Pentaho Reporting - a separate project for reporting that requires low- level connections to data sources. This project was formerly known as JFreeReport, another Open Source Java-based reporting tool
• Weka - a Java-based data mining set of libraries and tools for testing and evaluating various data mining algorithms, built and maintained by the University of Waikato in New Zealand
• Pentaho BI Platform - another project maintained by the Pentaho team that adds additional components like workflow. It is built upon another Java-based developer studio, Eclipse, and requires integration with J2EE application server infrastructures

Similarly, consider Jaspersoft, another leading Open Source provider, whose solution is also composed of many projects managed by different and divergent developer teams. There are five core projects along with links to 205 additional projects that each require varying degrees of technical developer skills to integrate.

As a result, companies employing these technologies will need to invest more in integration when using Open Source business intelligence tools than when using traditional solutions - resulting in increased staffing costs during both the initial deployment and for ongoing system maintenance.

Open Source Challenges: Programmering Complexity

Given that each Open Source solution grew up from a series of independent, java-based developer communities, it is not surprising that Open Source solutions retain that programmer's mindset. Documentation is riddled with references to Java class definitions and Java technologies. This requires technical depth and places a significant burden on BI implementers to develop Java programming and platform integration skills - thereby creating staffing challenges and further increasing staffing costs.

With Pentaho, users must understand Java database connectors such as "OLAP4J" and be able to understand Java namespaces and Java classes. For example, to get a list of supported connectors, one must know how to reference the Java class "org.pentaho.reporting.engine.classic.core.MetaAttributeNames." As another example, users must understand Java classes in order to use data sources, which are, like most other objects in the project, instantiations of Java classes (e.g. "org.pentaho.reporting.engine.classic.core. MetaTableModel" is a specific java interface class.)

As another example, users must understand Java classes in order to use data sources, which are, like most other objects in the project, instantiations of Java classes (e.g. org.pentaho.reporting.engine. classic.core.MetaTableModel is a specific java interface class.)

The definition of Pentaho reporting "DataSource", taken from the community Wiki, is:

DataSources provide MetaData by returning TableModels that implement the "org.pentaho.reporting. engine.classic.core.MetaTableModel". The Meta-Data is DataAttributes, which are a map of <namespace.name> keys and arbitrary values.

This technical complexity is further demonstrated by some recent developer community postings illustrating the complexity of installing and using these solutions:

Like Pentaho, Jaspersoft is built on a Java framework. In fact, Jaspersoft implements all custom expressions as Java expressions. Upon report compilation, these expressions are extracted from the report definition and fed directly to the Java compiler to build a custom Java class. As a result, in order to be able to build expressions of any complexity in Jaspersoft, a developer must have working knowledge of Java, Java classes and Java expression syntax. In fact, in the screenshot below, it can be seen that each text field has an associated Java class and associated expressions that are built with Java expression and method invocation syntax.

"By providing new levels of abstraction and automation, SaaS can reduce TCO by 70% or more."
—Joe Bugajski,
Senior Analyst, Burton Group

SaaS BI: Reducing TCO by 70% through Automation and BI Virtualization

Unlike traditional and Open Source BI platforms, Software-as-a-Service BI was designed to radically reduce overall costs by providing a fully-integrated software suite that automates much of the manual configuration required by other tools. For example, Birst was developed as an integrated solution by one development team with one goal: enabling faster, easier business intelligence deployments. Birst does this by shifting the focus to the development of the logical data model that describes the data in business terms. Once that model is developed, Birst leverages its integrated platform to automate the creation of the physical data model, the full and incremental ETL routines required to populate that model, and the metadata that describes that logical model. The result is that the developers in a Birst deployment can begin developing reports and dashboards as soon as the logical model is completed - unlike deployments using other approaches for which there is typically months of effort between designing the logical model and building the reports and dashboards for the end users. Through the use of automation enabled by the fully-integrated platform, Software-as-a-service solutions like Birst can radically lower the staffing costs required for a BI project both in Initial Build and in Annual Staffing costs.

In addition, because Software-as-a-Service solutions include hardware and are able to amortize the resulting costs across many clients, the hardware cost category is not just subsumed in the software subscription costs, it is greatly reduced - another source of huge savings. Lastly, because SaaS solution providers manage their systems to the highest uptime and performance standards, customers using SaaS BI solutions will also see a significant reduction in Downtime expenses as defined above.

For purposes of comparison, consider a typical 50 user BI implementation with 10-15 different data sources and modest levels of data transformation and cleansing required. By providing new levels of abstraction and automation, TCO can be dramatically impacted and reduced by as much as 70% or more.

A Detailed Breakdown of Costs

The overall cost of every business intelligence deployment is comprised of initial and ongoing costs, both of which are described in detail here for traditional solutions, Open Source solutions and Birst. The detailed discussion that follows is intended to convey how Birst radically reduces the total cost of ownership across the entire project life cycle.

Initial Build

Initial build consists of the steps and effort required to initially start up a BI project. By automating, pre-integrating and delivering as a service, large chunks of this work can be reduced or eliminated. We detail each step below and the reduction in TCO that SaaS delivers.

Logical Business Model
This is really the core of a BI solution. It includes the business definitions of all data elements that will be used to build reports and dashboards and conduct analysis. This includes all required metrics and KPIs, hierarchies, levels within those hierarchies, level keys and business attributes. It also includes the definition of how these logical entities relate to source physical data. Best-practice BI solutions start with the definition of the business model first and then proceed with implementing that business model. The work required for this phase is dependent upon deep knowledge of the business and questions being addressed. This is where the unique skills of a business analyst or BI developer are leveraged. Generally speaking, this business definition is independent of whatever tool is used to implement it.

Source Data Transformation/Cleansing
Data rarely comes from a single, fully integrated source system or in a form that can be simply aggregated (summed or counted) in order to generate the required business metrics. Most often data needs to be cleaned and transformed. Examples of such cleansing and transformation operations include: bad record rejection, missing value handling, parent-child hierarchy unrolling, time-based sequence analysis, special-purpose business logic, custom record-matching and lookups, etc.

In both on-premise and Open Source BI toolsets, data transformation and cleansing is accomplished using independent ETL tools (e.g. Kettle.) These tools are designed for generalized data movement that involve the following steps: attach to a source data source, extract a series of rows, create some sort of transformation of those rows, and output them to a potentially different data output. These ETL tools provide low-level mechanisms to move data between arbitrary locations and manipulate it during the process. As a result, they can be used for transforming and cleansing data as part of an analytical data flow. In addition, they can be used for moving data from one system to another and for the integration of transactional systems. This generality comes at a cost of complexity, redundancy and lack of integration. All schemas must be independently defined in the ETL tool, separate from the downstream BI tool. This results in redundant metadata and significantly increased complexity. Such ETL tools have their own metadata, developer model, methods, syntax, libraries, etc. They require additional training and expertise. Moreover, redundancy creates greatly increased risk when modifying elements as all downstream impacts must be analyzed and compensated for. Changing one source column in a source database requires the examination of ETL metadata along with that of the downstream reporting and analysis metadata.

Birst, on the other hand, has a focused transformation and cleansing engine that is directly integrated into the analytical data flow. It utilizes the same business model elements and definitions that are used in reports and dashboards and therefore does not require the redundant metadata or configuration that exists when utilizing general-purpose data movement tools. Because schemas, sources, targets and metadata elements do not need to be defined, the amount of work required to implement transformation and cleansing logic is significantly reduced. Moreover, Birst's transformation syntax is identical to that in the reporting and analysis components.

Physical Data Model
The physical data model represents the actual physical table, file or cube structure that is required to contain the data for analysis purposes. This structure must be designed to support:

• Analytical flexibility - it should be obvious how this structure is to be queried in order to produce the broadest range of analytical results
• History - a huge reason for the use of analytical systems is to be able to save historical snapshots of items that change over time in order to analyze sequences, patterns and trends. The schema must be able to support storing and querying both current and historical versions of important business items.
• Performance - creating an efficient structure where, regardless of the query, the system can quickly bring together results from different places in order to serve up the results

In the world of data warehousing, generally this involves converting an original, normalized schema, into a denormalized one specifically designed for the above characteristics. In fact, according to Ralph Kimball, the author of "The Data Warehouse Toolkit", founder of both Metaphor and Redbrick Systems:

5. Only one standard schema methodology exists that's capable of expressing data in a single, uniform format that looks the same at the atomic layers as in all aggregated layers, and at the same time requires no schema-dependent programming: the star schema, other known as the dimensional model. Star schemas support all forms of drilling down described in this column. All possible many-to-one and many-to-many data relationships are capable of representation in a star schema, thus the star schema is the ideal platform for ad hoc querying.

Building such a structure involves the creation of (among other things):

• Fact tables
• Dimension tables (type I and type II if historical attributes are needed)
• Surrogate keys
• Dimensional snowflakes
• Proper indexes and indexing strategies (which can result in a three-fold increase in storage)
• Data partitioning strategies
• Missing value record creation

Building and designing these components takes highly specialized skills and can take a significant amount of time. Shortcuts on schema design very often leads to problems down the line where unforeseen analyses simply cannot be accomplished without a redesign and reload of the database.

Birst obviates the need for this entire step by completely automating the physical schema creation and management. By understanding the logical business requirements through the definition of the logical model, Birst automates the entire process of design and implementation of physical schemas while providing all the benefits of a full-featured modern star schema infrastructure under the covers.

Initial Load of the Target Schema
Once a physical schema is designed which allows for the calculation of all of the elements in the logical model, that schema must be loaded with source data. Loading that schema traditionally involves two different phases: initial load and incremental load. The initial load typically includes historical data going back a given period. Incremental loads provide for the loading of recently changed data or for the data needed for snapshot purposes (typically daily.) Each of these strategies involves different techniques and challenges.

For the initial load, the following are key items to accomplish:

• Bulk loading historical data - given the data volumes, bulk loaders typically provide the best mechanism for moving data into the database. Source data typically needs to be formatted in a very specific way and bulk loaders can be very finicky with even the smallest deviations from properly formatted data (embedded carriage returns in strings, null columns, proper quoting, date/time formats, etc.)
• Staging of data - typically data is loaded into a staging area from where it can then be loaded into the target schemas. This staging area needs to be designed.
• Dimension table loading - needs to ensure that the uniqueness constraints of dimensional attributes are maintained and that any surrogate keys are created. Also, linkages to any other snowflake tables must be set up.
• Fact table loading - loading facts from source tables. Needs to ensure that all relevant key relationships to dimensions are established and maintained (often requiring lookups.)

Given Birst's automated loading, the process of constructing the ETL scripts and routines to accomplish the initial load is eliminated.

Incremental Load of the Target Schema
As source data changes and new data becomes available, it is necessary to update the analytical database with these changes. Rather than re-loading the entire database each time (which, for larger data volumes, can be prohibitively expensive), changes to data must be detected and then propagated to the analytical database. Doing this requires additional complexity as unchanged data must be preserved and new data must be appropriately integrated into the structure. Typically this requires:

• For each dimension, detecting changes and updating attributes. For example, detecting that a given customer's address has changed and updating the customer record appropriately. Doing this efficiently can be challenging and expensive to set up (checksum and other schemes can be deployed to ensure only the records that changed need to be updated.)
• Adding additional fact metrics - for transactional information that needs to be aggregated, making sure that new items (like orders, shipments, etc.) are added to database.
• Recording historical snapshots - being able to properly record snapshots of various attributes. This requires being able to save many versions of a given record (say, for example, a customer record where their status may change.) This allows for the analysis of changes in the status of records and the effect on various metrics or outcomes. Proper treatment of snapshot data versus transactional data is critical for most real business analysis as well as being able to easily manage snapshot policy.

These various mechanisms require detecting whether a source data record should change an existing analytical data record, add a new record, or record a snapshot correlated with previous ones. The ability to do this drives powerful analytical capabilities, but hand coding the ETL or scripting required to create these results can be very arduous and error-prone.

Birst eliminates the need for manually creating this process by automatically detecting changes in dimensional records, automatically adding new fact metrics and automatically recording and managing snapshot sets.

Logical Business Metrics and Calculations
Business metrics are the core of a BI application. They are the reason that BI exists and they are the facts that will drive business decisions. As a result, their definition and calculation are critical. In addition to being important, they can also be very complex. Some metrics might seem simple to calculate at first, but after examination there is often more complex embedded business logic in these calculations that are important to take into consideration in order to arrive at a meaningful result. Two things are critical in being able to deliver these kinds of results:

• A powerful and expressive OLAP engine that allows for sophisticated metrics to be easily specified and calculated
• A platform that allows for rapid creation, deployment, testing and iteration on metrics to ensure that the results are what the business needs

BI Platforms have traditionally favored one or the other of these two needs which results in a difficult environment to create key calculations:

• Relational analytics solutions have allowed for easier creation and deployment of simple, one-pass metrics but more complex metrics (share calculations, period-over-period comparisons, multi-level calculations, etc.) require very complex metadata to accomplish
• Cube-based systems have powerful query languages (e.g. MDX) that are very expressive, but the redefinition of relationships often requires reloading and redeploying cubes and generally all the critical data is not loaded into a single cube, requiring the creation of yet another cube.

Birst deals with this by having a powerful expression language (that is dimensional and allows calculations typically found in a cube-based system), while maintaining the speed and flexibility to create, deploy and re-deploy metrics that even best-of-breed relational systems cannot match. This allows for much simpler expressions being able to calculate more complex items and allowing much faster iteration on metric definitions (with instant deployment) to ensure their correctness and utility (minimizing development time and waste.)

Report and Dashboard Design
Reports and dashboards have two very different end-user use cases. Reports are designed to pack a lot of richly formatted information for broad-based distribution in a format where users are meant to see the data as is with little to no exploration required. Reports can be printed and laid out in a pixel-perfect manner. Dashboards are designed to fit into a narrower slice of screen real estate but allow for interactive filtering and drilling such that users can "pull out" of a dashboard the information they need. As a result, in traditional BI suites reports and dashboards are actually created with different products requiring potentially significant re-work in order to address all key users.

Creating report and dashboards in Birst takes half the effort required by traditional BI products.

Moreover, many reporting and dashboarding products are so focused on formatting, that they require the end user to do a considerable amount of configuration and even programming. Pure-play reporting products often require deep knowledge of the SQL query language as well as a programming language like C# or Java.

The low-level nature of these tools, where logical metadata is lightly leveraged, if at all, and the duplication of efforts for different user interfaces creates a large burden on BI designers. Birst, on the other hand, unifies the development of reports and dashboards. All report elements can be composed into dashboards and all dashboard elements print in a pixel-perfect manner. No duplication of work is required and every object can be delivered in either usage style. Moreover, the full strength of Birst's logical metadata model is available to report designers, making reports much easier to create.

Creating report and dashboards in Birst takes half the effort required by traditional BI products.

Hardware Setup and Provisioning
Hardware systems must be set up and provisioned. Given the nature of web-based platforms that scale to more than a few users, several elements are required:

• A database server with the appropriate Disk I/O subsystems needed to support high-volume reads. Typically high-end RAID systems or SAN environments are required with parallel channel I/O in order to provide for predictable performance. Moreover, if relational databases are used, care must be taken to provision database files on different disk spindles than database log files or database temp files in order to prevent contention during analytical queries. It is very costly to set up a database server with the amount of memory and CPU needed.
• Should any high-availability requirements exist, a secondary server must be clustered with the primary one to ensure failover and recovery. Active versus passive clustering can add more expense and complexity for the benefit of uptime.
• A sufficient number of front-end web servers are required to shoulder the end-user load. The more interactive end users, the the greater the demand will be on the web server. These machines must be relatively high end to handle concurrency.
• A load-balancing infrastructure is required to ensure that user sessions are managed across these various web servers seamlessly and that the system scales to the right number of end-users
• Backup and disaster recovery mechanisms need to be provided
• Security infrastructure to secure "within the perimeter" is also necessary

Elimination of many of the most painful elements results in a 70% reduction in staffing and management costs for SaaS.

Birst incorporates best-of-breed database infrastructure with redundancy and scalability as key factors. Birst's multi-tenancy allows the costs of this sort of infrastructure to be shared such that more BI users can benefit from these configurations.

Software Installation and Configuration
Software installation and configuration is one of the most underappreciated categories. It is not uncommon to hear stories about eight week installations for mainstream BI products. Consider that for many organizations all servers confirm to an IT certified image. That image includes a known set of software, service packs, drivers, etc. It is rare for packages like BI products to be completely compatible with these images and as a result considerable time is spent patching, upgrading installing drivers, changing operating system settings, etc. just to get the software running.

In addition to installing BI software, several other expensive and complicated software components must be installed, configured and managed:

• Application servers (e.g., WebLogic, IIS, Webshere, Tomcat, etc.) - this includes base software installation along with things like port configuration, SSL and certificate management, authentication infrastructure, logging, clustering, failover, etc.
• Database servers - significant costs exist in setting up and maintaining analytical databases including database storage strategies, partitioning, authentication, backup, clustering failover and recovery
• Single sign-on configuration

As a service, none of these pain points exist with Birst.

Training
With fewer parts of the product exposed and requiring training, Birst's training modules can be more focused and efficient as a result, end users can be productive in far less time and for far less money

Annual Management and Staffing (Three Years)

Eliminating many of the most painful elements results in a 70% reduction in staffing and management costs.

Hardware Management
Hardware infrastructure needs to be maintained at the platform level on an ongoing basis. This includes hardware monitoring, routine hardware maintenance/replacement, and general IT-level systems management:

• Hardware failure/replacement
• Disk space monitoring/management
• RAID/SAN/Storage system management
• Defragmentation
• OS-level patches/upgrades
• Network management (firewall, routing, bandwidth, etc.)
• Asset management/accounting
• Cluster management (redundant hardware, failover testing, etc.)

All of these items are included in Birst.

Database Administration
Database administration is another key element of cost. For relational databases, this includes:

• Data load/failure monitoring and management (and perhaps execution)
• Index rebalancing/tuning
• Index/table defragmentation
• Database copy/replication (e.g. test environment versus production)
• Security and security policy management
• Database file management

For cube data stores, index and file management are reduced, but cube reloading is a bigger issue. Moreover, proliferation of cubes exacerbates the other issues. Birst automatically handles all database management tasks.

Logical Data Model Changes
As a business changes, its BI also needs to change. New metrics, new data sources, and new business rules and priorities become important. These priorities must be understood and defined. Once defined, they must be able to be flexibly added to an existing solution. These activities are relatively independent of the BI solution used because they relate to underlying business needs.

Physical Data Model Changes
Once changes to a logical model are determined, they must be implemented physically. These typically involve schema changes (e.g. the addition of a new column to a table) and the addition of new data sources. Traditional BI infrastructures require modification of existing schemas and load routines. Birst automatically propagates schema and database model changes into its underlying physical data store. This eliminates the need to manage database physical structures and keep them in synch with logical metadata models.

Development-to-production Management
Most often, reporting and dashboarding solutions are constructed by one or more individuals for consumption by a different set of individuals. Those who consume the reports and dashboards (and potentially ad hoc analysis) are shielded from the implementation. Once a system is delivered, additional reports, logical data model changes, etc., need to be incorporated into the solution. That development process may involve altering existing functionality. As a result, it is usually inappropriate to do anything more than report and dashboard development in a production environment. Best practice involves setting up a development or user acceptance environment where new items can be added or modified, and data/ and metadata can be added, deleted or altered at will without disrupting a production instance.

In order to accomplish this, traditional business intelligence deployments require the setup of a redundant instance of the BI technology stack which often involves the duplication of both software and hardware infrastructures. In addition to the added burden of more hardware and software to manage, the development environment will have its own metadata, data, and configuration. Examples of items which may be different in a development environment include:

Birst virtualizes the BI application infrastructure and makes it easy to maintain multiple instances simultaneously.

• Data source definitions
• Hierarchies
• Metric definitions
• Security rules/filters
• ETL processes
• Schema definitions
• Reports
• Reports

When the time comes to migrate these changes into a production environment the challenges can be considerable. Special time windows must be used to ensure production system downtime is minimally disruptive. Some metadata must be moved from development to production, while others are not. For example, the users who are defined in a development instance may not be the same users defined in a production instance, but the metric definitions and reports should transfer. Moving the metadata over appropriately and synchronizing these systems can require significant overhead each time a "release" occurs.

Birst virtualizes the BI application infrastructure and makes it easy to maintain multiple instances simultaneously. No additional infrastructure need be installed, managed, or maintained. Moreover, individual items can be migrated from development to production in an automated way, making development to production management dramatically simpler.

New Report/Dashboard Design
The ultimate deliverable of a BI solution is some form of data presented for individual consumption. There are three primary modes of information distribution that have evolved over the years:

• Reports - Reporting is the core of BI and the dominant mode of information consumption. Reports are intended to broadly disseminate information in a published manner, requiring minimal user interaction to consume. Reports present information as it is intended to be consumed, They are typically highly formatted with multiple views, aggregations and levels of detail present. Reports are often meant for offline use and are generally designed to be printed for reference. Over the years, the banded report writer has become the de-facto standard for generating reports.
• Dashboards - Dashboards are designed to provide users a much narrower window into data along with controls that allow users to interact with these views to manipulate the data presented. Best-of-breed dashboards provide a higher level of interactivity and allow end users to filter, sort, drill, and generally navigate through various views and visualizations of data.
• OLAP - For power users and business analysts, there is a need for a richer tool for exploring data and finding answers. Dimensional OLAP tools (typically with a pivot table user interface) allow power users to sift through and segment data in arbitrary ways in order to analyze various segments. These tools generally require a higher degree of skill and are intended for a limited audience with deep knowledge of both the tool and data.

Given conventional BI suites, including all major Open Source BI suites, are collections of independent tools designed separately, there is a distinct tool for each of the above purposes (in some cases more than one.) Designers are often forced to choose between picking one of these tools and catering to a particular end-user group, or the prospect of building a solution in multiple tools. For those who choose the latter, multiple products must be installed, configured, deployed, and integrated. Also, metadata must be duplicated and synchronized, and training must be extended. This significantly increases the scope and complexity of a BI project.

With Birst, all three modes of analysis are contained within one product, one user interface, and one deployment. Metadata is shared between them and all three forms are based on the same underlying object. For any report, banding can be optionally leveraged to produce best-of-breed reports. Moreover, for any report, an OLAP/Pivot UI can be leveraged for data exploration. All reports can be simply dragged directly onto a dashboard with no coding, duplication, or rework required.

Software Patching and Upgrades
All computer system instances are moving targets. Over time, each layer of software becomes more and more out-of-date. Systems managers must choose when and if individual software patches are installed at each of the layers (operating system, database, ETL, reporting, dashboarding, application server, etc.). Patch installation requires careful control as any patch that is incompatible with other layers of the stack or does not get installed properly can result in a system which does not function. Moreover, these patches may not be reversible.

Best practice involves patching development environments first to ensure patches occur as planned.

Birst eliminates the need to manage system backup and recovery.

System administrators who fail to apply patches in a timely manner risk bugs, or much worse, security holes that can continually crop up in all layers of software and lend themselves to vulnerability. This makes the prospect of having an out-of-date system particularly risky.

Patches generally involve in-place application. Software upgrades are generally more serious and difficult to manage. Upgrades often involve serious revisions to the process and require significant planning and work to implement. Additionally, many vendors charge additional license fees for upgrades, while at the same time stopping the support of older versions of their products. Installations of software not on the current release do not receive patches and fixes as regularly (maintenance is generally de-prioritized) and therefore those systems are particularly at risk.

As a service, customers of Birst do not need to worry about any software patching or upgrading. It is all managed automatically and end users are always on the current version with zero upgrade cost.

Security Infrastructure and Management
In addition to keeping software patched, security must also be managed for an on-premise solution. Most organizations generally have perimeter security covered (inside and outside the firewall), but within the firewall security is an issue. Systems where BI software is installed require anti-virus and internal firewall management. These systems should also be locked down to prevent improper access from anyone who has access to an internal network. This typically includes proper user security management, system security policy management (which often needs to be specifically tuned to work with the given installed software packages), internal encryption and secure certificate management, as well as potential network management (subnet restrictions, etc.). All of these elements are automatically managed and secured within Birst.

Backup Management and Disaster Recovery
Business intelligence environments are increasingly mission critical. As a result, system failure must be guarded against and recovery time can be important. A proper backup policy must be maintained and managed to ensure the system can be restored if any system issue occurs. Today's regulatory environment also often calls for a proper disaster recovery mechanism to be in place for critical business systems. Implementing disaster recover can be very expensive and difficult to test or audit.

Birst eliminates the need to manage system backup and recovery by providing additional production through application virtualization. Entire BI instances can be copied or cloned in a single click. In addition to being a helpful development tool, this protects against developer error where data or a solution is irreparably harmed by an unintended mistake.

Training
Having a single, integrated product with a single metadata layer and consolidated user-interface, Birst requires substantially less training over time.

Hardware Costs

Hardware provisioning for BI can be a challenge. Unlike operational systems, where every user screen generates a well-defined and consistent workload, BI reports and queries can vary from trivial, to hugely expensive (aggregating millions or billions of rows of data.) Therefore, one must typically provision hardware to handle many users issuing complex analysis requests simultaneously. This extremely variable computing load requires provisioning of greater computing power and generally results in lower hardware use than in conventional computing systems. It is not uncommon to have CPU and disk use at 1-4% in order to handle infrequent peaks of 60-80%. These low use levels result in particularly expensive hardware requirements. Cloud-based hardware virtualization does not address this as these systems must remain on and using CPU at all times as user load is unpredictable.

This is compounded if any degree of service level is required. To maintain uptime service levels, redundant hardware must be made available for clustering and failover, often doubling hardware infrastructure costs.

Birst's multi-tenant architecture (unique for SaaS BI solutions) allows for a scalable, share-nothing server environment that not only allows Birst to scale to tens of thousands of users, but balances load across a wide number of machines. That allows for higher levels of machine use and inherent redundancy and failover.

Software Costs

In addition to the fact that the licensing model for major on-premise solutions can be very expensive, the licensing model itself is more difficult to consume financially. License software requires larger, initial payments that are typically counted in capital expenditure budgets. Maintenance fees must also be paid over time.

While community versions of Open Source solutions are free, enterprise versions also have fees attached to them. These fees may follow a license or subscription model, but are necessary if a customer wishes to receive technical support (which is often critical for business intelligence solutions given their complexity.)

Birst is offered as a service and therefore leverages a subscription model that not only costs less in aggregate over a three-year period than on-premise solutions, but can typically be included in operating budgets and does not require capitalization or depreciation.

Downtime

Loss of productivity can be expensive. The power of business intelligence is in its ability to allow businesses to monitor operations closely and make critical decisions based on fact. After an organization builds those capabilities into their normal business practices, the removal of such a capability can paralyze an organization, rendering it even less effective than it was before the system was initially installed. Idle workers and wasted productivity is a huge soft cost.

Downtime comes from two principal sources:

• Planned downtime - Due to data loads, development-to-production migration, upgrades, etc.
• Unplanned downtime - Due to system failure

Birst provides for zero-downtime data loads and automated development-to-production migration with no need for upgrades. Birst also provides for higher services levels than can usually be achieved internally (or if they were to be achieved, would require significant infrastructure investment.)

Conclusion

Since the lion's share of costs in a BI deployment relate to human capital and integration costs, Birst's pre-integrated and consolidated solution drives significant total cost of ownership (TCO) advantages over both traditional on-premise vendors and Open Source alternatives. Using Birst eliminates many of the costs in a BI deployment resulting in a 70% reduction in TCO and a 65% reduction in time to value.

Birst, Inc.
153 Kearny St., 3rd floor
San Francisco, CA 94108
http://www.birst.com/
Email: sales@birst.com
Toll Free Phone: (866) 940-1496