Everything Oracle

Introduction

In this article we’ll contrast and compare three different OBIEE solutions:

Custom Build

Fusion Intelligence

BI Applications

With a custom build solution you get the OBIEE software, but it’s up to you to build the repository that maps your data sources onto the repository Presentation layer, and it’s also up to you to create the end user reports based on this Presentation Layer. You have complete flexibility in your ability to use the wide range of OBIEE supported data sources, either alone or in combination.

With “Fusion Intelligence” you get the OBIEE software plus a pre-packaged repository and a pre-packaged set of reports for a particular data source, either E-Business Suite or PeopleSoft. For example, a particular member of this family is “Oracle Fusion Financials Intelligence for E-Business Suite” – note, this product should not be confused with “Financials Intelligence”, a reporting component that is built into E-Business Suite. You have complete flexibility in your ability to merge non-supported data sources into the repository and produce consolidated reports.

With “BI Applications” you get the OBIEE software, a pre-packaged repository, and a pre-packaged set of reports (everything you got with Fusion Intelligence), plus, in addition, a Business Analytics Warehouse, Informatica ETL, Data Warehouse Administration Console (DAC) ETL orchestration, and a custom set of data warehouse tables and ETL processes for a number of different data sources. BI Applications is also called “Oracle Business Intelligence Fusion Edition”; for example, a particular member of this family might be called “Financial Analytics Fusion Edition” or, in abbreviated form, “Financial Analytics” – if the product name contains the words “Fusion Edition” or the word “Analytics” then it belongs to the BI Applications family. You have complete flexibility to produce consolidated reports from non-supported data sources, either by merging those data sources into the OBIEE repository or by populating the data warehouse tables using your own ETL processes.

The sales blurb from Oracle and its partners often gives the distinct impression that BI Applications is a carefully crafted, “best of breed” product. But the feedback from BI Applications developers is not quite so "glowing", with complaints about poor indexing, the inordinate length of time it can take for Informatica ETL loads, and the large numbers of redundant columns that adversely affect query performance. So look on BI Applications as a template that will need some pruning and optimization before it will be production ready.

You can think of Fusion Intelligence as “BI Applications Lite”. With Fusion Intelligence, OBIEE connects directly to the data warehouse /summary tables that are built into the supported ERP product, whereas with BI Applications, an external data warehouse is first populated from the ERP product’s transaction tables, and then OBIEE connects directly to this external data warehouse.

You’ll read a lot about OBIEE and BI Applications, but very little about Fusion Intelligence. It isn’t marketed with any vigour, and I get the distinct impression that Oracle regrets giving birth to it in the first place, and is quietly trying to phase it out. The reason for Oracle’s apathy seems to be that, for the supported products, Fusion Intelligence often provides users with an adequate and much cheaper solution than BI Applications, and, more importantly, the existence of Fusion Intelligence also interferes with Oracle’s grand plan to strip BI reporting and its supporting structures out of its ERP applications – this can’t happen until users migrate to BI Applications. Oracle seems keen to force users to choose between a custom build and a BI Applications solution, even when the latter duplicates functionality that is already available within the ERP products supported by Fusion Intelligence.

These OBIEE offerings are like Russian dolls, one sitting inside another. Each offers you more functionality than its predecessor, but at a higher price in terms of the licence fees that you’ll have to pay.

Oracle: BI Revenues

The first thing to understand when choosing between these options is that what is in Oracle’s interest is not necessarily in yours. Oracle has already made the investment in acquiring / developing these three solutions, and its interest lies in maximizing the return on this investment. Licence fees for Fusion Intelligence will be higher than those for OBIEE standalone, and they will be higher for BI Applications than for Fusion Intelligence (by a factor of about 500% per application user). So Oracle, or any business acting on a commission basis, will have a strong incentive to sell you a BI Applications solution.

Look at it this way. Suppose the total cost of ownership (TCO) for a custom build and a BI Applications solution was exactly the same. In the first case, you would pay a modest licence fee for the OBIEE software and you would spend a substantial amount on the custom build. In the second case, you would pay a substantially higher licence fee for BI Applications and much less on customizing the software to meet your requirements. The choice is cost-neutral as far as you are concerned, but since the cost of the custom build won’t impact Oracle’s “bottom line”, Oracle has a strong incentive to sell you the BI Applications solution.

So when it comes to procurement beware of “siren voices”. If you are looking for external advice, make sure the consultancy does not have an agenda that favours one solution over another – if the only comparisons made are between a custom build and BI Applications, and there is no mention of Fusion Intelligence, then beware.

But medium term “bottom line” considerations are not the only factors involved in the push towards BI Applications. Oracle also has in mind the cost cutting that will result when it achieves its longer term goals.

Oracle: Future Direction

The second thing to understand is the direction in which Oracle is travelling with regard to BI reporting. Oracle is moving to a new business model, and the three different OBIEE solutions are stepping stones that will help Oracle to migrate you “from where you are now” to “where Oracle wants you to be”.

For many years Oracle’s business model was one of “offering all things to all businesses”. It built – or more often acquired – software products to meet various business needs and then marketed these products with the aim of persuading businesses to rely entirely on Oracle for their business software requirements.

But in recent years Oracle has changed its tune in favour of a “mix and match” approach, in favour of a business model that offers a complete Oracle solution, if you want one, or a partial solution, if you do not – a partial solution that will fit in seamlessly with the product offerings from other software vendors. One driver behind this change in direction is the realization that market dominance is not realizable, and that in a mixed vendor environment the “bottom line” is strengthened by supplying part of a business’ computing requirements rather than by supplying none. The other driver is the acquisition by Oracle of some very large and well known brands in the early 2000s, brands such as PeopleSoft, JD Edwards, Siebel, and Hyperion. A rapid absorption of these products into the Oracle product set was neither practical, due to the scale of the endeavour, nor desirable, due to the impact that damaging the well established brands would have had on Oracle’s revenue stream.

In the days when Oracle marketed the E-Business Suite as its single ERP solution it was a good idea to build a data warehouse into the product in the form of Daily Business Intelligence, and then to use this data warehouse for bundled reporting. Now, however, as Oracle is the proud owner of many different ERP/CRM offerings, it faces the task – in the long term – of consolidating all these offerings into a single product line, while, at the same time, minimizing the considerable costs of maintaining and upgrading very similar product lines in the interim.

To minimize costs Oracle has decided on a single BI reporting front end. OBIEE is that front end, so Oracle wants its user base to discard ERP specific reporting tools and to move over to using OBIEE instead. Since, in many cases, users are using ERP built-in reports with little or no customization, there is no prospect of ERP users building an equivalent set of reports from scratch using OBIEE. Fusion Intelligence offers a solution by providing a set of reports with equivalent, or better, functionality to that available in a particular ERP product. Migrating to Fusion Intelligence reporting from in-built ERP reporting is not such a large step, and it offers businesses a carrot in the form of a facility to integrate data from other data sources into their existing ERP reports.

Unfortunately, Fusion Intelligence doesn’t get you to where Oracle wants you to be. Fusion Intelligence makes use of a data warehouse or summary tables built into a supported product. But Oracle still has the problem of maintaining and upgrading these data warehouses or summary tables. As a further step in the consolidation process it makes good sense – from Oracle’s perspective – to build a common data warehouse – welcome to BI Applications. In this scenario, the pre-packaged OBIEE repository and reports connect to the consolidating data warehouse, and the consolidating data warehouse is populated by ETL processes that extract data directly from ERP transaction tables, bypassing the ERP product’s own data warehouse / summary tables. When users have migrated to BI Applications, Oracle is in a position to remove the built-in reporting and data warehouse support from its ERP products (of course, Oracle will offer maintenance support for the foreseeable future, but we can expect it to stop offering upgrades and enhanced functionality).

The problem with BI Applications is that, in its current form, it is a transitional product. If you were building your own data warehouse you’d populate it with data from just those tables and columns that were needed for reporting, and you’d optimize the indexing and ETL loads accordingly. But BI Applications has to map a disparate set of applications from different vendors onto a single set of data warehouse tables. The inevitable result is a set of tables, each of which has a vast number of columns, most of which you will never use in any of your reports. The consequences of such a generic, “lowest common denominator” solution are inevitably waste and poor performance from an “out of the box” implementation. Cutting BI Applications down to size can take some effort – unfortunately, Oracle does not provide a configuration utility in which you can select just the reports that you are interested in and which then strips out from BI Applications all elements that are not dependent on the selected reports.

Oracle’s next step will be to rationalize the transaction level aspects of its various ERP solutions. Expect this to take place behind the scenes initially as different ERP products begin to share table structures and processes, while still providing distinctive interfaces to end users. Eventually, when the Oracle brand name dominates that of the acquired brands in the minds of IT purchasers, we can expect a single consolidated ERP product that will replace the current E-Business Suite, PeopleSoft, JD Edwards, and Siebel offerings.

Bear in mind that it will take at least a decade to complete this transition to what we might call “E-Business Suite Mark II”. Your current BI reporting requirements are almost certainly going to be on a much shorter timescale. It’s in Oracle’s interests to push you along its long term migration path as fast as possible – the greater the uptake, the sooner Oracle can complete the transition and reduce its cost base. However, it’s much more likely to be in your business interests to move along this migration path at a more leisurely pace. Moving along too quickly is likely to be expensive and to add little by way of new functionality that will bring significant business benefits, even in the medium term. So, when it comes to the brave new world of Oracle BI, caveat emptor.

Total Cost of Ownership, Risk, and Time to Value

Total Cost of Ownership

The total cost of ownership will depend on (1) the initial one-off cost of either a custom build or product customization; and (2) the annual recurrent cost of licence fees and product maintenance.

Let’s start by comparing a custom build with the other two pre-packaged alternatives. In the case of a custom build, there will obviously be a considerable one-off cost that must be met up front. However, a pre-packaged solution will certainly have to be customized to meet your needs, and this can also incur a substantial up front cost. So the critical question is this, “What fraction of your reporting requirements can be met out of the box, or by modifying the existing reports, repository, and, for BI Applications, the data warehouse and ETL processes?” If you only need to lightly customize a pre-packaged solution then you might save up to a third on the cost of the equivalent custom build; with heavy customization the savings will be substantially less. You’ll need to evaluate what reports are available and how closely they match your requirements before deciding which option is best for your business.

In terms of annual recurrent costs, licence fees for a custom build will certainly be lower than for the pre-packaged alternatives, especially in the case of BI Applications. Product maintenance costs for a custom build may also be lower. With a custom build your developers will understand the application thoroughly since they have built it from scratch. But with a pre-packaged solution your developers will only get to understand the minimum needed to customize the application to meet your immediate needs, leading in subsequent years to an additional learning curve when the application is enhanced.

Now let’s compare Fusion Intelligence with BI Applications. One-off costs will be substantially higher for BI Applications since in addition to customizing the repository and the reports, you’ll also have to customize the data warehouse, and the ETL processes. Customizing the data warehouse elements will be time consuming, particularly if the source application has been highly customized.

In terms of annual recurrent costs, product maintenance costs for BI Applications will be higher than for Fusion Intelligence since there’s more functionality to maintain. Licence fees for BI Applications will also be significantly higher than for Fusion Intelligence (by a factor of about 500% per application user). Moreover, where BI Applications can hit your budget particularly hard is in terms of resourcing. With a custom build or a Fusion Intelligence solution the additional skills that you’ll need will be in two areas: OBIEE repository development and report construction. With BI Applications, in addition, you’ll need expertise in the Business Analytics Warehouse, Informatica ETL, and DAC ETL orchestration. So you need to factor in the annual staff costs of the additional developers that you’re likely to need with a BI Applications solution. These costs may well add significantly to your recurrent expenditure.

Project Risk

How likely is your BI project to come in on time and within budget? When it comes to risk, then a custom build will score higher than a pre-packaged solution. But not necessarily that much higher. If you’re not building a data warehouse, but simply building a repository and creating reports, then a custom build can be performed in incremental steps: you can map the data source and build the reports in stages – there is no substantial up front development effort that needs to be put in place before you can start delivering the goods. If you are building a data warehouse as well, then the risk will be much higher as the number of prerequisites that must be completed before reports can be delivered will be significantly higher.

The project risk for BI Applications will be higher than for Fusion Intelligence as it requires more customization, and a more diverse set of developer skills will need to be brought on board.

Time to Value

If we define “time to value” (TTV) as the time taken to deliver all your reporting requirements, then which solution will come in first will depend on your configuration. For example, if you have E-Business Suite in place and are comparing a custom build against the DBI, Fusion Intelligence against the DBI, and BI Applications, then the TTV for Fusion Intelligence might be half that for a custom build, and the TTV for a custom build might be half that of BI Applications (customizing a data warehouse can be expensive).

If we look at “time to first value” (TTFV) – the time taken to deliver some of your reporting requirements – then the TTFV for Fusion Intelligence and a custom build will be similar – if you’re not building a data warehouse but using one that is already built into an ERP product (such as E-Business Suite), then the mapping of a subset of tables and the creation of the corresponding reports can be rolled out pretty smartly. So what you’ll need to consider here is both the urgency and the extent of your reporting requirements.

Which OBIEE Solution is right for you?

There is no easy answer to this question. The interactions between the total cost of resourcing an OBIEE solution, the additional licence fees, and the potential reduction in licence fees for your existing reporting solution can be complex – you’ll need to do your “home work” before making a decision. To give you a feeling for the issues involved we’ll examine a number of different scenarios in this section.

Non-Supported Application with In-built Data Warehouse

Let’s suppose that the application is not E-Business Suite, PeopleSoft, JD Edwards, Siebel, or SAP. Let’s assume that it comes with a data warehouse with ETL processes in place. In these circumstances, you’re very likely to be best off with a custom build. Your developers import the metadata to the OBIEE repository, map it, and create the reports. Total project resource requirement might be 6 man-days per report and the development timescales might be 0.25 weeks per report.

However, if the subject areas for which the reports are required corresponded closely to those supported by Fusion Intelligence, your developers might be able to map most of the tables and columns to the equivalent ones within Fusion Intelligence. If your developers could do most of the remapping within the Physical and Business Model layers within the repository and make only a few changes to the Presentation layer, then you would be able to use most of the Fusion Intelligence reports without any changes. Of course, there would also be the additional cost of the Fusion Intelligence licence.

Non-Supported Application with no In-built Data Warehouse

Unless the data volumes are small then you’ll need a data warehouse or some sort of summary tables / materialized views to achieve a reasonable level of performance. Adding summary tables to the application may provide a quick fix – OBIEE has an Aggregate Persistence Wizard that can help to automate this process. But for larger data volumes you’ll benefit from a data warehouse.

For a custom build of the reports, repository, data warehouse, and ETL processes, the total project resource requirement might be 20 man-days per report and the development timescales might be 0.8 weeks per report.

Tailoring BI Applications might be an option if your developers can readily map the application’s tables and columns onto BI Applications’ Business Analytic Warehouse. But licensing BI Applications is going to cost a great deal more than licensing the individual components. So, unless Oracle comes up with a special licensing arrangement to cover this scenario, you’ll probably be better off with a custom build.

Single Supported Application with an In-built Data Warehouse

Let’s suppose the application is E-Business Suite or PeopleSoft. Here you have three alternative build options.

For a custom build of the reports and repository, the total project resource requirement might be 6 man-days per report and the development timescales might be 0.25 weeks per report.

If the application is lightly customized and you only want to make modest changes to the pre-packaged reports, then for a Fusion Intelligence solution the total project resource requirement might be 2 man-days per report and the development timescales might be 0.125 weeks per report. This would represent a very considerable cost saving, and it would almost certainly still be cost effective when you take into account the cost of the Fusion Intelligence licence.

The key issue here is the degree to which the in-built reports that come with Fusion Intelligence already meet your needs. If you only need a modest number of extra reports, perhaps to combine data from other sources with your application’s data then a custom build will be fast and cheap. If the new reporting requirements are more extensive then Fusion Intelligence is probably a good bet.

For a BI Applications solution, the total project resource requirement might be 6.5 man-days per report and the development timescales might be 0.4 weeks per report – similar to the total resource requirement for the custom build. When you take into account the hefty licence fee for BI Applications, then BI Applications would seem to be a non-starter.

However, one important factor that you need to take into account when considering BI Applications is whether by using it you could reduce the licence fee that you pay for your ERP application. If you’re already paying a supplementary licence fee for reports built into the ERP application (say, “Financials Intelligence” in the case of E-Business Suite), then by moving to BI Applications you may be able to eliminate this cost. As the licence fee for bundled reporting can also be hefty, the net result of a reduction could make a BI Applications solution much more attractive. An important caveat here is that you’ll probably need to migrate all your users from bundled ERP reporting to OBIEE, so this solution is unlikely to work if you just intend to use OBIEE to meet additional reporting requirements.

You also need to consider the possibility of reducing the bundled reporting licence fee in the case of a Fusion Intelligence solution. The question here is whether the supplementary licence fee for bundled reporting applies just to the use of the ERP reporting tools or also to the use of the summary tables that support them. Even if the summary tables needed for Fusion Intelligence are included in the bundled licence fee, you may be able to take out licence bundled reporting for a minimal number of ERP users, which would still allow you to use the summary tables as a data source for Fusion Intelligence. As the cost per application user for ERP bundled reporting can be five times that of a Fusion Intelligence licence, the reduced licensing costs might, over time, pay for your Fusion Intelligence project.

As always with any cost comparison you need not only to work out the total resource requirement in man-days but also to read the “nitty-gritty” of the licensing T&Cs offered by Oracle for the various product options that are on offer.

Multiple Supported Applications

Let’s suppose you use multiple applications from amongst those supported by BI Applications, two or more from E-Business Suite, PeopleSoft, JD Edwards, Siebel, and SAP.

For a custom build of the reports, repository, data warehouse, and ETL processes, the total project resource requirement might be 20 man-days per report, and the development timescales might be 0.8 weeks per report.

If the application is lightly customized and you only want to make modest changes to the pre-packaged reports, the total project resource requirement for a BI Applications solution might be 6.5 man-days per report and the development timescales might be 0.4 weeks per report.

BI Applications is clearly a winner in terms of total resource requirement, but when you add in the differential in the licence fees the gap may narrow considerably depending on your user profile and configuration.

An alternative here might be to do a custom build and leverage the data warehouses / summary tables built into the component applications. Multiple data sources will add complexity to the repository but will have no impact on the time taken to develop the reports. The total resource requirement might not be much greater than that for a BI Applications solution, and overall, when the high cost of the BI Applications licence is taken into account a custom build might reduce your total cost of ownership.

However, the problem with using OBIEE to combine multiple data sources in real-time – rather than using ETL processes to combine them offline – is that OBIEE will have to send multiple subqueries to the respective data sources and combine the results. Even if these subqueries return only a small number of rows, you’ll still not get the same level of performance that comes from a properly constructed data warehouse. So unless data volumes are small and the concurrent user load is light, you’ll be better off “biting the bullet” and going for a BI Applications solution.

Summary

When it comes to choosing an OBIEE reporting solution it’s a case of “horses for courses”.

If you’re in doubt, and you’re considering a Fusion Intelligence or a BI Applications solution, then you’d be well advised to do a trial installation, to examine the reports that are on offer and to determine to what extent these reports, with modifications, would meet your reporting requirements. This analysis should make it much easier to rule in, or to rule out, a custom build.

If you decide to go for a BI Applications solution beware of some of the figures for productivity gains that you’ll see touted about by some consultancies looking for your business. Beware of comparisons that exclude any discussion of Fusion Intelligence. And, especially, beware of comparisons that focus exclusively on the total cost of project resourcing and fail to take into account the cost of the relevant licences based on your user profile and configuration. Not to do so is very much an “apples to oranges” comparison, usually designed to push you in the direction of a BI Applications solution. Adding in the budgetary implications of licence fees over the life cycle of a BI application can yield a dramatically different perspective on the viability of different BI solutions. So caveat emptor.

Everything Oracle

Home

Everything Oracle