Archive for the ‘Migration’ Category

Continuity vs. Reinvention

In an lead architect role i’m currently involved into a project to design the migration of a very mature IAM implementation towards a newer release of the same IAM solution suite within an complex infrastructure. I don’t want to shed light on the technical details here, but i would like to discuss the impact on the end user in such an migration.

The customer is using the web based end user portal heavily with an user base beyond 100.000 end user all over the world. Due to the lack of oob-features in the currently used release the customer spent a lot of time and money in extensively customizing the web portal. In fact, there are just a NO standard modules used anymore, the whole web portal was reimplemented by the customer and their current service provider to offer the best breed value for their end users.

Facing the challenge of migrating the existing solution to an newer release of the same IAM suite, were facing some issues here:

  • due to the fact that we plan to make a jump over 2 major releases, lot’s of the backend technology, database structure as well as the web portal designer engine and controls have changed, were replaced or disestablished
  • to enhance the end user experience, the customers service provider did implement a bunch of custom controls into the web portal using the existing web portal designer engine which are sometimes based on oob-controls
  • the web portal implementation is doing some tasks in an very special way, so to say not all of the tasks are initiated through the web portal are being handled and executed by the IAM solutions backend engine (as it would be the usual way to deal with) but they are being driven directly out of the web portal itself without ever interacting with the backend engine (e.g. several web service calls)

All of these issue and their consequences have to taken into consideration when planning the migration as an strategy as well as the technical implementation itself. When not taking a look on effort or cost, we’re coming down to the following decision:

Rebuild the web portal as it exists today OR reinvent the web portal using the newer technology and oob controls?

Or just rephrasing the question: Continuity or Reinvention? Let’s discuss both of them a bit first before coming to my final conclusion.


Keeping an eye on the huge end user base of more than 100.000 users it might be worth spending the effort in rebuilding the same heavily customized web portal than it is existing today. This will minimize the impact on the end user in the final phase of the solution migration and might keep the help desk and the IAM team in an comfortable situation. But the price that has to be paid is high: all controls that can’t be migrated automatically using the IAM suites migration features have to be rebuild within the new platform. So there is effort to be spent which has already been spent and paid by the customer. Keeping a high level of customization does increase the complexity of the final solution implementation as well as the potential maintenance effort but also the risk when migrating towards newer versions of the IAM suite in some years. It does also make the customer dependent from the implementing service provider as the implementation know how will be on the side of the implementing service provider. The solution vendor might not be able to support all of the implementation as it might be to heavily customized, which also does not bring any value to the customer.


Reinvention does mean to migrate the complete web portal towards the standard solution features by limiting the customization to the lowest level possible (which in the best case would be customers CI). The nearer the to the delivery standard the solutions implementation is, the better is the supportability by the solution vendor instead of the implementing service provider which brings the customer into a much more comfortable situation for future business with the vendor as well as with the service provider landscape. On the other hand there is impact on the huge end user base as they will have to relearn and / or adopt the newer solutions web portal and it’s functionality as it will have another look and behavior. This will also have an impact on the customers help desk and the IAM team as they will be the point of contact for all the end users that do have trouble with adjusting themselves to the new solution and the new way of handling things. This can be mitigated by providing training material, web casts and regular updates during the implementation process to make key users and power users of the upcoming changes. Utilizing the group of key users and power users does streamline the process of sharing knowledge and information from the help desk and the IAM team through the key users and power users to the regular end user.


From an architects view, my conclusion is pretty clear: i’m recommending the reinvention of the end user web portal although there will be an impact on the huge end user base. Why do i want to do that?

  1. Bringing the solution back towards oob standard as far as possible does make the solution less complex and enhances the maintenance situation for the customer itself as well as for the service provider (which might not necessarily be the implementing service provider)
  2. The implementation effort is not that high than keeping the web portal as it is by spending a lot of time and material in keeping continuity by reimplementing anything that has been implemented so far
  3. The end user impact will have a peak at the beginning of the solutions roll out but will decrease quickly

From an realists view knowing the customer for a while i’m pretty sure we will end up with kind of an mixture between continuity and reinvention. But the strategy i’d like to propose to my customer is clear: decrease customization over time. Maybe it’s worth spending the money in reimplementing the existing solution in the newer release and then starting an process of moving feature by feature back to standard.

Categories: IAG, IAM, Identity, IDM, Migration, Strategy

Discussing IDM Migration Strategies

September 13, 2012 Leave a comment

Days ago I was reading a discussion around Sun IDM Migration Strategies with different approaches. First of all there was an approach named “Migration by Objects” as an Bottom-Up approach. This strategy is attempting to migrate Objects within Sun IDM into the new IDM platform. The next approach I read about was named “Migration by Use Cases” as an Top-Down approach. This meant to migrate Use Cases from Sun IDM into the new IDM platform. Then there was a mixture of both named “Hybrid Migration”, discovering Use Cases by analyzing Objects and / or Implementation. The fourth approach mentioned in this discussion was IMHO something very similar than the “Hybrid Migration” approach, but in this case invented by another company for another target IDM platform.

The fact that hit me while reading those approaches was that it seems like the only way to get rid of Sun IDM is actually really “migrating” Objects or Use Cases or both in different flavors from Sun IDM to another IDM platform. That’s not all from my perspective.

The approach which is completely left out in this discussion is the approach of implementing IDM from scratch. After years of operating an IDM solution like Sun IDM, companies might have realized new needs, new requirements, new systems. Sometimes it makes total sense to invest into a complete new analysis of the situation as-is, finding gaps between the existing implementation and current expectations. I don’t say that this is not possible by using Top-Down, Bottom-Up or hybrid migration approaches. It’s more about the question: does it make sense to migrate at least one single Object or one single Use Case from A to B without looking on the current needs? Even companies running Sun IDM or whatever IDM / IAM solution in the world in these days should have a roadmap on how to increase the value out of their IDM strategy. And strategies are not only about staying with one single solution or one single approach. Strategies have to be redefined to face business needs, technology and the technical development.

But it’s interesting to see that there is still that much interest in migrating existing Sun IDM installations after the Sun acquisition by Oracle at the beginning of 2010 was named the dead of Sun IDM.

Categories: IDM, Migration, Strategy