A common situation we run across in the world of consulting is when companies choose to swap one IDM solution for another. There are a number of reasons to consider making a change like licensing costs, feature set, knowledge levels and even future expansion.
And a lot of times these can be very valid reasons for moving from system to another. If you have a system that has a high annual license cost and you have the chance to move to a system with a relatively low (or even free) license cost then it might sense on the surface to make the switch, right? As a company. the goal is to try to be more productive and cost-effective. If you can save money while still performing the same (or more) automated identity management processes, switching seems like an easy win.
But a more common reason than switching to save on licensing costs, is when the existing system knowledge base moves on and companies are left with nobody that knows the current system and a need to hire new talent. Oftentimes that new talent has IDM experience, but perhaps not with the same product or vendor that is currently in use, and in many cases a decision is made to move to a product more in line with the existing knowledge, rather than increase the knowledge of the current system.
Is The Right Decision To Implement A New IDM Solution?
Ultimately that is a decision that the company has to weigh over time and answer for themselves. But before making a decision, there are several things to consider.
State Of The Current Environment
I often hear people people complain about the IDM products in their current environment. “It doesn’t work right,” or “It isn’t stable,” or “It doesn’t do what we want it to do.” But the more I talk with the people who make those statements, the more I find that it isn’t so much that the system can’t do the things that they want it to do, but more often that they don’t know enough about the system to make it do the things that they want it to do, or how to troubleshoot/solve problems in that environment. If you handed me a car with a blown head I would know something was wrong, but not how to fix it, and oftentimes that is the same case with these companies; they know something is broken but don’t have the skill set to fix it on their own.
How To Increase The Knowledge Base
There are two logical solutions to this problem: either get training or bring in someone knowledgeable about the product, either through direct hires (which can be difficult to find) or through contractors (like IDMWORKS.) Either approach allows companies to grow their knowledge of the existing environment and resolve pressing issues. The problem with these two solutions often comes down to budget. Companies lack the budget for new hires or a long-term contractor, or the training fees are too steep.
When companies look at it through that narrow scope it makes sense to change. “It will cost a small fortune to hire a contractor to manage this system and we want to control it in-house.” “For the cost of a contractor long-term we could pay for a new system,” or “Why spend money to train staff in one product if they already know another product? They will be more effective and productive in an environment they already know.” And to a certain extent these are all valid sentiments.
But when you paint the full picture things don’t look as clear cut. There are a lot of other costs in transitioning from one system to another:
Dual System Costs
For a period of time both systems will be in existence. This means that companies will still have the overhead and cost of maintaining the current system (including its licensing) while adding new overhead for the new system and its environmental requirements (hardware, OS, software, licensing, etc.). If not planned properly this could be an expensive overlap.
Time To Install & Configure The New Environment
Most companies, especially those with smaller IDM staffs, may find it difficult to support an existing system while trying to build out a new one. There isn’t enough time for the staff to address questions, issues, enhancements, etc., with the current system and still set up an entirely new system in a timely manner, so in many cases it means bringing in help from the outside, i.e. contractors. If keeping the current environment was nixed because there would be a dependency on contractors, those same contractors could be required to create a new environment, so how much is really being saved?
Current Capabilities Versus Future Needs
It may make sense to swap a more expensive system for a cheaper one because your current needs do not require all of the features in the more costly system. But then the question should become, does the new system provide not only the same capabilities in use today, but also the capabilities that will be needed tomorrow?
Oftentimes one system is cheaper than another because it does less. Vendors may sell that product as more “XYZ” focused or oriented than the competitor’s but in actuality that system may not be as scalable or mature as other systems. If you save money this year by going to a cheaper and less feature-heavy system that’s good for this year, what happens next year when you need a service or capability that the new system doesn’t have, especially if the old system did?
New System Impact On Existing Processes & Groups
Most IDM people see changing systems as a pure behind-the-scenes change that people downstream will never see or know about. In terms of how end users are being provisioned, that might make sense, but others like help desk people may have to change processes to resolve issues, communicate with end-users regarding URLs, and hold end-user trainings if the new system has some type of user interface that is exposed to the user community or changes how information is fed to the new system compared to the old system, etc.
Very rarely is a new IDM solution a straight swap, so it requires effort and changes from a number of people and groups to make it happen. There is a lot more coordination that has to take place to truly support this type of operation than some may realize.
Swapping IDM Products Is Just As Big An Undertaking As Implementing Your First IDM Solution
In my experience, you still have to design a new system, gather requirements (oftentimes this swap is seen by the company as an excellent time to enhance or improve processes, so new functionality is almost a given,) build servers, install and configure products, develop the business logic, perform all the standard tests, and then do a typical production go-live implementation.
In some ways, a swap is even more complex than a new implementation because you have to do this while managing the existing system which includes the decommissioning of it after the swap is done. Instead of just flipping one switch now you have manage 2 or more switches.
Making The Decision
Ultimately it is up to each company to decide what is best for them, but based on my experience, I would look hard at the options to leverage what is already there.
Sure, training can be “expensive” (a relative term when discussing corporate budgets) by the time you pay for the training courses and the travel costs. You may have $4k-$5k per trainee invested in a training session with a vendor (or a vendor partner like IDMWORKS) but by the time you consider the cost of implementing a new system from the ground up, training is just a drop in the bucket. I would rather spend $20k to have a team trained on a product and maintain a support agreement with a vendor if they need help, than spend $250k or more to put in a new system that I will still need a support agreement for. For 1/10th of the cost I may be able to make my current system meet my needs.
For some it is just easier to make the change regardless of cost because in the end they think it will be more cost effective, while others want to get all that they can from the existing investment. I fall more into the second group. You’ve spent the money to put that system in place, so use it. If it hasn’t been properly maintained and updated then changing to a new system may fix the immediate problems, but not the long-term ones, because who’s to say that the new system won’t fall into that same state of disrepair with the same lack of upkeep. And really, who’s fault is that? It does’t happen overnight. That’s like buying a new house because the current one is dirty. The new one may be clean when you move in, but it will get just as dirty over time if not kept up.
You get out of an IDM system what you put into it; new or old.
There is no easy answer with this topic. To be or not to be, that is the question.