The deployment for Oracle Data Integrator (ODI) was in-house.

The implementation was completed in-house.

We use a consultant for the implementation of ODI.

We are having different environments for ODI and depending on many factors in those environments will dictate how many people we need. We have the development, testing, and production environment. We will need people for each of these areas. If it is a small firm or a mid-sized firm, and if the consultant has good knowledge, then they can manage the three environments, or else the work can be distributed. 

For the deployment, we use eight people. If the project is a small size project with fewer tables, then it can be even done with three people.

I have been on both sides of the fence for this question. I would always have a vender do the install if you have never used the product before. There are a lot of little tweaks that can be made that takes experience with the tool to know these tweaks. If you have had the product for over a year, I would say, that in-house would be ok. Just make sure that if you have to remediate the install that you involve Oracle in that process so you make sure that all the parts get cleaned up properly otherwise the reinstall could be problematic.

We used an integrator.

Deployment was done in-house.

We used a third party to do the implementation of ODI.

We have approximately five engineers that do the maintenance and support the solution.

In-house.

The implementation was done by both a vendor and internal resources. In addition, name standards for objects (e.g., packages, scenarios, procedures) should be considered and each package should be design independently from other packages (e.g., Modular Programming).

We set up the tool in an environment because of data sensitivity.

We reached out to Oracle and a few other partners that Oracle has but, in the end, we decided we should do it ourselves. If we did not do it ourselves we wouldn't have the knowledge of how to do it in the future. We received a quotation from them and then decided, we would do it ourselves, in-house.

For all these cloud products, we have to patch them ourselves, it is not done automatically. I was expecting patching to be automatic but it is not. 

I was usually part of the implementation team to implement the product .

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.

We did it at our own.

We did not need the help of a vendor or integrator. We did do everything on our own.

I implemented with our in-house team. You should try to have good documentation before using this product.

We performed an in-house one. If you have a technical team for ODI, then they can easily perform any implementation. If not, then you should have the vendor perform your implementation.

We had a vendor team help us with the implementation.

I implemented it with an in-house team, since my company is a consultancy and also an Oracle partner.

Even if ODI allows implementing a very smart solution with an high level of customization, I think that keeping the model of what you are developing as simple as possible is always the best choice. This is due to its future maintenance. Keep in mind that, even if you may be a very keen developer and you can propose the best and most parametric solution ever, if another (less expert) person inherits the responsibility of what you have developed, they may encounter difficulties in solving problems. For this reason, the easier you keep the complexity or technicalities of what you have created, the better it is.

This is also valid for performance - one of the basic rules of the informatics development is “divide et impera”, which means that you should always try to create “objects” as small as you can to improve performance and to be able to identify quickly where a problem is.

We used an in-house team. My advice would be to know what you want to achieve with the tool because it is very flexible.

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.

Probably because of user error – as I’ve mentioned, I had no prior experience with it – my first attempt was a bust. I was fortunate enough that I worked someplace where they sent me to training. The second time around was very easy; maybe the training was what I needed. For somebody like me, I recommend training first.

I think some people have that ability to just look online. I thought I followed all the instructions, and it would not work. It might help that, the second time around, I used the more up-to-date version. I know they change things on the install process sometimes. Second time easy; first time headache.

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

I believe we implemented it with our in-house team.

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.

In-house

We implemented it through a vendor.

The implementation was done in-house.

We used a completely internal team to implement this solution. 

We used an in-house team but hired interim experts, and created a team with combined knowledge levels, from rooky to expert. The initial setup is rather complex, and needs an experienced architect to make the correct decisions. The change of success is highly depending on the decisions that are made during the setup.

I performed the implementation. If there was something that I was unsure about, I contacted the support team for clarifications and update patches. Overall, it depends on the situation and the time frame.

It was implemented in-house by experts.

It was already implemented on the projects where I have worked.

We implemented with our in-house team.