Oracle's Bi Applications

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 prebuilt 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

8