Oracle's BI Applications

OBI EE (Siebel Analytics) is a powerful enterprise capable BI/Reporting/Analysis tool that is

rapidly gaining solid market share and recognition. This is despite Siebel's (and to a lesser
extent) Oracle's lack of marketing it is a pure play platform. The will sell it to you, but it's not
really their focus.

If so, then what is? The answer is BI Applications.

BI Applications, whether you believe it or not, are the future of Data Warehousing and
Business Intelligence. Just as the mid sized and large companies throughout the world have
adopted large ERP, CRM, Billing, and HR applications, so to will the world adopt BI
Applications. Siebel was one of the first to preach this message, and now Oracle is preaching
it as well, although on a much larger scale, with significant development and marketing
resources behind it.

This two part post will overview BI Applications in general, but focus on Oracle's BI Apps. It
will cover the whys and whats, pros and cons of a pre-built data warehouse & BI system.

What is a BI Application?
In a generic sense, it is simply a complete pre-built BI and Data Warehouse system. It
encompasses ETL, a data model, a technology platform, metadata and pre-built analyses and
reports. Just download the software and the application configuration files, install, load the
data and you are ready to go. In some cases it really is that simple.

A full BI application, such as Oracle's, contain everything professionally done by an

engineering team at the direction of not only technical experts, but also industry and
functional experts. A basic BI application goes far beyond "industry standard data models",
and would include all necessary ETL, data model, BI tool MetaData, and pre-built reporting
content. Some may even go further to include change data capture or integrations with other
consumers such as front end applications, portals, advanced data services, or even other BI
tools.

Within Oracle's world of applications, there is some potential for confusion given their names.
Oracle presently sells three different OBI EE base applications; 2 of them are called Fusion
Intelligence (there is one for Oracle EBS & DBI, and another for PeopleSoft & JD Edwards).
Note that these applications are officially not part of Oracle's direction, and will not be
actively pursued. Instead Oracle is focusing on it BI crown jewel, the poorly named BI
Applications. It is these BI Applications, which include nearly 50 modules such Applications
as Marketing Analytics, Partner Analytics, Service Analytics, and Sales Analytics that this
post is discussing.

1
Why Create a BI Application?
The answer is identical to why we have ERP systems today. SAP, PeopleSoft, Oracle EBS,
Baan, Siebel, Clarify, etc were all built with the same thought in mind: a customer can buy a
fully functioning system instead of going through the risk, cost and delay of building it
themselves. It just started with the front end systems first. Now that the vast majority of the
fortune 2000 companies have standardized on one or a few ERPs, the ability to make a pre-
built BI system becomes possible. Only with clearly defined data models existing through out
so many companies is cost effective to have pre-built ETL, and with pre-built ETL comes the
vast majority of the benefit of the BI Apps from an effort perspective.

Why Should You Consider the Oracle Pre-Built BI Apps?

If you are reading this post, then you are at least somewhat interested in Oracle's BI offerings,
in particular OBI EE. If you have one or more of the supported source EPR packages (Oracle
EBS, JD Edwards, PeopleSoft, Siebel, SAP, and call center switch data), then Oracle's BI
Applications will pose an even greater interest.

There are numerous benefits to Oracle's BI Apps, but many, such as UI integration, security
integration and the like, really boil down to the same thing: they save you effort. Everything
that the BI Applications provide does so using the base technology platforms, which means
you would be able to do yourself. The difference is that Oracle Engineering has done a vast
amount of work for you.

But what effort are we actually talking about? It boils down to everything that a large scale
data warehouse and BI system would need to do, from start to finish. The real benefit of the
BI Apps are the many components and tasks that have been completely or mostly built that
will require little to no effort on your part. These include:

Requirements Analysis
Naming Standards
Source System Analysis
Change Data Capture Design
Extract, Transform and Loading design and coding
ETL orchestration / Architectural Foundation (sequencing, record tracking, restarts, index
management)
Generic integrations to non-supported data sources
Robust Target dimensional data model
BI tool configuration - MetaData
Reports and Dashboards
Alerts / Delivers / iBots
Real-Time integrations
Testing
Deployment Bundling

As a bonus, you will benefit from additional capabilities or qualities that would be difficult to
impossible for you to reproduce on your own:

2
 Functional and industry experts and industry best practices input into functionality, ranging
from metrics to dashboards
Simple UI integration with source applications - enable BI as an object inside your ERP
systems
Benefits of industry leading experts for architecture and design
Benefits of a vast testing and certification process covering numerous deployments across a
large number of customers and platforms
Designed to be fully upgradeable with new features, data sets and technologies
Application technical support staff
Relative availability of experienced resources working with the BI Applications
Pre-built 3rd party integrations

Many of these things you may not realize are needed as part of your DW/BI deployment. As
you begin to plan a new data warehouse or data mart, these tasks will need to be considered in
order to make a fully functioning system.

One common example of this is ETL Orchestration. ETL is much more involved than
scheduling a series of source to target mappings. Necessary items such as process dependency
checking, multiple schedule coordination (e.g., Daily and Weekly ETLs), restarting of a failed
process, parallelization, change data capture, and integration with index management are all
items that you will have to design, build, test and determine how to monitor and manage.
With the pre-built BI Application, this work is already done for you.

Each of these tasks takes a significant amount of time. Each task carries with it significant
risk. Multiply this risk by your team's ability and experience levels in each area, and you
begin to see why many BI / DW project fail, die after a short while, cost significantly more
than planned, or take much longer than planned.

Buy Vs. Build

The decision is a classic Build vs. Buy. If you have an ERP system, you have already sided
with the Build side of the argument at least once. Why was that purchase made instead of
custom building it in PowerBuilder, ColdFusion, .NET or Java? Most likely it boiled down to
the critical mass of arguments in favor of the Buy argument:
Less time & effort to deploy
Reduced risk, due to lower effort time and higher quality levels
Quicker ROI
Upgradeablity
Application Support
Availability of technical resources familiar with the application
Advanced features that you would be hard pressed to reach
Developed and tested by a robust engineering group

These benefits all apply for the BI Applications, albeit at different importance levels for each.
As you may already know, DW and BI require very different skill sets from traditional
application development, and frequently take years of practice to become proficient. Beyond
expertise in a BI or ETL tool, complex architectural and design challenges are where the real

3
difficulty lies. These challenging areas are precisely where you want to apply your strongest
resources. When purchasing an application, these difficult challenges have already been
solved and thoroughly tested and tuned.

The two benefits for the Buy decision that stand out the most are reduced time and effort, and
reduced risk.

Oracle's marketing statements and sales pitches about getting a BI application up and running
in weeks is not an exaggeration; it is something we see at Metricpshere everyday. Install,
make adjustments for your ERP customizations, load the data, make a few new reports and
you are done in weeks and not months. If you are building out your ERP, deploying without
analytical, summary, and trending capabilities may simply not be an option. The only realistic
way you can achieve such capabilities shortly after (or in conjunction with) an ERP
deployment is with the BI Apps.

As for reduced risk, the vast majority of the hard work is already done and thoroughly tested
and tuned. As a result, deploying BI Applications has a low enough risk profile and is so
similar across customers that Metric sphere is able to offer fixed price contracts to get you up
and running on the BI Apps in 4 weeks, or 12 weeks if you have significant alterations and
differing needs.

The great thing about the BI Apps is all of the things that come with it that go beyond simple
source to target mapping in a BI Tool. As outlined above, even if you need only a small
portion of one of the BI Apps, your architecture and infrastructure is Industrial Strength. This
allows you to easily grow into new modules and functionality over time without having to
revisit the foundational components and processes.

Common Misconceptions
Before I cover the Cons of the Buy decision, I want to discuss a few common misconceptions.

It works only with the pre-built data sources:

The Oracle BI Applications are fully designed to add new data sources to the BI Apps with
less effort than in a Build scenario. Using a publish-subscribe model, data can be extracted
from any source application that maps to existing objects in the BI Apps. After the extraction,
a feature called Universal Adapters pick up this data and continue transforming and loading it
into the target BI Application.

I am limited to the Applications I buy:

The BI Applications are built on a 100% open platform; there is nothing that cannot be
extended. Do you have a reporting need on some data that is not associated with the BI
Application that you purchased? Then simply develop the mappings as you normally would,
and plug them into the robust infrastructure as another work stream.

The key point here is that they in no way shape or form lock you in to just the code that you
have purchased. In fact, one could purchase a BI Application, delete all of the BI Application

4
specific code, and use the platform and infrastructure to build a 100% custom data warehouse.
That bears repeating: you can use the platform as simply a pre-built infrastructure and do
whatever you want with it (assuming you get the correct licenses). As mentioned in the first
post, ETL infrastructure is commonly overlooked when building a new data warehouse.

In reality, most BI Apps deployments bring in other data from other sources, be they some
other ERP, external data, spreadsheets, or custom developed internal applications. If
flexibility is a primary concern, you can fully consider the BI Apps as a starting point, with
the ultimate direction determined by non BI App content and needs.

Application Vendor's BI Applications are lightweight

This is true for many of them. In fact it was true of Oracle's own offerings before the BI Apps
7.9 came along. However, the BI Apps that Oracle now offers are far from lightweight. These
applications are built using industry best practices on relational platforms that scale as large as
the database can handle. I have been involved with a multi Terabyte implementation of the BI
Apps on the TeraData, DB2 and of course Oracle platforms.

Unlike other prepackaged BI applications from other vendors, Oracle's uses the same design
techniques, tools and platforms that you would use if you were starting from scratch. If you
feel comfortable with relational databases, Dimensional Models and Informatica, then you can
feel comfortable about the BI Apps. Whatever you can do with those tools by yourself in a
Build scenario you can also do with Oracle's BI Apps in the Buy scenario. Additionally,
Oracle adds some functionality missing from Informatica, namely ETL Orchestration (in the
form of the DataWarehouse Administration Console - the "DAC").

As an example of the complexity that you can build into your BI Apps system if needed,
consider a global organization with 2 different types of ERPs, each physically located in 6
data centers around the world. Additionally, there is more customer data residing in smaller
applications residing throughout. All 12 instances of the ERPs need to be smoothly integrated
into one data warehouse, even overcoming potential data issues such as records appearing
randomly on more than one ERP, linking records across ERPs, and a very complex security
model. Although far from trivial, this exact scenario has been performed using the BI Apps
with appropriate extensions and customizations to handle the additional logic. Many of the
customer's needs were very different from the pre-built code and configuration, but the BI
Apps were able to adjust to handle extremely complex requirements.

With regards to the flexibility of the BI Apps, a point that hits upon the advantages of
Relational OLAP vs. MultiDimensional OLAP (Cubes) deserves discussion. Adding new
dimensionality to perform metric analysis in the BI Apps is a relatively simple exercise of
adding a new dimension to an existing fact table, a fact table which can handle dozens of very
rich dimensions. Cube based systems generally do not operate in this manner; there are limits
to how many dimensional attributes you can add to a cube before it bogs down and something
else has to be removed. Not so with a enterprise capable ROLAP engine like OBI EE.

Finally, with the capabilities of OBI EE, the OBI Apps are extremely broad focused. When
CRM heralded the 360 degree view of the customer; this mantra was carried over to the first

5
iterations of what is now the BI Apps. 360 degree view means breadth and depth, and wide
and deep analysis capabilities are enabled by the OBI EE platform and were taken advantage
of in the BI Apps. In practical terms, this allows analysis of a variety of different metrics,
each from different sources and different processes to be analyzed simultaneously. This is a
capability that is severely lacking in most BI applications due to technology platform
constraints or weakness of their application. Additionally, this capability of the OBI EE
platform is the reason that this blog exists; I write about its ability to deliver real BI as
opposed to a just a bunch of reports.

The Perceived Cons

With any decision, there have to be some cons, especially if we are talking about the real
world.

The biggest and most common "Cons" associated with a Buy decision are cost, applicability
to your specific business requirements, and flexibility to meet future needs outside of
purchased functionality.

Cost
The discussion on costs is typically based on high capital costs associated with the software
and infrastructure, with some lesser costs coming from implementation. A license for a BI
App dashboard is significantly more expensive then a base license for and empty Oracle
Dashboard. But this is of course an apples to apple pie discussion; one is raw materials the
other is a finished product.

To make a better comparison, consider the real costs of building not a comparable system, but
a less powerful, flexible, feature rich and scaleable system that meets you exact needs. Don't
forget to add in the commonly overlooked infrastructure components that you will need to
have. The apple metaphor breaks down, but maybe consider comparing a house vs. raw
materials and tools. If you were to build a house by yourself, would it be as good as a house
made by experts? Would it have all of the features, advanced materials and advanced
engineering that the construction company and architect would build into it? Not a chance. So
even comparing your home made house to a pre-built house is not really a fair comparison, as
you will have a significantly better house if you buy one.

In most common cases, when you add everything up you'll find that the cost of the BI
Applications and associated licenses is far less than it would take you to build such things on
your own. When you factor in labor costs to customize the application based on your specific
environment and requirements, the equation ratio changes only slightly. Plus, factor in the
cost of the difficulty in doing it on your own, from missed functionality to delayed timelines,
to non-extensible architectures.

Ability to Address your Current and Future Requirements

Obviously there is great variability in requirements for each BI/DW need, even within the
same industry. However, when discussing analytical capabilities out of your ERP, the range
of possibilities is greatly reduced. There are three main categories where your requirements

6
may differ from the OOB BI Applications:

Your ERP is heavily customized: If this is the case, there is still tremendous benefit to the
OOB BI applications, even though you do have to modify them accordingly. The
infrastructure is still used, and in reality most of your data objects will be unmodified or
lightly modified, requiring little to no customization during the build of your BI Applications.

Your Reporting and Analysis requirements are different: This can be open ended to some
extent, but what does that boil down to? The BI Applications bring data objects over on a
transaction by transaction level, so that all appropriate information is available in the BI
Applications Data Warehouse. As this data is being extracted, adjustments can be made to it
to alter its structure to support a different set of analysis needs with a relatively low amount of
effort. Any gaps in the pre-built reports and Dashboards can be quickly overcome with
minimal effort. In fact, many implementations do not us the pre-built reports and dashboards
at all; instead creating their own customized content on top of the already substantial data
stack that has been leveraged. Changing the reporting content, in comparison with the much
larger efforts of other portions of the project, is akin to repainting the house a different color.

Additional data or complex metrics: If much of your need comes from outside the pre-built
ERP mappings, you will have to determine if they map to the same objects that exist in the BI
Apps (e.g., Customer, Employee, Order, Partner, etc). If so, you will be able to use the
Universal Adapters functionality and leverage 95% of the existing infrastructure. If not, and
there are substantial amounts that are not, then perhaps the benefit is not as great. However,
do not overlook the infrastructural components that the whole BI Apps package brings with it.
Complex metrics will usually be created with a combination or ERp & non-ERP data, and can
be plugged into the existing large scoped data model with little more than incremental effort.

In summary, if OBI EE can do it, then so can the BI Applications. If you need to build it on
the back end, it can be done using the tools included in the BI Apps stack. Specific point
solutions such as a name and address scrubber can be integrated into the overall loading
process to extend functionality.

BI Apps vs. and EDW

I hope to this point that I've discussed the benefits and realities of the BI Apps sufficiently. As
a thought experiment, consider what would happen if one or more of the Oracle ERPs systems
continued to grow throughout a company, adding new modules, retiring legacy systems along
the way. Eventually, it might be possible to have the majority of your operating data in your
ERP(s).

What then would the difference be between a central Enterprise Data Warehouse (EDW) and
the data warehouse in the BI Apps (called the Business Analysis Warehouse, or BAW)? They
would be pretty close in what they can do, as they would both have atomic level data from the
ERP. An EDW might have other data sources added to it, giving it more coverage than the
BAW. But wait, those sources can be added to the BAW as well.

If this is the case, then there is no difference from an EDW and the BI Apps data warehouse.

7
Can't the BAW become the EDW? If so, then a central EDW is not needed, but more
importantly, it does not have to be built. In essence, an EDW can be bought.

Although for the majority of customers this is a stretch, as only some of their data is in their
ERPs. However many medium sized businesses have grown so fast that they do not have an
EDW, or at best a poor one. By considering moving to Oracle's EPR systems, they have the
opportunity to get a pre-built EDW by purchasing the BI Applications. Of course additional
sources will be needed, but the benefits are there, the flexibility is there, and the capability is
there.

Although this sounds ridiculous to some, it can and will happen for some customers. Just as
years ago no one thought that packaged apps would rule the world, the same thinking
shortsides the potential of the pre-built, standardized BI system.

Disclaimer
At Metricsphere we work not only with the Oracle BI Apps, but also with the base OBI EE
platform. In other words, we are happily doing projects on both the Buy side as well as the
Build side. Personally, since I like a challenge, I like doing it the hard way and build them
from scratch. It's a lot more fun to do something hard than something easy. That being said,
Oracle makes a very compelling argument for their BI Apps, one that I think potential
customers should give a serious look at.

I hope this post put the BI Apps in a new perspective for some, and opens the door of
possibility for others.

Jeff McQuigg