Oracle Data Integrator (ODI) Reviews

The Knowledge Module is the most valuable feature in our experience with it.

This product can be installed on a desktop or a server to be operated. v10 has a local database that allows you to train a client for its use. This, of course, provides good knowledge transfer.

v12 has good features, but it needs to be certified with Hyperion EPM. Also, the Knowledge Module needs to be improved because it is the backbone of ODI. When we change the Knowledge Module, Oracle will not support the change in production.

There have been no issues with the deployment.

We have had no issues with the stability.

We have had scalability issues that were mainly due to a bad environment. Also, if ODI is not setup for scalability, load balancing becomes an issue.

7/10 because it is hard to find someone who has ODI knowledge on the first line of support. Oracle takes a long time to respond and to provide a fix for issues. It takes, sometimes, up to eight weeks before Oracle will say that the issue is a bug.

We previously used Informatica when it was used with Hyperion, but it is not certified for Hyperion now. ODI is less expensive, and it can be installed on a desktop or a server for implementation. With ODI, you can do transformations on the source, staging or target databases.

For me, it was straightforward if installing it on a desktop. There is more complexity when installing it on a server. Agents are involved and in v10, it was not easy to install even the agents.

We implemented it with a vendor or sub-vendor team with help from the client.

The ROI is good.

Oracle has increased the licensing price for ODI.

Before implementing or designing, please have someone familiar with the product give their input. If your network is weak, the implementation may take more time.

We mainly use ODI to integrate all of our EPM applications, which includes Essbase ASO/BSO cubes, Hyperion Planning, DRM and HFM applications. Also it is used to manage a custom data warehouse developed in Oracle DB which is used as source for OBIEE reporting.

We use ODI to integrate all Oracle EPM suite used in our financial area. ODI is the core engine used to move data across different applications every day. It’s by far the most important architectural element in our BI/EPM environment since all data passes through it.

ODI has the ability to connect to virtually any technology out there. If it does not connect out-of-the-box, we can very easily add a new technology into it. This flexibility gives a tremendous developmental advantage to its users, which can use ODI as the official ETL tool for any kind of integration project.

Its Knowledge Modules (KMs) may abstract the “how” portion of integrations, allowing the users to focus on the “what” that needs to be done. It can be easily used by either young ETL developers or expert professionals.

For resumes, the ease of use for young professionals and its great development flexibility for expert professionals make it a great product to be used for every ETL project out there.

In my opinion, ODI should connect to ALL Oracle products out-of-the-box, but currently that’s not the case for all of them. Hyperion Financial Management (HFM) is one of the Oracle products for which Oracle decided to remove its ODI support in its last product version. In other words, if you wish to use ODI and HFM together, both from Oracle, you will need to create custom code, which does not make any sense to me.

Another area to improve would be the development life-cycle, which did improve in the latest ODI version, but needs further improvements.

More than five years.

ODI 12 version is very stable. It can manage several parallel executions/large volumes without much trouble.

ODI scales very well.

This is a delicate subject. My experience with Oracle support has both great and very bad situations. If the problem that you are facing is only related to ODI, then your chances of having a great Oracle support experience are good. But if your problem involves multiple technologies, like ODI integrating EPM apps, then it is probably going to be a nightmare (and, unfortunately, most of the problems that will require support assistance will involve “multiple technologies”).

This happens because Oracle supports different technologies with different teams and the communication between them seems complicated sometimes. Several times I was in a situation where teams would keep discussing who should fix the problem instead of actually fixing it.

I've always worked with ODI for ETL development.

The initial setup is extremely easy and straightforward.

ODI was the only option we considered.

I'm a technical manager and we provide technical services to our customers. We are partners with Oracle. 

This product helps our customers achieve their goals and objectives.

The best feature of this solution is the documentation. Everything is set out clearly with step-by-step instructions.  

I think Oracle should add more functions to improve optimization. Automation should be improved to enhance the product. Some of our customers carry out data comparisons between Oracle and other features and Oracle is lacking in some of those tools and features.

The stability and performance are good and our customers use the solution on a daily basis. 

The scalability is good, we have around 100 users. 

The initial setup really depends on the situation so it can sometimes be more complicated. When it comes to implementation, a deployment will usually take around 40 days and up to six engineers. 

I rate this solution seven out of 10. 

The most valuable feature is that it's bundled with all the other Oracle products. We use the ODI with BI Apps. It does all the ELT along with our data warehouse for BI purposes. That’s good. It comes as a bundled package. If we want to use the newest, latest version, we can install it separately.

It's very user friendly. We used to use Informatica; compared to that, it's easier.

The learning curve is a little less because if you are already in the ELT business, you know how it works. Overall, it's good.

I would like to see them make some more improvements on the troubleshooting side, to help with the troubleshooting because right now, the errors are not very clear. I think they are already working on it; it's in the latest release, but yet to be included in the BI Apps bundle.

It is still not as stable as the old BI Apps and ELT tools were, but it's getting there. BI Apps doesn't come with the latest ODI yet, but in the future, it might be better.

It works with Oracle Fusion, so it can be spread across the cluster. It's pretty scalable.

Technical support is good. That's the standard. It's good.

We upgraded because the old version was no longer supported. The new version comes with ODI, so we didn't have a choice. But, we like the product.

It didn’t come with any other option. However, even if we had another option, we would have gone with Oracle, because we are a big Oracle shop.

Initial setup is straightforward. If you are from a technical background, it's pretty straightforward.

We didn't actually look at anyone else. We looked at different Oracle partners who provided this software, but the product was Oracle from the start.

We learned some lessons, such as how to plan out the entire process, and so on. Oracle documentation is good. If you follow that, you should be fine.

When I’m choosing a vendor such as Oracle, support is the most important criteria.

• Direct infusion of statements to the database, which allows the full use of database capability
• Ease of creating data flow and transformation
• Flexibility on technology on transformation

My customers started to increase their ETL performance with great margins. This was especially the case when ODI was used with Exadata, which allows each statement to be executed much faster.

The main problem with ODI is that you have to create each step of the transformation as a new interface. A big data flow can have more than 100 interfaces, which can make it difficult to trace the data. However, in v12, this approach changed to become more flexible.

Another complaint is with the user interface performance -- as the work repository gets bigger, issues arise.

I've used it for seven years now.

We have had no issues with the deployment.

There have been no stability issues.

It has been able to scale for all our needs.

7/10

I have a lot of experience on Oracle environments. I've started to have projects with my client using Oracle solutions. In my experience, ODI is a tool that is 100% compatible with all Oracle environments.

I can say that the level of complexity of the initial setup is medium. It is not straightforward because each customer may need specific logic on ETL approaches, so this means that your Knowledge Modules are mostly customized. Although except after the first installation and environment definitions, it is pretty easy to do after that.

I am a part of a vendor team. I think the most important thing is to decide where to reside this tool and its agent. This architectural question will help in the future to execute ETL processes. Secondly, the naming standards of all projects, immediate tables, Knowledge Module and folder names etc. are pretty important. Thirdly, versioning is crucial. All these standards should be done at the beginning of your use.

The product has a wide range of options on licensing.

The Knowledge Module is the heart of this solution. If you have nicely written Knowledge Modules, then you will not have any performance issues. The language should be kept as common as possible and all in one solution. You can write in many different languages, but the maintenance will need a wide variety of knowledge in the future. This can be very tricky in the long term. Do not forget to clean temporary tables after each execution of ETL. Otherwise, the database will be full of unnecessary data.

Multiple data sources: "Most" of them, Oracle databases (some MS SQL, some Sybase, lots of files and some web services). Because the environment was overwhelmingly Oracle, ODI (we started from OWB) was a much better and cost-effective solution for us than Informatica.

Far more efficient and robust than OWB, (it was the natural evolution for us).

Separate environments for dev, test and prod from one management facility.

• Click intensive on mapping
• Lots of mouse clicking
• GUI could be improved.
  

Their code-once-use-everywhere approach for coding data flows. Unlike other ELT solutions, ODI allows for creating scripts ("modules") which are then shared across multiple data load processes. If you find a bug, you fix it once, and it is fixed for everyone. It is the same if you need to code a new feature. It is also worth mentioning that ODI supports over a dozen of scripting languages. Chances are that your favorite language is amongst them.

The main improvement was unifying and standardizing ELT processes. For example, each table in the EDW solution has a set of standard columns used solely for auditing, data lineage and debugging purposes. Because the code to support those columns is shared across the whole solution, we are now capable of getting the auditing information for every single piece of data in the entire solution, without having to code it individually for each stream.

The GUI is Java based, and is less than friendly. It feels a little bit like being in the late 1980s when I started using it. So I would say: hey, Oracle guys! Improve the GUI. Make it more intuitive. Snappier. Sleeker.

I've used it for three years.

Not really. There were some caveats when upgrading from one major release to another but that's expected with tens of thousands of highly customized ELT streams. Nothing that could not be resolved within a day or two.

It is Oracle. So, you get what you pay for. We used their customer support once or twice (for instance, when resolving incompatibility with certain versions of the JDBC driver) and got all our issues fixed.

I used DTS/SSIS, Cognos DM, and Informatica previously. They all have their little pros and cons. For ODI, the killer feature was the shared code. Plus, the whole EDW solution is built upon Oracle databases so it simply makes sense to use Oracle ELT tool.

Well, it is certainly not the "Run the installer, click Next Next Next Next and have it up and running" kind of an install. There are many types of ODI agents that need to be installed and tweaked on uncountable number of servers so it does take a while to get the whole thing functional. It is all well documented though. Don't expect any major issues here but make sure you book enough time for the initial setup.

We have implemented this with an in-house team. The main thing is to get one or two ODI gurus into your DEV team. ODI is built with unique philosophy in mind and if you try to start implementing your solution using your past (non-ODI) knowledge, you will get into trouble very quickly.

I have no idea. I was not involved in ROI related discussions. I can assume that because the tool is extremely stable and, once correctly implemented, runs practically without supervision, it is a good investment in a long run. But that's just my private guess.

Make sure you understand differences between ETL and ELT (ODI is the latter). Have a well-structured source data. And if you don't know anything about ODI, find someone who does before diving into your data-warehouse project. You can learn SSIS or Informatica yourself in days. This approach is not going to work for ODI.

High volume batch loads to move data from transactional systems into the decision support warehouse.

It worked fine, but we needed a tool that would include quality and master data seamlessly.  This is more of a standalone ETL tool.

I found nothing overly amazing about this tool, although I appreciate its ability to easily load slowly changing dimensions.

It lacks a suite of tools suitable for fully processing data and moving it into decision support warehouses.