The question of build versus buy is an old and much-debated topic in the field of Information systems and data-related technologies. Oracle has clearly been selling the “buy” proposition when it comes to building a metadata model in OBIEE (aka: Oracle Business Intelligence Applications or OBIA), and there are many great and valid reasons for this that I would like to discuss.
Back in 2006, I began my career in what would become the Oracle Business Intelligence Enterprise Edition (OBIEE) solution arena. Previous to that, I had been a Siebel CRM transactional system developer. So I definitely had a major advantage when it came to understanding the Siebel Sales BI application that my company purchased as part of Siebel Analytics. I knew all the Siebel CRM “base” tables from Siebel. In addition, I was able to easily understand what the Informatica jobs were doing in terms of pulling together information from Siebel and also what the “core” business model was doing in terms of further consolidating and organizing this information. This was really the ground floor of what was to become Oracle’s present-day “BI applications.”
Since those days, very little has changed about what comprises a BI application. BI application building blocks include:
- A pre-built set of real physical tables that are organized into a star schema
- A set of pre-built ETL code to load those tables
- A set of pre-built tables and triggers in the transaction system to pick up incremental changes to data
- A pre-built set of meta-data based on the star schema structure
These BI applications aren’t too complicated if you think about them this way, are they? Now, all you need to do is to vary the transaction system and – viola – you have what are known today as the Oracle BI Applications (OBIA):
- Oracle Sales Analytics (my favorite!)
- Oracle Service Analytics
- Oracle Financial Analytics
- Oracle HR Analytics
- Oracle Marketing Analytics
- Oracle Order Management Fulfillment Analytics
- Oracle Vertical (Industry Specific) Analytics
- Oracle Contact Center Analytics
- Oracle Supply Chain Analytics
If you vary the ETL tools as well, you will now arrive at Version 188.8.131.52 of the BI applications – where Oracle Data Integrator (ODI) becomes the centerpiece (and only!) ETL solution. Don’t worry…support for Informatica will be back soon! I can imagine there will be many customers skipping the ODI-only version of BI applications – especially if they have invested in an excellent ETL tool like Informatica.
So why purchase Oracle’s BI applications?
Here are some of the reasons we discuss with our clients when they are evaluating “build versus buy:”
1. Lower Total Effort.
Given what I know about Oracle’s Enterprise Business Suite (EBS), or even the transactional tables of Siebel CRM, I would never want to embark on building a data warehouse or an OBIEE from scratch – given that this has already been done by Oracle. The man hours alone to create a data warehouse would far exceed a year – and even then, you would not be in lock-step with Oracle’s team, who changes base tables quite often. With BI applications, you can deliver not only a data warehouse, but a metadata data model, along with multiple prebuilt applications in less than half the time it would take you to build it all from scratch.
2. Dollar Cost.
The caliber of technical personnel you would need to undertake such a project would be expensive. Whether you outsourced or hired staff, it would cost a small fortune to fund a “from-scratch” data warehousing and integration project that would even have a chance of being done within a single year.
3. You Can Customize It Anyway.
No organization exists today that has such generic needs generically setup for a transaction system that there is no requirement to customize a BI application (aka: there are always customizations based on the realities of the business you are in). Oracle does a great job of getting you most of the way there – and now you need to just fill in the gaps.
4. Pace of Technology.
Oracle maintains a small army dedicated to keeping the BI applications in synch with the latest and greatest changes that occur within their transaction systems. I’m not saying there are never bugs or issues, but by and large, they do a better job than any company could manage in-house of keeping things in synch – especially given the secret and proprietary nature of future versions of their tools. Internally, Oracle will already be developing the next version of the BI applications against versions of transactional systems that are not even out yet.
Author: John McGale, Performance Architects