Oracle Data Integrator (ODI) Review

ODI is a flexible tool that can adapt to fit your business, not the other way around.


Video Review:

Valuable Features

The biggest feature for ODI is the fact that it uses the power of the source or target database to actually perform the ETL processing. So a typical data integration tool might have its own ETL engine, and that would be an additional server, additional costs, something else you have to maintain. ODI actually has the ability to create and generate code that runs potentially on your Oracle database, or even on a big data target, on Hadoop or somewhere like that. So, you have that flexibility, and you don't have to have that additional cost in maintenance.

A couple other additional benefits of Oracle Data Integrator would be the use of what's called a knowledge module. So this is like a code template that uses the metadata that you have available within ODI, and within your mapping, to generate that code, that then can be executed, like I said before, on the source or target system. The code will be generated in the native format of that database or that technology. So, again, you have sort of a hands-off.

These knowledge modules are built in. They can be developed and modified. So, the biggest thing, I always think, with ODI is, it fits around your data warehouse needs. Rather than taking your production, or your business, and trying to make it fit a tool, you do the opposite. You make the tool fit your business.

Room for Improvement

One thing that is included, and it's going to improve, is the integration with a configuration management tool. Right now, they integrate with Subversion. And we know in the future, there's going to be more tools implemented there for configuration management and some new features there. So right now, it's kind of one of those features that, it's been released, but it's sort of a beta version of that feature where a lot more functionality will be coming down the line.

Stability Issues

So ODI is actually quite a stable product. As a testament to the product team that develops it, they're not going to release something that is extremely buggy or things like that. So, I do see that often they will release features that are highly anticipated and highly sought after. And they might release them a little early. So there's definitely patching that comes into play there, to kind of get the full solution there.

As far as stability, the Oracle Data Integrator has agents that run either in WebLogic, as a Java deployment there, or on a server as a Java agent, or a Java deployment. As long as a client has had the product implemented, with no issues there. So that's kind of the key there, you don't want to have those agents have a blip or any issues.

Scalability Issues

So as far as scalability of Oracle Data Integrator, from the high availability standpoint, if you use WebLogic for your agent, you can use the clustering capability within WebLogic to create multiple nodes on different WebLogic servers. And then run your agent through that process there. So if something fails, if the main agent fails, it can fail over to the secondary agent or, again, another agent in your cluster.

Customer Service and Technical Support

I'd probably put them up there around an eight, yeah. Being a system integrator of Oracle products, typically I'm on behalf of a client. So oftentimes it depends on who your client is and what their level of support is, as far as response and how things go. But I've always had great response with those guys.

Previous Solutions

A lot of the projects I've worked on recently are Oracle VM apps projects. So, it's the folks that are in the Informatica version of VI apps, and looking at moving to the latest and greatest, which has Oracle Data Integrator behind the scenes. I'm not saying they're actually talking about using Informatica, they're just, that's what they have. And they're looking to migrate. Quite often where we come into play, ODI is typically chosen at that point. And then they call us in to help with it.

Implementation Team

It's not too difficult. It's tough to look at it from the perspective of someone who hasn't been doing it for a while. And oftentimes, that's what you need to kind of make that determination. But as far as just getting up and running, you can get it installed, configure an agent, quite quickly. And then the next step would really be getting ready to build a mapping. And they actually introduced in the most recent release, or maybe even when 12C came out, they introduced a feature that would basically get everything, topology, the models, all the data stores, everything, ready to go for you, just in one simple wizard. And then you could actually start building mappings quickly.

A lot of it is when they have home-grown ETL processes. So they'll manually script their ETL code. It's basically something that's difficult to maintain. So we talk about how we can use ODI to keep everything centralized. And even if we're not using ODI to actually build out mappings within the product, we might still be able to run that PL SQL or whatever it is, the script for ETL, from within ODI.

So we still have everything consolidated and contained and then the other approach, or reason for moving to ODI, would be the need to get off of that middle tier integration server. That we don't need with ODI.

Other Solutions Considered

As far as why consider Oracle Data Integrator, I think the big thing is the ability to consolidate all of your ETL into one place. Whether it's an Oracle to Oracle, source to target load, or even Oracle to Hadoop, or anything in between. SQL Server, MySQL, XML. ODI can basically talk to all of those different technologies. From a consolidation of all of your data warehouse or your data integration, if you will. And also, just use the same approach for mapping and creating processes for all of those different types of solutions. You have everything logically defined. And so when you're developing, it actually doesn't look any different than an Oracle source, and target doesn't look any different than a Hadoop source and target.

Other Advice

So I would rate ODI a nine. And that's really because, just looking across the other ETL tools, so I mentioned Informatica, there's a lot of other ones out there. I've seen what ODI does from a sort of a declarative design approach, and the push-down of work to the source and target. I've seen that replicated in other tools that have come out after Oracle Data Integrator. That's a big key.

It puts it kind of at the top, if you're going to look at a scale across all of the ETL tools. The other aspect to that rating is how they're integrating a lot of the big data technologies now. And it's a big deal from an Oracle standpoint, it's kind of how things are going. And it also just makes sense to, again, keep everything consolidated in one place. You already have an investment in ODI, it makes sense to try to drive some of your other big data type Hadoop loads or whatever it may be from that same place.

Disclosure: My company has a business relationship with this vendor other than being a customer: We're a partner.
4 visitors found this review helpful
3 Comments
ConsultantConsultantTOP 20

Michael, Just a note on the text above. It looks like they misquoted you regarding Oracle BI Apps as Oracle "VI" Apps.

A comment on the benefit of ODI to use the source and target technologies for the most efficient and powerful processing. Another view... I have used other products in the past that provide a third layer that actually insulate you from intimately knowing the details of each target and source technology. (Thinking in terms of the new user or casual user here).

Ultimately I agree with your statement on power and performance however I also see the other side which I never seem to hear much about - maybe its just me. To me, for the casual and new user, there is considerable benefit to having a middle layer - especially when you are doing small implementations across a few technologies - in small implementations that middle layer can reside on the target server so you don't need a third box as is always said. This third layer can add some development leverage too - admittedly at perhaps some cost in performance if the source and targets are leveraged thoroughly well in ODI. This third layer/engine can shield you from all of the intricacies of each platform you integrate with. For example I use ODI for integration with AS400 db2, SQL Server, and Oracle and once against Informix. While it is true that I can leverage the best of all of those technologies in ODI - it also requires me to keep up with all the trials and tribulations that that third layer might shield me from - all those technology differences. To take an absurdly simple example, in db2 and oracle I can use TRIM(), in sql server I cannot. In Informix I don't remember! A third layer would shield me from having to know all that allowing the engine to determine, based on the technology that I am using, to issue the correct command. Again, simple example but I hope you get my point.

As a footnote I realize you can create ODI functions to do the same thing - which I love, but again I have to know how to implement each feature across each technology to get it to run properly. Not so great if you are trying to do a POC or get up and running very quickly.

I just wanted to point out the advantage of some ETL's that I have used in the past that made my life a little easier than ODI especially if you are a new user or a casual user and doing small implementations. Maybe we need options to do both?

Lastly, in my little world because of the cost and complexity odi, I find the use of ODI to be very prevalent in oracle shops and not so common elsewhere. You?

Appreciate the review - great job as always.

04 August 16
Alan YvesConsultantTOP 5LEADERBOARD

But one of the beauties of ODI is exactly that flexibility in integrating several different platforms/technology, for example, say you have a data source on SQL server database and your target database is Oracle and you want to apply a sql server function, in your interface you have an option to specify the execution on the source and then you would be able to write your SQL server function : Rtrim(Ltrim (column)), I would rather bring the source record as it is in the source and execute on the staging and use oracle trim(column) that would give the expected results, but again, you can use the sintax of either rdbms platform/ technology .

05 August 16
Consultant at a tech services company with 10,001+ employeesConsultant

I have used informatica, ab initio before getting into odi. Odi 12c is a big improvement as compared to its previous version.

I like the flexibility of the tool and the ease with which you do the things. It will take just few days of learning to deliver the solution you need.

If you are good on the database in which you are pushing your data, then you are good to deliver a high class etl solution with very less time in learning the tool.

02 January 17
Guest
Sign Up with Email