RE: Oracle Fusion Middleware 10g vs. 11g stack selection (OID, OVD, OIM, OAM specifically).

Here at IDMWorks we specialize in Identity and Access Management full life-cycle services.

Discovery √ Design √ Implementation √ Development √ Support √

During a recent trip to a customer site for an installation of the Oracle Fusion Middleware stack we ran into an interesting conundrum. We were to install the 10g release of OVD, OID, OAM and OIM into the development environment. The customer pointed out that 11g had been released approximately 3 weeks prior and asked for a recommendation of whether we should jump to the 11g implementation path or continue down the 10g path.

First, let me say, the customer was right on point with the question. We like a customer who is knowledgeable and will challenge the decisions and recommendations that we make as a team because that is the same customer who will “take care” of their system long after Elvis (or in this case IDMWorks) has left the building.

Conventional wisdom states that you never jump to the next release of a product in the first month. You wait for stabilization (and typically the first service pack). However in this case we must keep in mind that the products, at least the directory components, are pretty mature. So we can add another option of a mixed upgrade, perhaps 11g OID and OVD, with the 10g release of OAM and OIM. Additionally, with a new release, and this speaks to stabilization, you don’t have the luxury of all the little “gotchas” that have been addressed with implementations of the past. In our case, when we had a Linux Service Pack Library dependency issue, we had Google to rely on to find the fix in less than 5 minutes. No call to Oracle Support, no waiting for recreation and resolution, no explanation to the customer on why we must halt progress while we investigate the issue.

So we created a game plan as follows:

1) Stick with what works!
The known 10g release, while the “older” release, provides a level of maturity and issue resolution that will allow our project to remain on budget and time. This is HUGE. The unknowns that a fresh release present, if the customer has time and budgetary constraints (don’t they all?), means that time spent resolving the “basics” is time lost (and hence money).

2) Plan, Plan, Plan for the future!
In order to address the 11g want of the customer, the resolution we opted for, was to develop an upgrade path and plan to 11g including the steps, the timeline, the associated cost and the follow up procedures that will allow, in a cost and time effective manner, the ability to smoothly transition into the next release in a matter of months instead of years.

3) Work with the customer
This should go without saying but don’t let personal agendas drive the project to failure. The customer wants (and rightfully so) the latest and greatest they can have. If that means the latest technology, than so be it. In our case we have three options, Old, New, and Newish (a little old and new mixed together). However, because we are the implementation partner ours is not to decide but to recommend. As such we explained all available options, gave our recommended approach and let the customer know that if they choose to move forward with another option (the non-recommended one) we would support them 100% and move forward in that direction.

In the end the customer stuck with the recommendation approach and we are well on our way to a successful implementation with a path to the future product laid over the existing framework!