The deployment went pretty smoothly. It takes less than five days. But for other configurations, depending on customer needs and use cases, it could take about a month or two, considering the scope of the product.

We are having government work, especially because my customers are in the public sector, mostly preferring on-premise solutions. Cloud and hybrid are still young in that area. Most government institutions prefer on-premise. But we're looking to enable a hybrid kind of solution. Most are good for on-premise solutions with on-site protection.

The overall deployment process took close to one hour. The important steps in the installation are the domain configurations, selecting the parameters from the server, and selecting add-ons based on the space and features. Then, we create the infrastructure.

Deployment was done in-house. Typically, one person is sufficient for the deployment. The person would be a system administrator or a WebLogic admin.

Moreover, there will be quarterly patches that need to be applied for maintenance. The number of people required for maintenance depends on the complexity of the APIs and the organization's needs. WebLogic admins or SOA admins handle the maintenance tasks.

We implemented it ourselves (as we are system integrators for this solution) both at our own premises and at multiple customer locations.

Oracle SOA Suite was deployed long ago, and I wasn't with the company when it was deployed.

The majority of the work we have had done with Oracle SOA Suite has been through a major systems integrator with a few internal individuals with some knowledge for basic operational support. Given the choice, use smaller specialist Oracle partners -- they may cost more per person, but they know how to get the most out of the platform and can deliver a lot more in the same time. The big SIs we have seen approach things with just training staff to use the tools and then assume that is good enough, rather than invest in the underlying principles and support the development of good skills through experience.

I have been on both sides of the fence. It is important to leverage the experience of an implementer who can bring the know-how and protect the organization from making mistakes that can prove to be very costly in the future. If the budget allows try to learn from the mistakes which were done by others before you.

We need technical support for the deployment. We needed three developers and two engineers to deploy the tool.

We implemented the solution in-house.

We implemented it on our own, although on certain modules the Oracle team had helped us.

We hired Oracle for a few of our implementations when we were setting up our in-house team. We began implementing with vendors and later on formed an internal team with knowledge transition. If you're a company that does not have COE in the areas that you are implementing, it's advisable to consult the vendor team for industry experts and gradually move the technology over.

Some of the good ways to implement SOA in a traditional, agile, system development lifecycle is really trying to understand what are the functional use cases. What is the business process that needs the support? Some of the other key aspects are being able to understand what is the universal data model that you're going to be integrating? Right? What are the fields and elements on the back ends' system that's providing the information and what are fields and elements on the consuming system? Then be able to come up with a semantic level, canonical level mapping between those two and be able to create a universal data object. Create a loosely coupled implementation.

Traditionally building integrations does follow a system development lifecycle. Traditionally going through requirements, design sessions, integration, development, testing and so forth, There's a lot of techniques to do those rapidly in an agile-like way but there's also some ways to also blueprint those so that they're well documented, well understood. It helps keep your technical debt low for organizations who have to manage and maintain these over the course of many different years. Oracle SOA is well-designed, it is a product that we've implemented many times over and we've built a lot of best practices to help customers understand the complexity or take some of the complexity out. Because at the end of the day it is a platform, it's not a shrink wrapped solution. It's a platform that you have to be able to build things on and if you're not building things the right way, you can easily create what we call 'spaghetti architecture'. Which is building a bunch of point-to-point integrations between these systems that is not loosely coupled, not reusable and not scalable because they're not following good design patterns. If you're going that approach which unfortunately we see some customers do, then that could get you in trouble. We've got some frameworks and some solutions on how to avoid those types of architectures and designs.

Our in-house team deployed it. 

We implemented it ourselves with our in-house team.

In-house.

The vendor team was not used. Full disclosure - I work for a consulting company and we were brought in to facilitate the BPM and integration aspects of the project.

We have an in-house team that did it.

We used Oracle consulting services for the implementation, they are very good.

We have at least four infrastructure engineers working on the support of the solution because you need people shadowing each other. Four should be good.

You will need an infrastructure person because it runs on WebLogic. Another person who can set up the infrastructure, and someone else who can work on the Oracle SOA Suite, which involves many services. Your security team needs to get involved too, they are part of this project. However, there are only two main technical people involved, infrastructure and product person.

I attend implementations at customers with their teams. Their feedback is that during deployment, it has

• Robustness
• Performance
• Rich functionality

The largest customer has more than four million hits a day on its Oracle SOA Suite infrastructure.

We had another partner, because we had no idea about SOA Suite. So we had another offshore vendor who helped us do the initial configuration, sessions of going through the architecture sessions and now we have become comfortable with it.

We implemented it with a mixed team. Read the documentation and Oracle Support portal notes. Design error handling and monitoring upfront. Decide on your underlying Database infrastructure based on data volume and anticipated load.

Most of the time, it's straightforward for the integration patterns, and isn't rocket science.

A vendor team did the installation.

I have implemented the solution as a mixed implementation between vendor resources and in house. This model has been used at all my implementations across industries. My advice would be to identify your pre-requisites and also hold pre-planning meetings to identify business and technical requirements.

We implemented it on our own.

We implemented it using a third-party team of integrators.

We used a third-party implementer.

We implemented it with our in-house team.

I implement SOA Suite for my clients.

I have implemented and consulted on several implementation projects using Oracle SOA Suite. My main recommendation is to be trained and willing to learn, because there is so much that can be done with this product and the projects are always looking for long-term usage. Having more knowledge will result in implementing better architectures and problem-free solutions.

I have always been an independent consultant, and I always say there has to be an in-house responsible person/department for SOA.

I have always worked with Oracle partners and we usually implement for clients. Implementation is relatively easy.