Description
Comparing the Total Cost of Ownership of Business Intelligence Solutions
WHITE PAPER
Comparing
the Total Cost
of Ownership
of Business
Intelligence
Solutions
How Cloud BI Can Reduce TCO
by 70% versus Traditional and
Open Source BI
2
WHITE PAPER
Table of Contents
Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Overview of the Three BI Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Elements of a Business Intelligence Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . .5
TCO of Traditional BI Solutions are Dominated by Stafng Costs . . . . . . . . . . . . . .7
Open Source Software Lowers Software Costs, While Raising Others . . . . . . . . . .8
Open Source Challenges: Lack of Product Integration . . . . . . . . . . . . . . . . . . . .9
Open Source Challenges: Programming Complexity. . . . . . . . . . . . . . . . . . . . 10
Cloud BI: Reducing TCO by 70% through Automation and BI Virtualization . . . 12
A Detailed Breakdown of Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Initial Build. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Annual Management and Stafng (Three Years) . . . . . . . . . . . . . . . . . . . . . . . 20
Hardware Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Software Costs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Downtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Comparing the Total Cost of Ownership of
Business Intelligence Solutions
3
WHITE PAPER
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 ?nancial 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 software license costs, it does not achieve the expected
reduction in Total Cost of Ownership (TCO.) This is because Open Source does
not address the stafng costs associated with deploying and maintaining a BI
solution, which according to IDC can constitute 60% of a three-year TCO.
Speci?cally, Open Source BI generally requires more con?guration and
integration, as the solutions are typically far less integrated and require
general programming skills to con?gure – thereby resulting in higher stafng
costs. Because of these factors, Open Source provides little more than 10%
savings on a three-year TCO versus traditional on-premise BI vendors.
In contrast, the Software-as-a-Service (SaaS) delivery model is predicated on
automation and pre-integration, directly targeting the largest areas of cost
for BI solutions. Cloud delivery completely alters how software is provisioned,
con?gured and deployed and ofers signi?cantly greater TCO advantages.
Comparing the TCO of Cloud BI with both traditional and Open Source BI
solutions reveals dramatic cost reductions – as much as 70% or more.
Executive Summary
4
WHITE PAPER
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 con?gure 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-pro?t institutions, a
revenue model for these ?rms 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 ofering lower license costs, the solutions similarly
require the customer to buy and manage hardware and install, integrate,
con?gure and manage several distinct software components.
Cloud BI
In contrast to traditional and open source solutions, Software-as-a-service
enables a completely diferent software delivery model. Cloud providers
sell software, but also maintain responsibility for hardware, installation,
provisioning and integration in a hosted environment. Consumers of Cloud
solutions typically require nothing more than a browser. Cloud 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 efective?
In this paper we ?rst review the three primary delivery models for BI:
traditional, Open Source and Cloud. We then establish a TCO model by which
we can evaluate the three ofering types. Finally, the three BI ofering types are
evaluated at a summary level against this model. A more detailed TCO analysis
can be found in the appendix.
Executive Summary
5
WHITE PAPER
The process of converting raw data into useful business intelligence suitable
for business decision making involves signi?cant 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 stafng
related (initial build and annual stafng). In fact, for larger deployments,
the percentages skew even more towards stafng costs. According to IDC,
project stafng 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, con?guring, 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 additional software licenses. Lastly, required system downtime for
hardware and software updates results in lost productivity costs. In addition
to the IDC and Birst TCO models, companies have continually validated that
stafng costs are the highest percentage of the TCO of a BI solution.
Elements of a Business Intelligence
Deployment
More than
half of the
total cost of
a BI solution
over three
years is
stafng
related.
According to
IDC, project
stafng costs
account for
approximately
60% of
the 3-year
total cost of
ownership
of a typical BI
project.
6
WHITE PAPER
Elements of a Business Intelligence
Deployment
According to a white paper by Business Objects and Crimson Consulting Group
on TCO:
• In addition to initial build and ongoing maintenance stafng 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
?ve 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
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 stafng costs.
7
WHITE PAPER
TCO of Traditional BI Solutions are
Dominated by Stafng Costs
As shown repeatedly in the studies above, the total cost of ownership for
traditional business intelligence solutions are dominated by stafng 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 speci?c 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 speci?c purpose and all of which must
be manually integrated to create a complete solution for every project.
This requires purchasing, setting up, con?guring, and maintaining multiple
products and then declaring the same logical entities in each of them – and
making sure those de?ned objects work together as expected across all the
products. Given the time required to get that right, it is not surprising that
stafng costs easily outstrip the license cost of the software in the TCO for
traditional business intelligence solutions.
8
WHITE PAPER
Similar to traditional BI solutions, Open Source BI platforms are comprised
of multiple, disparate products that require signi?cant efort to install,
integrate, con?gure and manage. As a result, Open Source BI solutions
require similar stafng expenses to traditional approaches. Because the
TCO for BI solutions is dominated by stafng 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 diference in TCO after ?ve 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 sufer from the same
challenges (separate tools, diferent 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 stafng 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 con?guration 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.
Open Source Software Lowers Software
Costs, While Raising Others
9
WHITE PAPER
Open Source Software Lowers Software
Costs, While Raising Others
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 signi?cant efort 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 diferent 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 training and running
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 work?ow. 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 diferent and divergent
developer teams. There are ?ve 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 stafng costs during both the initial
deployment and for ongoing system maintenance.
Never has
Open Source
been able
to channel
multiple
independent
projects
into a single,
coherent
solution.
10
WHITE PAPER
Open Source Software Lowers Software
Costs, While Raising Others
Open Source Challenges: Programming 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 de?nitions and Java technologies. This requires
technical depth and places a signi?cant burden on BI implementers to develop
Java programming and platform integration skills – thereby creating stafng
challenges and further increasing stafng 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 speci?c java interface class).
The de?nition 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:
I’m a newbie. When I tried modifying the HelloWorld.xaction with 2.0.0
release, I encountered a couple of difculties:
• I thought I was using the “fle-based repository”, but I still found it
necessary to log into the admin console at http://localhost:8099, select
Administration » Services » Solution Repository » Refresh. Once I ?gured
this out, changing that xaction ?le to “I did it” actually worked.
• That %quote thing really bothered me. There was no HelloWorld_
en.properties in the Pentaho Solutions so it never put anything there. If
you want to use that %quote function and there is no such ?le, just create
it in the same folder with the line:
I think the Plug-in Installation paragraph is out of date. You can download
the plugins here:
• SourceForge (Design Studio) contains the above mentioned
1. org.pentaho.designstudio.editors.actionsequence_X.X.X.X.zip
2. org.pentaho.designstudio.editors.core_X.X.X.XX-0.zip
11
WHITE PAPER
Open Source Software Lowers Software
Costs, While Raising Others
• SourceForge (Report Design Wizard) contains legacy version of pentaho-
report-design-wizard-XXX.zip (replacement for the above mentioned org.
pentaho.designstudio.editors.core_X.X.X.XX-0.zip)
I’m new to Pentaho and just becoming acquainted with it so I don’t know
what happened with the Report Wizard. Maybe the wizard is not included
in the .core or .actionsequence package.
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 de?nition 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 ?eld has
an associated Java class and associated expressions that are built with Java
expression and method invocation syntax.
12
WHITE PAPER
Cloud BI: Reducing TCO by 70% through
Automation and BI Virtualization
Unlike traditional and Open Source BI platforms, Cloud BI was designed to
radically reduce overall costs by providing a fully-integrated software suite
that automates much of the manual con?guration required by other tools. For
example, Birst was developed as an integrated solution by one development
team with one goal: enabling faster, easier BI 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
and schema, the full and incremental ETL routines required to populate that
schema, and the metadata that describes the 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 efort between
designing the logical model and building the reports and dashboards for
the end users. Through the use of automation enabled by a fully-integrated
platform, Birst radically lowers the stafng costs required for a BI project both
in initial build and in annual stafng costs.
In addition, because Cloud solutions share hardware 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
Cloud solution providers manage their systems to the highest uptime and
performance standards, customers using Cloud BI solutions will also see a
signi?cant reduction in downtime expenses as de?ned above.
For purposes of comparison, consider a typical BI implementation with 50
users, 10-15 diferent 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.
“ By providing
new levels of
abstraction
and
automation,
SaaS can
reduce TCO
by 70% or
more.”
—Joe Bugajski,
Senior Analyst, Burton Group
13
WHITE PAPER
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 efort 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 Cloud solutions deliver.
Logical Business Model
This is really the core of a BI solution. It includes the business de?nitions 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
de?nition of how these logical entities relate to physical data source.
Best-practice BI solutions start with the de?nition of the business model ?rst
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 de?nition 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
A Detailed Breakdown of Costs
14
WHITE PAPER
A Detailed Breakdown of Costs
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 involves 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 diferent
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 ?ow. 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 de?ned in the ETL tool, separate from the downstream BI
tool. This results in redundant metadata and signi?cantly 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 ?ow. It utilizes the same
business model elements and de?nitions that are used in reports and
dashboards and therefore does not require the redundant metadata or
con?guration that exists when utilizing general-purpose data movement
tools. Because schemas, sources, targets and metadata elements do not need
to be de?ned, the amount of work required to implement transformation and
cleansing logic is signifcantly 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, ?le or cube
structure that is required to contain the data for analysis purposes. This
structure must be designed to support:
• Analytical fexibility – 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 data that change over time in order to analyze
sequences and identify patterns and trends. The schema must be able
to support storing and querying both current and historical versions of
important business data.
15
WHITE PAPER
A Detailed Breakdown of Costs
• Performance – creating an efcient structure where, regardless of the query,
the system can quickly bring together results from diferent places in order to
serve up the results
In the world of data warehousing, generally this involves converting an
original, normalized schema, into a de-normalized one speci?cally 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:
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
• Slowly changing dimensions (SCDs)
• Surrogate keys
• Dimensional snowfakes
• Proper indexes and indexing strategies
• Data partitioning strategies
• Missing value record creation
Building and designing these components takes highly specialized skills and
can take a signi?cant amount of time. Shortcuts on data model 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 these manual steps by completely automating
the physical schema creation and management. By understanding the
logical business requirements through the de?nition of the logical model,
Birst automates the entire process of design and implementation of physical
schemas while providing all the bene?ts 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 diferent phases: initial
load and incremental load. The initial load typically includes historical data
16
WHITE PAPER
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 diferent 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
provides the best mechanism for moving data into the database. Source data
typically needs to be formatted in a very speci?c way and bulk loaders can be
very ?nicky 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 schema. The required staging tables need
to be designed and maintained.
• Dimension table loading – needs to ensure that the uniqueness constraints of
dimensional attributes are maintained and that required surrogate keys are
created. Also, linkages to any other snow?ake tables must be set up.
• Fact table loading – loading facts from staging tables. Needs to ensure that
all relevant key relationships to dimensions are established and maintained
(often requiring lookups.)
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 efciently 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 efect
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.
A Detailed Breakdown of Costs
Given Birst’s
automated
loading, the
process of
constructing
the ETL scripts
and routines
to accomplish
the initial
load is
eliminated.
17
WHITE PAPER
A Detailed Breakdown of Costs
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 running 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
de?nition and calculation are critical. In addition to being important, they can
also be very complex. Some metrics might seem simple to calculate at ?rst,
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 speci?ed 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 difcult 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 rede?nition 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 ?exibility 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 de?nitions (with instant deployment)
to ensure their correctness and utility (minimizing development time and waste).
Report and Dashboard Design
Reports and dashboards have two very diferent end-user use cases. Reports
are designed to pack a lot of richly formatted information for broad-based
18
WHITE PAPER
A Detailed Breakdown of Costs
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 ?t into a narrower slice of screen
real estate but allow for interactive ?ltering 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 diferent products
requiring potentially signi?cant re-work in order to address all key users.
Moreover, many reporting and dashboard products are so focused on
formatting, that they require the end user to do a considerable amount of
con?guration 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 eforts for diferent user interfaces
create a large burden on BI designers. Birst, on the other hand, uni?es 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 reports and dashboards in Birst takes half the efort 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 ensure
predictable performance. Moreover, if relational databases are used, care
must be taken to separate database ?les onto diferent disk spindles from
database log ?les or database temp ?les 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 expenses and complexity for the needed
bene?t of uptime.
• A sufcient number of front-end web servers are required to shoulder the
end-user load. The more interactivity end users require, the greater the
demand will be on the web server. These machines must be relatively high-
end to handle concurrency.
Creating
report and
dashboards
in Birst takes
half the efort
required with
traditional BI
products.
19
WHITE PAPER
A Detailed Breakdown of Costs
• 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
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 across many customers.
Software Installation and Con?guration
Software installation and con?guration is one of the most under appreciated
categories. It is not uncommon to hear stories about eight week installations
for mainstream BI products. Consider that for many organizations all servers
need to conform to an IT-certi?ed image. That image includes a known set of
software, service packs, drivers, etc. It is rare for standard enterprise software
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, con?gured and managed:
• Application servers (e.g., WebLogic, IIS, Webshere, Tomcat, etc.) – this
includes base software installation along with things like port con?guration,
SSL and certi?cate management, authentication infrastructure, logging,
clustering, failover, etc.
• Database servers – signifcant costs exist in setting up and maintaining
analytical databases including database storage strategies, partitioning,
authentication, backup, clustering failover and recovery
• Single sign-on confguration
As a fully-managed service, none of these pain points exist with Cloud BI
and Birst.
Training
With fewer parts of the product exposed and requiring training, Birst’s training
modules can be more focused and efcient as a result, end users can be
productive in far less time and for far less money.
Elimination of
many of the
most painful
elements
results
in a 70%
reduction in
stafng and
management
costs for SaaS.
20
WHITE PAPER
Annual Management and Stafng (Three Years)
Eliminating many of the most painful elements results in a 70% reduction in
stafng 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 (frewall, routing, bandwidth, etc.)
• Asset management/accounting
• Cluster management (redundant hardware, failover testing, etc.)
All of these items are included with Cloud BI and Birst.
A Detailed Breakdown of Costs
21
WHITE PAPER
A Detailed Breakdown of Costs
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 fle management
For cube data stores, index and ?le 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 use and scope of BI needs to adapt. New metrics,
new data sources, and new business rules and priorities become important.
These priorities must be understood and de?ned. Once de?ned, the BI solution
needs to accommodate them ?exibly and quickly. 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 manual modi?cations of existing schemas and load
routines. Birst automatically propagates required 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 dashboard solutions are constructed by one or
more individuals for consumption by a diferent set of individuals. Those
who consume the reports and dashboards (and potentially ad hoc analysis)
are shielded from the actual 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 modi?ed, and data/ and metadata can be added,
deleted or altered at will without disrupting a production instance.
22
WHITE PAPER
A Detailed Breakdown of Costs
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
con?guration. Examples of items which may be diferent in a development
environment include:
• Data source defnitions
• Hierarchies
• Metric defnitions
• Security rules/flters
• ETL processes
• Schema defnitions
• Reports
• Dashboards
When the time comes to promote 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 de?ned in a development
instance may not be the same users de?ned in a production instance, but
the metric de?nitions and reports should transfer. Moving the metadata
over appropriately and synchronizing these systems can require signi?cant
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. A report is typically
highly formatted with multiple views, aggregations and levels of detail
present. Reports are often meant for ofine 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.
Birst virtualizes
the BI
application
infrastructure
and makes
it easy to
maintain
multiple
instances
simultaneously.
23
WHITE PAPER
A Detailed Breakdown of Costs
• 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 interact with the data presented. Best-of-breed dashboards provide
a high level of interactivity and allow end users to ?lter, sort, drill, and
generally navigate through various views and visualizations of data.
• Ad Hoc/OLAP Analysis – For power users and business analysts, there is a
need for a richer tool for exploring data and ?nding 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 that 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,
con?gured, deployed, and integrated. Also, metadata must be duplicated
and synchronized, and training must be extended to deal with diferent user
interfaces. This signi?cantly 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, dashboards, 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 ?rst to ensure
patches occur as planned.
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.
Birst
eliminates
the need
to manage
system
backup and
recovery.
24
WHITE PAPER
Patches generally involve in-place application. Software upgrades are
generally more serious and difcult to manage. Upgrades often involve
serious revisions to the process and require signi?cant 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 ?xes 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 ?rewall), but within the ?rewall
security is an issue. Systems where BI software is installed require anti-virus
and internal ?rewall 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 speci?cally tuned to
work with the given installed software packages), internal encryption and
secure certi?cate 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
difcult to test or audit.
Birst provides backup and disaster recovery as part of the Cloud BI service.
In addition, 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.
A Detailed Breakdown of Costs
25
WHITE PAPER
Hardware Costs
Hardware provisioning for BI can be a challenge. Unlike operational
systems, where every user screen generates a well-de?ned 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 Cloud 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 difcult to
consume ?nancially. License software requires larger upfront payments that
are typically recognized as capital expenditures. 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 ofered 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.
A Detailed Breakdown of Costs
26
WHITE PAPER
A Detailed Breakdown of Costs
Downtime
Loss of productivity can be expensive. The power of business intelligence lies
in its ability to allow business users to monitor operations closely and make
critical decisions based on facts. After an organization builds those capabilities
into their normal business processes, the removal of such a capability can
paralyze an organization, rendering it even less efective 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 signi?cant infrastructure investment.)
27
WHITE PAPER
About Birst
Birst is the leader in agile business analytics. It ofers a single place to manage all of a business’ analytics and agility
to answer questions that span departments, data sources, and deployments—across both public or private Clouds.
Birst gives users the fastest way to answer their most pressing business questions—and then all the ones they didn’t
know to ask. At one-third the cost, time, and staf of traditional big BI, Birst brings the bene?ts of analytics and fact-
based decision-making to a much broader audience. For more information, visit www.birst.com.
Birst Inc.
153 Kearny Street
San Francisco, CA 94108
Call toll free: (866) 940-1496
Email us: [email protected]
www.birst.com
Conclusion
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
signi?cant 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.
doc_195466336.pdf
Comparing the Total Cost of Ownership of Business Intelligence Solutions
WHITE PAPER
Comparing
the Total Cost
of Ownership
of Business
Intelligence
Solutions
How Cloud BI Can Reduce TCO
by 70% versus Traditional and
Open Source BI
2
WHITE PAPER
Table of Contents
Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Overview of the Three BI Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Elements of a Business Intelligence Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . .5
TCO of Traditional BI Solutions are Dominated by Stafng Costs . . . . . . . . . . . . . .7
Open Source Software Lowers Software Costs, While Raising Others . . . . . . . . . .8
Open Source Challenges: Lack of Product Integration . . . . . . . . . . . . . . . . . . . .9
Open Source Challenges: Programming Complexity. . . . . . . . . . . . . . . . . . . . 10
Cloud BI: Reducing TCO by 70% through Automation and BI Virtualization . . . 12
A Detailed Breakdown of Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Initial Build. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Annual Management and Stafng (Three Years) . . . . . . . . . . . . . . . . . . . . . . . 20
Hardware Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Software Costs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Downtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Comparing the Total Cost of Ownership of
Business Intelligence Solutions
3
WHITE PAPER
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 ?nancial 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 software license costs, it does not achieve the expected
reduction in Total Cost of Ownership (TCO.) This is because Open Source does
not address the stafng costs associated with deploying and maintaining a BI
solution, which according to IDC can constitute 60% of a three-year TCO.
Speci?cally, Open Source BI generally requires more con?guration and
integration, as the solutions are typically far less integrated and require
general programming skills to con?gure – thereby resulting in higher stafng
costs. Because of these factors, Open Source provides little more than 10%
savings on a three-year TCO versus traditional on-premise BI vendors.
In contrast, the Software-as-a-Service (SaaS) delivery model is predicated on
automation and pre-integration, directly targeting the largest areas of cost
for BI solutions. Cloud delivery completely alters how software is provisioned,
con?gured and deployed and ofers signi?cantly greater TCO advantages.
Comparing the TCO of Cloud BI with both traditional and Open Source BI
solutions reveals dramatic cost reductions – as much as 70% or more.
Executive Summary
4
WHITE PAPER
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 con?gure 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-pro?t institutions, a
revenue model for these ?rms 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 ofering lower license costs, the solutions similarly
require the customer to buy and manage hardware and install, integrate,
con?gure and manage several distinct software components.
Cloud BI
In contrast to traditional and open source solutions, Software-as-a-service
enables a completely diferent software delivery model. Cloud providers
sell software, but also maintain responsibility for hardware, installation,
provisioning and integration in a hosted environment. Consumers of Cloud
solutions typically require nothing more than a browser. Cloud 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 efective?
In this paper we ?rst review the three primary delivery models for BI:
traditional, Open Source and Cloud. We then establish a TCO model by which
we can evaluate the three ofering types. Finally, the three BI ofering types are
evaluated at a summary level against this model. A more detailed TCO analysis
can be found in the appendix.
Executive Summary
5
WHITE PAPER
The process of converting raw data into useful business intelligence suitable
for business decision making involves signi?cant 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 stafng
related (initial build and annual stafng). In fact, for larger deployments,
the percentages skew even more towards stafng costs. According to IDC,
project stafng 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, con?guring, 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 additional software licenses. Lastly, required system downtime for
hardware and software updates results in lost productivity costs. In addition
to the IDC and Birst TCO models, companies have continually validated that
stafng costs are the highest percentage of the TCO of a BI solution.
Elements of a Business Intelligence
Deployment
More than
half of the
total cost of
a BI solution
over three
years is
stafng
related.
According to
IDC, project
stafng costs
account for
approximately
60% of
the 3-year
total cost of
ownership
of a typical BI
project.
6
WHITE PAPER
Elements of a Business Intelligence
Deployment
According to a white paper by Business Objects and Crimson Consulting Group
on TCO:
• In addition to initial build and ongoing maintenance stafng 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
?ve 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
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 stafng costs.
7
WHITE PAPER
TCO of Traditional BI Solutions are
Dominated by Stafng Costs
As shown repeatedly in the studies above, the total cost of ownership for
traditional business intelligence solutions are dominated by stafng 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 speci?c 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 speci?c purpose and all of which must
be manually integrated to create a complete solution for every project.
This requires purchasing, setting up, con?guring, and maintaining multiple
products and then declaring the same logical entities in each of them – and
making sure those de?ned objects work together as expected across all the
products. Given the time required to get that right, it is not surprising that
stafng costs easily outstrip the license cost of the software in the TCO for
traditional business intelligence solutions.
8
WHITE PAPER
Similar to traditional BI solutions, Open Source BI platforms are comprised
of multiple, disparate products that require signi?cant efort to install,
integrate, con?gure and manage. As a result, Open Source BI solutions
require similar stafng expenses to traditional approaches. Because the
TCO for BI solutions is dominated by stafng 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 diference in TCO after ?ve 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 sufer from the same
challenges (separate tools, diferent 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 stafng 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 con?guration 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.
Open Source Software Lowers Software
Costs, While Raising Others
9
WHITE PAPER
Open Source Software Lowers Software
Costs, While Raising Others
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 signi?cant efort 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 diferent 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 training and running
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 work?ow. 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 diferent and divergent
developer teams. There are ?ve 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 stafng costs during both the initial
deployment and for ongoing system maintenance.
Never has
Open Source
been able
to channel
multiple
independent
projects
into a single,
coherent
solution.
10
WHITE PAPER
Open Source Software Lowers Software
Costs, While Raising Others
Open Source Challenges: Programming 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 de?nitions and Java technologies. This requires
technical depth and places a signi?cant burden on BI implementers to develop
Java programming and platform integration skills – thereby creating stafng
challenges and further increasing stafng 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 speci?c java interface class).
The de?nition 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:
I’m a newbie. When I tried modifying the HelloWorld.xaction with 2.0.0
release, I encountered a couple of difculties:
• I thought I was using the “fle-based repository”, but I still found it
necessary to log into the admin console at http://localhost:8099, select
Administration » Services » Solution Repository » Refresh. Once I ?gured
this out, changing that xaction ?le to “I did it” actually worked.
• That %quote thing really bothered me. There was no HelloWorld_
en.properties in the Pentaho Solutions so it never put anything there. If
you want to use that %quote function and there is no such ?le, just create
it in the same folder with the line:
I think the Plug-in Installation paragraph is out of date. You can download
the plugins here:
• SourceForge (Design Studio) contains the above mentioned
1. org.pentaho.designstudio.editors.actionsequence_X.X.X.X.zip
2. org.pentaho.designstudio.editors.core_X.X.X.XX-0.zip
11
WHITE PAPER
Open Source Software Lowers Software
Costs, While Raising Others
• SourceForge (Report Design Wizard) contains legacy version of pentaho-
report-design-wizard-XXX.zip (replacement for the above mentioned org.
pentaho.designstudio.editors.core_X.X.X.XX-0.zip)
I’m new to Pentaho and just becoming acquainted with it so I don’t know
what happened with the Report Wizard. Maybe the wizard is not included
in the .core or .actionsequence package.
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 de?nition 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 ?eld has
an associated Java class and associated expressions that are built with Java
expression and method invocation syntax.
12
WHITE PAPER
Cloud BI: Reducing TCO by 70% through
Automation and BI Virtualization
Unlike traditional and Open Source BI platforms, Cloud BI was designed to
radically reduce overall costs by providing a fully-integrated software suite
that automates much of the manual con?guration required by other tools. For
example, Birst was developed as an integrated solution by one development
team with one goal: enabling faster, easier BI 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
and schema, the full and incremental ETL routines required to populate that
schema, and the metadata that describes the 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 efort between
designing the logical model and building the reports and dashboards for
the end users. Through the use of automation enabled by a fully-integrated
platform, Birst radically lowers the stafng costs required for a BI project both
in initial build and in annual stafng costs.
In addition, because Cloud solutions share hardware 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
Cloud solution providers manage their systems to the highest uptime and
performance standards, customers using Cloud BI solutions will also see a
signi?cant reduction in downtime expenses as de?ned above.
For purposes of comparison, consider a typical BI implementation with 50
users, 10-15 diferent 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.
“ By providing
new levels of
abstraction
and
automation,
SaaS can
reduce TCO
by 70% or
more.”
—Joe Bugajski,
Senior Analyst, Burton Group
13
WHITE PAPER
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 efort 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 Cloud solutions deliver.
Logical Business Model
This is really the core of a BI solution. It includes the business de?nitions 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
de?nition of how these logical entities relate to physical data source.
Best-practice BI solutions start with the de?nition of the business model ?rst
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 de?nition 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
A Detailed Breakdown of Costs
14
WHITE PAPER
A Detailed Breakdown of Costs
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 involves 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 diferent
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 ?ow. 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 de?ned in the ETL tool, separate from the downstream BI
tool. This results in redundant metadata and signi?cantly 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 ?ow. It utilizes the same
business model elements and de?nitions that are used in reports and
dashboards and therefore does not require the redundant metadata or
con?guration that exists when utilizing general-purpose data movement
tools. Because schemas, sources, targets and metadata elements do not need
to be de?ned, the amount of work required to implement transformation and
cleansing logic is signifcantly 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, ?le or cube
structure that is required to contain the data for analysis purposes. This
structure must be designed to support:
• Analytical fexibility – 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 data that change over time in order to analyze
sequences and identify patterns and trends. The schema must be able
to support storing and querying both current and historical versions of
important business data.
15
WHITE PAPER
A Detailed Breakdown of Costs
• Performance – creating an efcient structure where, regardless of the query,
the system can quickly bring together results from diferent places in order to
serve up the results
In the world of data warehousing, generally this involves converting an
original, normalized schema, into a de-normalized one speci?cally 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:
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
• Slowly changing dimensions (SCDs)
• Surrogate keys
• Dimensional snowfakes
• Proper indexes and indexing strategies
• Data partitioning strategies
• Missing value record creation
Building and designing these components takes highly specialized skills and
can take a signi?cant amount of time. Shortcuts on data model 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 these manual steps by completely automating
the physical schema creation and management. By understanding the
logical business requirements through the de?nition of the logical model,
Birst automates the entire process of design and implementation of physical
schemas while providing all the bene?ts 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 diferent phases: initial
load and incremental load. The initial load typically includes historical data
16
WHITE PAPER
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 diferent 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
provides the best mechanism for moving data into the database. Source data
typically needs to be formatted in a very speci?c way and bulk loaders can be
very ?nicky 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 schema. The required staging tables need
to be designed and maintained.
• Dimension table loading – needs to ensure that the uniqueness constraints of
dimensional attributes are maintained and that required surrogate keys are
created. Also, linkages to any other snow?ake tables must be set up.
• Fact table loading – loading facts from staging tables. Needs to ensure that
all relevant key relationships to dimensions are established and maintained
(often requiring lookups.)
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 efciently 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 efect
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.
A Detailed Breakdown of Costs
Given Birst’s
automated
loading, the
process of
constructing
the ETL scripts
and routines
to accomplish
the initial
load is
eliminated.
17
WHITE PAPER
A Detailed Breakdown of Costs
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 running 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
de?nition and calculation are critical. In addition to being important, they can
also be very complex. Some metrics might seem simple to calculate at ?rst,
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 speci?ed 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 difcult 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 rede?nition 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 ?exibility 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 de?nitions (with instant deployment)
to ensure their correctness and utility (minimizing development time and waste).
Report and Dashboard Design
Reports and dashboards have two very diferent end-user use cases. Reports
are designed to pack a lot of richly formatted information for broad-based
18
WHITE PAPER
A Detailed Breakdown of Costs
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 ?t into a narrower slice of screen
real estate but allow for interactive ?ltering 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 diferent products
requiring potentially signi?cant re-work in order to address all key users.
Moreover, many reporting and dashboard products are so focused on
formatting, that they require the end user to do a considerable amount of
con?guration 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 eforts for diferent user interfaces
create a large burden on BI designers. Birst, on the other hand, uni?es 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 reports and dashboards in Birst takes half the efort 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 ensure
predictable performance. Moreover, if relational databases are used, care
must be taken to separate database ?les onto diferent disk spindles from
database log ?les or database temp ?les 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 expenses and complexity for the needed
bene?t of uptime.
• A sufcient number of front-end web servers are required to shoulder the
end-user load. The more interactivity end users require, the greater the
demand will be on the web server. These machines must be relatively high-
end to handle concurrency.
Creating
report and
dashboards
in Birst takes
half the efort
required with
traditional BI
products.
19
WHITE PAPER
A Detailed Breakdown of Costs
• 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
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 across many customers.
Software Installation and Con?guration
Software installation and con?guration is one of the most under appreciated
categories. It is not uncommon to hear stories about eight week installations
for mainstream BI products. Consider that for many organizations all servers
need to conform to an IT-certi?ed image. That image includes a known set of
software, service packs, drivers, etc. It is rare for standard enterprise software
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, con?gured and managed:
• Application servers (e.g., WebLogic, IIS, Webshere, Tomcat, etc.) – this
includes base software installation along with things like port con?guration,
SSL and certi?cate management, authentication infrastructure, logging,
clustering, failover, etc.
• Database servers – signifcant costs exist in setting up and maintaining
analytical databases including database storage strategies, partitioning,
authentication, backup, clustering failover and recovery
• Single sign-on confguration
As a fully-managed service, none of these pain points exist with Cloud BI
and Birst.
Training
With fewer parts of the product exposed and requiring training, Birst’s training
modules can be more focused and efcient as a result, end users can be
productive in far less time and for far less money.
Elimination of
many of the
most painful
elements
results
in a 70%
reduction in
stafng and
management
costs for SaaS.
20
WHITE PAPER
Annual Management and Stafng (Three Years)
Eliminating many of the most painful elements results in a 70% reduction in
stafng 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 (frewall, routing, bandwidth, etc.)
• Asset management/accounting
• Cluster management (redundant hardware, failover testing, etc.)
All of these items are included with Cloud BI and Birst.
A Detailed Breakdown of Costs
21
WHITE PAPER
A Detailed Breakdown of Costs
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 fle management
For cube data stores, index and ?le 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 use and scope of BI needs to adapt. New metrics,
new data sources, and new business rules and priorities become important.
These priorities must be understood and de?ned. Once de?ned, the BI solution
needs to accommodate them ?exibly and quickly. 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 manual modi?cations of existing schemas and load
routines. Birst automatically propagates required 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 dashboard solutions are constructed by one or
more individuals for consumption by a diferent set of individuals. Those
who consume the reports and dashboards (and potentially ad hoc analysis)
are shielded from the actual 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 modi?ed, and data/ and metadata can be added,
deleted or altered at will without disrupting a production instance.
22
WHITE PAPER
A Detailed Breakdown of Costs
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
con?guration. Examples of items which may be diferent in a development
environment include:
• Data source defnitions
• Hierarchies
• Metric defnitions
• Security rules/flters
• ETL processes
• Schema defnitions
• Reports
• Dashboards
When the time comes to promote 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 de?ned in a development
instance may not be the same users de?ned in a production instance, but
the metric de?nitions and reports should transfer. Moving the metadata
over appropriately and synchronizing these systems can require signi?cant
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. A report is typically
highly formatted with multiple views, aggregations and levels of detail
present. Reports are often meant for ofine 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.
Birst virtualizes
the BI
application
infrastructure
and makes
it easy to
maintain
multiple
instances
simultaneously.
23
WHITE PAPER
A Detailed Breakdown of Costs
• 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 interact with the data presented. Best-of-breed dashboards provide
a high level of interactivity and allow end users to ?lter, sort, drill, and
generally navigate through various views and visualizations of data.
• Ad Hoc/OLAP Analysis – For power users and business analysts, there is a
need for a richer tool for exploring data and ?nding 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 that 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,
con?gured, deployed, and integrated. Also, metadata must be duplicated
and synchronized, and training must be extended to deal with diferent user
interfaces. This signi?cantly 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, dashboards, 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 ?rst to ensure
patches occur as planned.
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.
Birst
eliminates
the need
to manage
system
backup and
recovery.
24
WHITE PAPER
Patches generally involve in-place application. Software upgrades are
generally more serious and difcult to manage. Upgrades often involve
serious revisions to the process and require signi?cant 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 ?xes 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 ?rewall), but within the ?rewall
security is an issue. Systems where BI software is installed require anti-virus
and internal ?rewall 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 speci?cally tuned to
work with the given installed software packages), internal encryption and
secure certi?cate 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
difcult to test or audit.
Birst provides backup and disaster recovery as part of the Cloud BI service.
In addition, 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.
A Detailed Breakdown of Costs
25
WHITE PAPER
Hardware Costs
Hardware provisioning for BI can be a challenge. Unlike operational
systems, where every user screen generates a well-de?ned 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 Cloud 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 difcult to
consume ?nancially. License software requires larger upfront payments that
are typically recognized as capital expenditures. 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 ofered 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.
A Detailed Breakdown of Costs
26
WHITE PAPER
A Detailed Breakdown of Costs
Downtime
Loss of productivity can be expensive. The power of business intelligence lies
in its ability to allow business users to monitor operations closely and make
critical decisions based on facts. After an organization builds those capabilities
into their normal business processes, the removal of such a capability can
paralyze an organization, rendering it even less efective 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 signi?cant infrastructure investment.)
27
WHITE PAPER
About Birst
Birst is the leader in agile business analytics. It ofers a single place to manage all of a business’ analytics and agility
to answer questions that span departments, data sources, and deployments—across both public or private Clouds.
Birst gives users the fastest way to answer their most pressing business questions—and then all the ones they didn’t
know to ask. At one-third the cost, time, and staf of traditional big BI, Birst brings the bene?ts of analytics and fact-
based decision-making to a much broader audience. For more information, visit www.birst.com.
Birst Inc.
153 Kearny Street
San Francisco, CA 94108
Call toll free: (866) 940-1496
Email us: [email protected]
www.birst.com
Conclusion
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
signi?cant 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.
doc_195466336.pdf