1

OOrraaccllee''ss BBII AApppplliiccaattiioonnss

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.

WWhhaatt iiss aa BBII AApppplliiccaattiioonn?? 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.

2

WWhhyy CCrreeaattee aa BBII AApppplliiccaattiioonn?? 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.

WWhhyy SShhoouulldd YYoouu CCoonnssiiddeerr tthhee OOrraaccllee PPrree--BBuuiilltt BBII AAppppss?? 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:

3

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

BBuuyy VVss.. BBuuiilldd 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

4

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.

CCoommmmoonn MMiissccoonncceeppttiioonnss 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

5

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

6

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.

TThhee PPeerrcceeiivveedd CCoonnss 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

7

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.

BBII AAppppss vvss.. aanndd EEDDWW 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.

8

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.

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

JJJJJJJJeeeeeeeeffffffffffffffff MMMMMMMMccccccccQQQQQQQQuuuuuuuuiiiiiiiigggggggggggggggg