Sun set

One of the things my professor in system development at Chalmers told me was to never put anything related to "new" or "next generation" in a system name because at some point the system will be old and will need to be replaced. Having to name the next system "even newer" simply looks silly.

Currently there are a lot of Sun IDM owners that are contemplating upgrading into something that actually is moving forward. Oracle has promised continuing support and probably will deliver, at a steep price, but with the platform not being improved investing more money to add new capabilities doesn't make sense. It will also be harder and harder to find staff that can support the system. I recently heard about a Sun client where the staff had spent three months trying to install a new instance of the access manager agent. The client simply couldn't get it to work and had to give up in the end which of course resulted in some serious angst among the senior leadership as it meant that if the access management agent broke in production the entire application would be out of order for at least an extended period of time and potentially permanently.

We are currently in the final part of the first phase of our migration of Sun and I thought it may be interesting to talk a bit about the experience.

When you do a major upgrade of an IDM stack you basically have two choices. The first approach is to try to do some form of automated or semi automated upgrade. You essentially look at the upgrade as a big patch so you apply the patch in dev and do some regression testing. If everything looks good you start to walk the environments through test, stage and finally prod. In theory this works well and there are even cases when it works in practice (see MIIS to ILM). In the case of going from Sun IDM to Oracle IDM I think it would take a small miracle and a very skilled team to get this approach to work. The product stacks are simply too different and too complex so there is going to be cases where the conversion simply isn't possible. If you also have substantial customizations in play I would consider the approach being close to setting yourself up to failure.

The second approach is to try to leverage as much of your already existing documentation but essentially look at the project as a refactoring exercise. If you have good business requirements and workflow documentation then use that but anything from design and upwards I would strongly recommend that you rework. Most IDM installations don't have good requirements to start with and given that you usually end up creating delta releases rather than updating the original documentation even the ones where the docs where good at one point usually are a victim of "here is the original docs and here are the docs for the 5-30 delta releases that we have put in over the last five years" syndrome.

Update: Identigral's blog recently covered this issue. It is interesting to see that their conclusions are quite closely aligned with this posting.