WHITE PAPER Comparing the Total Cost of Ownership … PAPER Comparing the Total Cost of Ownership of Business Intelligence Solutions How Cloud BI Can Reduce TCO by 70% versus Traditional

WHITE PAPER

Comparing the Total Cost of Ownership of Business Intelligence SolutionsHow 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 Staffing 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 Staffing (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 financial results . Unfortunately, providing this insight using traditional BI software has proven to be costly and resource intensive and in many cases fails to meet project and end user expectations .

Open Source business intelligence has emerged over the last several years as a potential way to address the cost issue . However, while Open Source BI may save money on 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 staffing costs associated with deploying and maintaining a BI solution, which according to IDC can constitute 60% of a three-year TCO .

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

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, configured and deployed and offers significantly 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 configure the software for use . Given that these license fees for several categories of software may be very high, Open Source has emerged as an alternative source for software .

Open Source BI

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

Cloud BI

In contrast to traditional and open source solutions, Software-as-a-service

enables a completely different 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 effective?

In this paper we first 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 offering types . Finally, the three BI offering types are

evaluated at a summary level against this model . A more detailed TCO analysis

can be found in the appendix .

Executive Summary

5

WHITE PAPER

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

More than half of the total cost of a BI solution over three years is staffing

related (initial build and annual staffing) . In fact, for larger deployments,

the percentages skew even more towards staffing costs . According to IDC,

project staffing costs account for approximately 60% of the 3-year total cost of

ownership of a typical BI project .

In this model, initial deployment costs include the costs of designing, scoping,

installing, configuring, implementing, quality controlling and training related

to a BI deployment . Ongoing management costs include continued application

evolution (new end-user reports/dashboards, new calculations, new data

sources, etc .), system management and administration and general system

maintenance . Infrastructure costs include the costs of the physical hardware as

well as any 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

staffing 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 staffing related. According to IDC, project staffing costs account for approximately 60% of the 3-year total cost of ownership of a typical BI project.

6

WHITE PAPER

Elements of a Business Intelligence Deployment

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

on TCO:

•Inadditiontoinitialbuildandongoingmaintenancestaffingcosts,onaverage each physical server requires 0 .25 full time employees (FTE) to manage

•AnaverageBusinessObjectsdeploymentof25reportstakesapproximatelyfive FTEs 90 days to deploy

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

•MostBIdeploymentstakebetween45and140man-daystocomplete

•MakingasinglechangetoanexistingBIreporttakesonaverage3.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 staffing costs .

7

WHITE PAPER

TCO of Traditional BI Solutions are Dominated by Staffing Costs

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

•Procure,setupandmaintainhardwareandsoftware

•Developthelogicalmodelforthedatatobeanalyzedandthemetadatathatdescribes it

•Createaphysicalschemaforthedatathatsupportsthelogicalmodel’sdimensional analysis as well as the specific ETL routines required to populate and update that data

•Developthereportsanddashboardsthatprovidetheresultinginsighttobusiness users

•Continueservicingbusinessuserrequestsforcustomreportstappingnewdata sources

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

8

WHITE PAPER

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

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

Open Source Software Lowers Software Costs, While Raising Others

9

WHITE PAPER


Open Source Challenges: Lack of Product IntegrationOne of the core challenges of BI is that the industry grew up as a collection of point solutions that were slowly acquired by larger organizations who attempted to assemble them into “integrated” suites . Despite being able to purchase these suites from a single vendor, the products are generally not well integrated thus requiring significant effort to integrate and maintain those components over the project’slifecycle.ThisproblemisevenmoreacuteintheOpenSourcecommunitywhere 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–whichisaROLAPserverandissharedamongseveraldifferentOpenSource vendors and therefore cannot be completely integrated into any particular one

•Kettle–anotherprojectdesignedtoallowforlow-level,datatransformationandmovement . 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)

•PentahoReporting–aseparateprojectforreportingthatrequireslow-levelconnections to data sources . This project was formerly known as JFreeReport, another Open Source Java-based reporting tool

•Weka–aJava-baseddataminingsetoflibrariesandtoolsfortrainingandrunningvarious data mining algorithms, built and maintained by the University of Waikato in New Zealand

•PentahoBIPlatform–anotherprojectmaintainedbythePentahoteamthatadds additional components like workflow . It is built upon another Java-based developer studio, Eclipse, and requires integration with J2EE application server infrastructures

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

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

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

10

WHITE PAPER


Open Source Challenges: Programming ComplexityGiven that each Open Source solution grew up from a series of independent, Java-based developer communities, it is not surprising that Open Source solutionsretainthatprogrammer’smindset.Documentationisriddledwithreferences to Java class definitions and Java technologies . This requires technical depth and places a significant burden on BI implementers to develop Java programming and platform integration skills – thereby creating staffing challenges and further increasing staffing costs .

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

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

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

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

I’manewbie.WhenItriedmodifyingtheHelloWorld.xactionwith2.0.0release, I encountered a couple of difficulties:

•IthoughtIwasusingthe“file-basedrepository”,butIstillfounditnecessary to log into the admin console at http://localhost:8099, select Administration » Services » Solution Repository » Refresh . Once I figured this out, changing that xaction file to “I did it” actually worked .

•That%quotethingreallybotheredme.TherewasnoHelloWorld_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 file, 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(DesignStudio)containstheabovementioned

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


•SourceForge(ReportDesignWizard)containslegacyversionofpentaho-report-design-wizard-XXX.zip(replacementfortheabovementionedorg.pentaho.designstudio.editors.core_X.X.X.XX-0.zip)

I’mnewtoPentahoandjustbecomingacquaintedwithitsoIdon’tknowwhat 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 definition and fed directly to the Java compiler to build a custom Java class . As a result, in order to be able to build expressions of any complexity in Jaspersoft, a developer must have working knowledge of Java, Java classes and Java expression syntax . In fact, in the screenshot below, it can be seen that each text field has an associated Java class and associated expressions that are built with Java expression and method invocation syntax .

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 configuration 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 effort 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 staffing costs required for a BI project both in initial build and in annual staffing 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 significant reduction in downtime expenses as defined above .

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

“ 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 effort required to initially start up a BI project . By automating, pre-integrating and delivering as a service, large chunks of this work can be reduced or eliminated . We detail each step below and the reduction in TCO that Cloud solutions deliver .

Logical Business Model

This is really the core of a BI solution . It includes the business definitions of all data elements that will be used to build reports and dashboards and conduct analysis.ThisincludesallrequiredmetricsandKPIs,hierarchies,levelswithinthose hierarchies, level keys and business attributes . It also includes the definition of how these logical entities relate to physical data source .

Best-practice BI solutions start with the definition of the business model first and then proceed with implementing that business model . The work required for this phase is dependent upon deep knowledge of the business and questions being addressed . This is where the unique skills of a business analyst or BI developer are leveraged . Generally speaking, this business definition is independent of whatever tool is used to implement it .

Source Data Transformation/Cleansing

Data rarely comes from a single, fully integrated source system or in a form that can be simply aggregated (summed or counted) in order to generate the required business metrics . Most often data needs to be cleaned and

A Detailed Breakdown of Costs

14

WHITE PAPER


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 cleansingisaccomplishedusingindependentETLtools(e.g.Kettle.)Thesetools 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 different data output . These ETL tools provide low-level mechanisms to move data between arbitrary locations and manipulate it during the process . As a result, they can be used for transforming and cleansing data as part of an analytical data flow . In addition, they can be used for moving data from one system to another and for the integration of transactional systems . This generality comes at a cost of complexity, redundancy and lack of integration . All schemas must be independently defined in the ETL tool, separate from the downstream BI tool . This results in redundant metadata and significantly increased complexity . Such ETL tools have their own metadata, developer model, methods, syntax, libraries, etc . They require additional training and expertise . Moreover, redundancy creates greatly increased risk when modifying elements as all downstream impacts must be analyzed and compensated for . Changing one source column in a source database requires the examination of ETL metadata along with that of the downstream reporting and analysis metadata .

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

Physical Data Model

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

•Analyticalflexibility–itshouldbeobvioushowthisstructureistobequeriedin order to produce the broadest range of analytical results

•History–ahugereasonfortheuseofanalyticalsystemsistobeabletosave 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


•Performance–creatinganefficientstructurewhere,regardlessofthequery,the system can quickly bring together results from different places in order to serve up the results

In the world of data warehousing, generally this involves converting an original, normalized schema, into a de-normalized one specifically designed fortheabovecharacteristics.Infact,accordingtoRalphKimball,theauthorof“The Data Warehouse Toolkit”, founder of both Metaphor and Redbrick Systems:

Onlyonestandardschemamethodologyexiststhat’scapableofexpressingdata 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):

•Facttables

•Dimensiontables

•Slowlychangingdimensions(SCDs)

•Surrogatekeys

•Dimensionalsnowflakes

•Properindexesandindexingstrategies

•Datapartitioningstrategies

•Missingvaluerecordcreation

Building and designing these components takes highly specialized skills and can take a significant 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 definition of the logical model, Birst automates the entire process of design and implementation of physical schemas while providing all the benefits of a full-featured modern star schema infrastructure under the covers .

Initial Load of the Target Schema

Once a physical schema is designed which allows for the calculation of all of the elements in the logical model, that schema must be loaded with source data . Loading that schema traditionally involves two different phases: initial load and incremental load . The initial load typically includes historical data

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 different techniques and challenges .

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

•Bulkloadinghistoricaldata–giventhedatavolumes,bulkloaderstypicallyprovides the best mechanism for moving data into the database . Source data typically needs to be formatted in a very specific way and bulk loaders can be very finicky with even the smallest deviations from properly formatted data (embedded carriage returns in strings, null columns, proper quoting, date/time formats, etc .)

•Stagingofdata–typicallydataisloadedintoastagingareafromwhereitcan then be loaded into the target schema . The required staging tables need to be designed and maintained .

•Dimensiontableloading–needstoensurethattheuniquenessconstraintsofdimensional attributes are maintained and that required surrogate keys are created . Also, linkages to any other snowflake tables must be set up .

•Facttableloading–loadingfactsfromstagingtables.Needstoensurethatall 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:

•Foreachdimension,detectingchangesandupdatingattributes.Forexample,detectingthatagivencustomer’saddresshaschangedandupdating the customer record appropriately . Doing this efficiently can be challenging and expensive to set up (checksum and other schemes can be deployed to ensure only the records that changed need to be updated .)

•Addingadditionalfactmetrics-fortransactionalinformationthatneedstobe aggregated, making sure that new items (like orders, shipments, etc .) are added to database .

•Recordinghistoricalsnapshots–beingabletoproperlyrecordsnapshotsofvarious attributes . This requires being able to save many versions of a given record (say, for example, a customer record where their status may change .) This allows for the analysis of changes in the status of records and the effect on various metrics or outcomes . Proper treatment of snapshot data versus transactional data is critical for most real business analysis as well as being able to easily manage snapshot policy .


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

17

WHITE PAPER


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 definition and calculation are critical . In addition to being important, they can also be very complex . Some metrics might seem simple to calculate at first, but after examination there is often more complex embedded business logic in these calculations that are important to take into consideration in order to arrive at a meaningful result . Two things are critical in being able to deliver these kinds of results:

•ApowerfulandexpressiveOLAPenginethatallowsforsophisticatedmetricsto be easily specified and calculated

•Aplatformthatallowsforrapidcreation,deployment,testinganditerationon metrics to ensure that the results are what the business needs

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

•Relationalanalyticssolutionshaveallowedforeasiercreationanddeployment 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-basedsystemshavepowerfulquerylanguages(e.g.MDX)thatareveryexpressive, but the redefinition of relationships often requires reloading and redeploying cubes and generally all the critical data is not loaded into a single cube, requiring the creation of yet another cube .

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

Report and Dashboard Design

Reports and dashboards have two very different end-user use cases . Reports are designed to pack a lot of richly formatted information for broad-based

18

WHITE PAPER


distribution in a format where users are meant to see the data as is with little to no exploration required . Reports can be printed and laid out in a pixel-perfect manner . Dashboards are designed to fit into a narrower slice of screen real estate but allow for interactive filtering and drilling such that users can “pull out” of a dashboard the information they need . As a result, in traditional BI suites, reports and dashboards are actually created with different products requiring potentially significant re-work in order to address all key users .

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

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

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

Hardware Setup and Provisioning

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

•AdatabaseserverwiththeappropriatediskI/Osubsystemsneededto 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 files onto different disk spindles from database log files or database temp files in order to prevent contention during analytical queries . It is very costly to set up a database server with the amount of memory and CPU needed .

•Shouldanyhigh-availabilityrequirementsexist,asecondaryservermustbeclustered with the primary one to ensure failover and recovery . Active versus passive clustering can add more expenses and complexity for the needed benefit of uptime .

•Asufficientnumberoffront-endwebserversarerequiredtoshouldertheend-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 effort required with traditional BI products.

19

WHITE PAPER


•Aload-balancinginfrastructureisrequiredtoensurethatusersessionsaremanaged across these various web servers seamlessly and that the system scales to the right number of end-users

•Backupanddisasterrecoverymechanismsneedtobeprovided

•Securityinfrastructuretosecure“withintheperimeter”isalsonecessary

Birst incorporates best-of-breed database infrastructure with redundancy and scalabilityaskeyfactors.Birst’smulti-tenancyallowsthecostsofthissortofinfrastructure to be shared across many customers .

Software Installation and Configuration

Software installation and configuration 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-certified 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, configured and managed:

•Applicationservers(e.g.,WebLogic,IIS,Webshere,Tomcat,etc.)–thisincludes base software installation along with things like port configuration, SSL and certificate management, authentication infrastructure, logging, clustering, failover, etc .

•Databaseservers–significantcostsexistinsettingupandmaintaininganalytical databases including database storage strategies, partitioning, authentication, backup, clustering failover and recovery

•Singlesign-onconfiguration

As a fully-managed service, none of these pain points exist with Cloud BI and Birst .

Training

Withfewerpartsoftheproductexposedandrequiringtraining,Birst’strainingmodules can be more focused and efficient 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 staffing and management costs for SaaS.

20

WHITE PAPER

Annual Management and Staffing (Three Years)Eliminating many of the most painful elements results in a 70% reduction in staffing and management costs .

Hardware Management

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

•Hardwarefailure/replacement

•Diskspacemonitoring/management

•RAID/SAN/Storagesystemmanagement

•Defragmentation

•OS-levelpatches/upgrades

•Networkmanagement(firewall,routing,bandwidth,etc.)

•Assetmanagement/accounting

•Clustermanagement(redundanthardware,failovertesting,etc.)

All of these items are included with Cloud BI and Birst .


21

WHITE PAPER


Database Administration

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

•Dataload/failuremonitoringandmanagement(andperhapsexecution)

•Indexrebalancing/tuning

•Index/tabledefragmentation

•Databasecopy/replication(e.g.testenvironmentversusproduction)

•Securityandsecuritypolicymanagement

•Databasefilemanagement

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

Logical Data Model Changes

As a business changes, its 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 defined . Once defined, the BI solution needs to accommodate them flexibly 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 modifications 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 different 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 modified, and data/ and metadata can be added, deleted or altered at will without disrupting a production instance .

22

WHITE PAPER


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

•Datasourcedefinitions

•Hierarchies

•Metricdefinitions

•Securityrules/filters

•ETLprocesses

•Schemadefinitions

•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 defined in a development instance may not be the same users defined in a production instance, but the metric definitions and reports should transfer . Moving the metadata over appropriately and synchronizing these systems can require significant overhead each time a “release” occurs .

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

New Report/Dashboard Design

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

•Reports–ReportingisthecoreofBIandthedominantmodeofinformationconsumption . 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 offline use and are generally designed to be printed for reference . Over the years, the banded report writer has become the de-facto standard for generating reports .

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

23

WHITE PAPER


•Dashboards–Dashboardsaredesignedtoprovideusersamuchnarrowerwindow 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 filter, sort, drill, and generally navigate through various views and visualizations of data .

•AdHoc/OLAPAnalysis–Forpowerusersandbusinessanalysts,thereisaneed for a richer tool for exploring data and finding answers . Dimensional OLAP tools (typically with a pivot table user interface) allow power users to sift through and segment data in arbitrary ways in order to analyze various segments . These tools generally require a higher degree of skill and are intended for a limited audience with deep knowledge of both the tool and data .

Given 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, configured, deployed, and integrated . Also, metadata must be duplicated and synchronized, and training must be extended to deal with different user interfaces . This significantly increases the scope and complexity of a BI project .

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

Software Patching and Upgrades

All computer system instances are moving targets . Over time, each layer of software becomes more and more out-of-date . Systems managers must choose when and if individual software patches are installed at each of the layers (operating system, database, ETL, reporting, 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 first 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 difficult to manage . Upgrades often involve serious revisions to the process and require significant planning and work to implement . Additionally, many vendors charge additional license fees for upgrades, while at the same time stopping the support of older versions of their products . Installations of software not on the current release do not receive patches and fixes as regularly (maintenance is generally de-prioritized) and therefore those systems are particularly at risk .

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

Security Infrastructure and Management

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

Backup Management and Disaster Recovery

Business intelligence environments are increasingly mission critical . As a result, system failure must be guarded against and recovery time can be important . A proper backup policy must be maintained and managed to ensure the system canberestoredifanysystemissueoccurs.Today’sregulatoryenvironmentalsooften calls for a proper disaster recovery mechanism to be in place for critical business systems . Implementing disaster recover can be very expensive and difficult to test or audit .

Birst 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 .


25

WHITE PAPER

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

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

Birst’smulti-tenantarchitecture(uniqueforCloudBIsolutions)allowsfora 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 CostsIn addition to the fact that the licensing model for major on-premise solutions can be very expensive, the licensing model itself is more difficult to consume financially . License software requires larger 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 offered as a service and therefore leverages a subscription model that not only costs less in aggregate over a three-year period than on-premise solutions, but can typically be included in operating budgets and does not require capitalization or depreciation .


26

WHITE PAPER


DowntimeLoss 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 effective than it was before the system was initially installed . Idle workers and wasted productivity is a huge soft cost .

Downtime comes from two principal sources:

•Planneddowntime–Duetodataloads,development-to-productionmigration, upgrades, etc .

•Unplanneddowntime–Duetosystemfailure

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

27

WHITE PAPER

About BirstBirstistheleaderinagilebusinessanalytics.Itoffersasingleplacetomanageallofabusiness’analyticsandagilityto answer questions that span departments, data sources, and deployments—across both public or private Clouds . Birstgivesusersthefastestwaytoanswertheirmostpressingbusinessquestions—andthenalltheonestheydidn’tknow to ask . At one-third the cost, time, and staff of traditional big BI, Birst brings the benefits of analytics and fact-based decision-making to a much broader audience . For more information, visit www .birst .com .

Birst Inc.153KearnyStreetSan Francisco, CA 94108Call toll free: (866) 940-1496Email us: info@birst .comwww .birst .com

Conclusion

ConclusionSincethelion’sshareofcostsinaBIdeploymentrelatetohumancapitalandintegrationcosts,Birst’spre-integratedandconsolidatedsolutiondrivessignificant 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 .

Documents

WHITE PAPER Comparing the Total Cost of Ownership … PAPER Comparing the Total Cost of Ownership of Business Intelligence Solutions How Cloud BI Can Reduce TCO by 70% versus Traditional