Summary: Oracle Data Integrator (ODI) has been a viable integration option for Oracle EPM for over a decade. Considering that the technology space has changed dramatically during this time, this article takes a closer look at the needs of today’s EPM users. The goal is not only to point out some short comings of ODI, but also to discuss some innovative ideas to improve EPM integration and automation processes.
This article is based on the experience from many complex Hyperion integration projects and being a training instructor and curriculum writer since 2010 for 123Olap’s class “ODI for Hyperion Applications”.
A Brief History of ODI
Do you remember HAL? (If your answer is no, you can skip this paragraph except for the last sentence in this paragraph). During my first Hyperion Planning project back in 2006, I had the pleasure of working with a tool called Hyperion Application Link (or HAL). This was a fairly simple tool used to build powerful processes. Despite some limitations it was a widely used application, until Oracle decided in 2007/2008 that it was time to introduce a much more powerful tool: ODI. Truth is, ODI’s capabilities exceeded HAL’s by far, but users were missing the ease of use that HAL offered and were facing a much steeper learning curve trying to migrate to ODI. Once a user became familiar with ODI, it was a great tool to build powerful integration processes for EPM and the existing Knowledge Modules (KM) helped expedite the implementation process.
A Key Benefit of using ODI over other ETL tools
A decade ago, ODI had one specific advantage over other ETL tools like Informatica and IBM DataStage (which also offered Hyperion adapters). This advantage was called “Declarative Design” which meant that ODI separated the What from the How. This allowed users to separate the business logic (What to do) from the specific technical implementation (How to do it). What was great about this setup was that a user could easily maintain the mapping logic while a more technical user or administrator could ensure the process was functional and improve performance if needed. To put this in perspective, other ETL tools require the user to split functionality which are logically combined into different steps to perform operations like extract from source, apply joins and filters, aggregate data etc.
Declarative Design was a great benefit over other tools in the market as they allowed functional and technical resources to work together more closely and let each provide their relevant knowledge – a key advantage for the Hyperion/EPM product suite which thrives on this type of collaboration.
ODI 12 brought disappointing changes for EPM
For KScope16, I had prepared a hands-on training lab to show how ODI 12 could be used for Hyperion integrations. This was a disappointing and cumbersome experience because Oracle had removed the feature I found so relevant for EPM in the prior versions of ODI: the Declarative Design approach. Rather than allowing business and IT to collaborate, the user interface was much closer to that of all the other ETL tools. I’m not sure if Oracle’s EPM product team had similar thoughts on this, but the next Hyperion on-premise release, 11.1.2.4, was still using ODI 11.
Today, more than 3 years later, we are close to the next Hyperion release: 11.2. With this release there are currently no Knowledge Modules (KMs) for Hyperion planned. This means the integration options for Oracle EPM/Hyperion will change. Sure, there is still FDMEE which provides excellent mapping capabilities if a customer requires those, but direct integration with its many advantages seems to be off the table for now.
This article asks a provocative question: it sounds like ODI won’t be the right choice for EPM anymore, but let’s take a look from a different perspective.
Has ODI ever been the right choice for EPM?
Considering that ODI has been used by many organziations around the globe, this might seem like an odd question. But truth is that ODI had never been built for EPM. The existing KMs were a good way to allow ODI to interface with EPM and this enabled users to implement many solutions. However, there were some core features missing that a great EPM integration tool should have offered, for example:
- tighter integration with Hyperion/EPM products
- an easier user interface that less technical administrators and users would understand with ease
- follow a similar approach as HAL had offered with a much more manageable learning curve (many ODI implementations are just scratching the surface of what could have been done if ODI was more intuitive to use)
- the ability for end users to launch processes on demand
- a less technical experience migrating objects and managing different versions
- simplifying the configuration of MaxL support (this had become more and more challenging over time)
- etc.
Bottom line: ODI was not built for EPM. Its Hyperion adapters provided decent capabilities that made integration possible, but its complex setup prevented many users from fully building the great solutions they had in mind. Also, there were many showstoppers from building truly integrated solutions.
A Look to the Future of EPM Integration
Despite the new on-premise release 11.2, there is a big push towards Oracle’s EPM Cloud. Integration and automation with the cloud applications (PBCS, FCCS, ARCS etc.) is almost entirely based on REST APIs, and on-premise applications are providing more and more of those as well. While ODI 12 supports REST API calls, there is no reason to use ODI over any other integration tool anymore as the Hyperion Knowledge Modules have been discontinued. These KMs provided significant advantages as they provided a basic feature set for “Application Intelligence” – as the FinTech Innovations team calls it.
What is “Application Intelligence”?
The idea behind Application Intelligence is to provide a much tighter integration between an integration platform and the applications with which it integrates. In the case of EPM, this means that the integration platform should “know” about key artifacts of an EPM application:
- Which Plan Types exist? Which dimensions do they have?
- What are the available Business Rules, Substitution Variables, Dimension Members?
Besides the artifacts, there should also be more advanced integration options to simplify the how data is loaded, how kickouts are identified and how unexpected errors are handled.
These are just some of the many features of ICE Cloud, the Integrated, Compliant and Efficient Cloud!
About ICE Cloud
Replacing an existing ODI implementation with ICE Cloud is an excellent approach for any organization that is interested in truly transforming their Finance and Accounting processes. But honestly that’s just the tip of the “ICE” Berg. Our focus is not just EPM, but also all of its associated up- and downstream systems. Stay tuned for our next articles to learn more – or contact us today to schedule a demo and transform your EPM experience.
And as always: If you love your EPM system, you will love it even more with ICE Cloud!
