Reflections on Sun Identity Man.... I mean, Oracle Waveset

It doesn't seem like two and a half years since Oracle shocked the technology world by announcing its $7 billion acquisition of Sun Microsystems, although a tremendous amount has happened in that time. For the most part, it has to be said that Oracle has done an outstanding job of assimilating Sun's technologies into their product portfolio. But in the IAM space, where it is not unusual for product migrations to take several years, there is still a great deal of work to be done.

Sun Identity Manager, which has been rebranded as Oracle Waveset and will reach end of life in 2014, continues to have an enormous footprint in the enterprise. Even a year and a half after Oracle announced EOL for the product, we still see customers continuing to develop and evolve their SIM/OW implementations, and in many cases express little appetite for migrating to OIM or any other identity suite, at least in the short term.

Some of us in the IAM community were more than a little surprised at Oracle's decision to select OIM over OW as its strategic provisioning solution, considering OW's extensive deploy base and maturity. But in retrospect, it was probably the right decision given the significant investment Oracle had already made in enhancing their existing IAM stack, of which OIM is a core component. With the release of OIM 11gR2, it is hard to deny that OIM is a superior product to OW in almost every respect.

The great thing about OW was that you could literally customize the tool to do anything you wanted. Its biggest flaw was that you could literally customize the tool to do anything you wanted. The open nature of OW was an engineer's dream. If a customer requirement wasn't met by out-of-the-box functionality, it could easily be provided by customizing the product using Java APIs and/or XPRESS scripts. Hell, I've even seen interfaces for OW built in .NET. Even after all this time, I'm still astounded by the creativity of some of the OW implementations out there, although I'm just as often left shaking my head in dismay, wondering how customers have allowed themselves to get into trouble with such poorly conceived customizations.

Typically, OW customers have made an enormous investment in developing sophisticated implementations and the specialized skillsets that are required to maintain them, so it is unreasonable to expect them to turn on a dime. Many implementations involve custom resource adapters, heavily customized rules and workflows, and sophisticated user interfaces. This makes it nearly impossible to automate the migration of OW to OIM or any other product, since no two OW deployments are identical.

Oracle has made a valiant attempt to smooth the migration path to OIM by releasing the OW2OIM migration tool. This tool performs a functional mapping between discovered OW configurations and their OIM equivalents, and can even automate the migration of certain objects (although not more sophisticated objects such as user forms, rule libraries and task definitions). At Qubera, we have developed our own upgrade assessment tool, which performs a deep dive analysis of an OW implementation and produces both an impact assessment and an LOE estimate. We are also planning to release a white paper, describing some architectural best practices and implementation strategies for migration.

Tools and assets such as these are intended to ease the pain of migration, rather than facilitate the migration itself. There is no simple and definitive upgrade path for OW customers, and it is misleading to suggest otherwise.

From a technical perspective, most OW functions now have functional equivalents in OIM, even if the nomenclature isn't always the same. There are notable differences, of course, such as in OIM's role capabilities; the advanced role features available to OW customers are now effectively divided between OIM and OIA. OIM's BPEL workflow engine will be alien to OW engineers, although it is far superior. Active Sync, which is one of OW's most commonly used features, does not have a direct equivalent in OIM, and of course all of those XPRESS forms and rule libraries will have to be completely rewritten. Furthermore, OW engineers making the shift to OIM will have to familiarize themselves with terms such as Generic Technology Connector, Adapter Factory, Trusted Source/Trusted Target Reconciliation, Lookup Definition and User Defined Field. Make no mistake, OW and OIM are fundamentally different products, even though they offer similar capabilities.

Skills learned in the OW world are not easily transferrable to OIM, implying a steep learning curve for OW engineers, who will have to forget many of the concepts they have long taken for granted. But change is inherent to the nature of I.T., and any technology professional worth their salt should be salivating at the opportunity to evolve their skills.

So where does all this leave customers, especially in an era of increasingly constrained budgets? In some cases, they have chosen to stay the course with OW and merely run down the clock (perhaps hoping that Oracle will have a change of heart and either provide indefinite support or decide to release OW to the open source community). Some customers have decided that the effort required of an OIM upgrade warrants a reevaluation of their IdM product strategy. And of course, some customers are biting the bullet and preparing to upgrade. Every organization is faced with different challenges; budgetary considerations, infrastructure demands, resource constraints, vendor relationships, compliance mandates and political in-fighting. Thus upgrading from OW to OIM is not always a no-brainer for IAM technology owners, especially given the vast differences between the two products. As somebody who spent more than a decade as an IAM customer and led numerous RFPs, I completely understand how these decisions are made, and the arcane considerations that frequently inform them.

On a strictly personal note, I am sad to see the end of OW. It was, and still is, an outstanding product and I have many great memories (and more than a few not-so-great ones) of implementing it. The sense of triumph from building my first custom adapter, the initial frustration and eventual mastery of my very first approval workflow, the sleepless nights wrestling with the mysteries of XPRESS form handlers, the patient experimentation with undocumented APIs, and the sense of relief following the success of my very first production deployment. But those days are behind us now, and let's face it, we all have a tendency to view the past through rose-tinted glasses (which is probably why my iPod is crammed with 80s music that I tend to remember being much better than it actually was).

I have no idea whether Oracle will have a change of heart on OW support, although given the scale and complexity of many OW deployments, I have a hard time believing that all OW customers will have migrated by the end of 2014 (hell, there are still production deployments of Sun Identity Manager 5.0 out there). But for a frame of reference, consider how long it has taken organizations to migrate away from JD Edwards. It is nearly ten years since PeopleSoft acquired JDE, and six years since Oracle's acquisition of PeopleSoft, yet JDE continues to thrive under the Oracle umbrella and will be supported indefinitely.

Something tells me we haven't seen the last of Sun Identity Man.... I mean, Oracle Waveset.... by a very long shot.