Five Practical Ways to Ruin Your IAM Project

Identity and Access Management projects are very common nowadays. The interesting fact is that too many of them either vastly under-deliver or totally fail. I have been fighting in the IAM trenches for many long years and I have seen both successful and failed projects. It looks like to me that the IAM projects are surprisingly easy to ruin. I though that it would be good to summarize some of the worst mistakes.

1. Start Big and Go Down the Waterfall

Everybody knows the waterfall development model even though you may not know that it is called “waterfall”. It goes like this: analysis -> design -> implementation -> testing -> deployment -> failure. This model is known to the software engineers since 1970s. And even back then it was considered to be fundamentally flawed and it was only documented to make a bad example. The interesting fact is that it is widely used until today. It is sometimes even recommended as a best practice. But that does not change anything about the fact that the process is flawed and that it is a recipe for almost certain failure.

Do not start your IAM project without any iterations in it. You may as well throw the money out of window. You IAM project needs to be decomposed into a smaller iterations. Each of the iterations needs to have its own small analysis, design, implementation, test and deployment. The iteration should not be longer than 3-5 months. Each of the iterations should provide a tangible value. Each of them needs to pass its own ROI assessment. If it does not then skip the iteration or stop the project. Plan first couple of iterations before the project starts and check ROI. If it fails then do not start the project at all and re-consider the choice of technology and delivery partner.

Are you using a commercial IDM product that has huge licensing cost and therefore you cannot proceed in iterations without ruining ROI? This has a very simple solution: do not use such product. The IAM market is crowded. If you look around a bit you can surely find a cheaper product. The capabilities of commercial IAM products are very similar therefore there are many options to choose from. If you do not want to change the product then ask for a discount. I have reports that many vendors are happy to discount the license fee by giving off 50% or even more. Or even better: go for open source product. Open source products have reached (and exceeded) the capabilities of many commercial IAM products during last few years. Licensing cost of open source is zero – by definition. Therefore there is absolutely no reason for paying huge license fees. Every IAM project must be able to work in an iterative fashion and maintain a ROI. If it does not then do not go for it.

2. Spend the Budget on Product

Buy product, deploy it and have fun. This simple plan may work for some technologies but IAM is definitely not one of them. IAM products typically do not work out-of-the-box. They need to be configured, customized, extended, connectors, plug-ins, workflows and widgets need to be developed, etc. The cost of the product is only a part of the total cost. And in fact it is quite a small part. Have a look at the cost structure of your project. If you plan to spend more on the product than you plan to spend on services then stop immediately. Such project is extremely likely to fail or run very high over the budget. The ratio of product to service cost needs to be at most 50:50 – and this is still a very risky endeavor. The ratio of 20:80 in favor of services is perhaps the most realistic one.

Also forget about using expensive products. The differences between individual IAM products are quite small. Any reasonably good product can satisfy your needs. The best-of-the-breed IAM is a myth. A marketing strategy. What you need is not a product, you need a solution. Therefore do not buy the product and then look for a team. Look for an experienced team that can deliver a solution first. And let them recommend a product. A product without a good deployment team is a waste of energy and money. On the other hand a good deployment team can satisfy your needs with almost any product.

3. Suite Up

All the big vendors offer technology suites: a set of products that are sold under the same brand. Such suites often create an impression that together they form one complete and integrated solution. However this is almost never the case. Most suites are created by acquisitions. The acquired products are technologically very heterogeneous almost to the point that they cannot really be integrated together. Therefore the “suite” is usually only a thick layer of paint designed to cover product differences. It does not make product integration considerably easier. Therefore there is usually no significant technological difference between buying a suite or buying several independent products.

But there is one very significant business difference if you buy a suite: vendor lock-in. The vendor that offers a complete suite has only a very little incentive to support integration of his products with another products from a competing vendor. Therefore suites are actually much harder to integrate with third-party products. If you are going to buy a suite you are going to stay with that suite forever. This is a life sentence. And it is going to be very expensive.

4. Customize Ad Nauseam

Customization is a necessary part of any non-trivial IAM deployment. But it has to have its limits. Customizations are by definition pieces of functionality that are not reusable and therefore are not part of the product. Therefore too much customization naturally means long and expensive deployment. But it is worse than that. Many IAM products are notoriously difficult to upgrade. The upgrades often ruin all the customizations. But even if an upgrade goes smoothly part of the customizations is almost certain to break and needs to be modified. This creates a huge maintenance burden. In a lot of practical cases the operation team simply decides not to upgrade the product any more. However this creates a technological debt. A need to upgrade the product eventually comes sooner or later. Then the only practical option is to re-implement the complete solution from the ground up. Which will completely ruin your initial investment.

Therefore keep the amount of customization reasonably low. The best project that I have witnessed are those where both the technology and the business processes adapt to each other. However this is a slow process and it just cannot be delivered in one huge package. This needs to be implemented using an iterative approach.

Also completely avoid products that require you to make customizations to support the very basic IAM features. Such products are very expensive road to hell. Prefer products that have common functionality present out-of-the-box but are still reasonably customizable. And choose a deployment team that can take advantage of such products.

5. Purchase an IAM Project

Many people believe that the IAM effort starts with analysis and ends with deployment. But that is definitely not the case. The real life of an IAM solution actually begins with a deployment. The day when the deployment team hands the IAM solution to the operations team is actually the very first day of IAM lifetime. Similarly to security practices the IAM is not a project. It is a program. It may have a start but it does not have an end. It is a continuous process. It is not possible to reflect all the requirements before the system reaches operation. IAM solution needs to be continually improved and adjusted. Therefore if your contract with the delivery team end when the solution is deployed then you are very likely doomed to fail in the long run.

Build up a long-term cooperation. Choose a delivery team that is able to work with you even after the system is deployed. Make sure that you can afford it. If you cannot then there is absolutely no point in starting the IAM project in the first place. Make sure that the team is empowered to really help you. Conducting a Proof of Concept (PoC) before the project start is a very good idea. Make sure that the PoC contains at least one very advanced scenario. Any fool can download and install the product. But going through an advanced scenario in a limited time can tell you whether the team really has the skills to use the product, whether they have good support from the vendor and also whether the vendor is open to support non-standard scenarios.

Bonus trick: If you are evaluating an IAM product have a look at the logfiles. Let the engineers show you logfiles from the actual deployment (e.g. a PoC deployment or a demo). Choose a random part of the logfile and ask the engineers to interpret the logfile for you. Let them explain what each line of the logfile means. If they cannot do it then the team may not have enough skills to use the product. Or maybe the logfile is not intelligible at all and even the most skilled team cannot use it. Which means that the deployment team will be powerless if they encounter a product problem and they will need to ask vendor for assistance every time. Which means lock-in and very slow response times. Avoid this at any cost.

5 thoughts on “Five Practical Ways to Ruin Your IAM Project

  • Actually this is a bit one sided…

    While it is very good on the clients side who should seriously take under consideration what is written here, there are other things not mentioned. Like:

    – organization should be mature enough to use an IAM. If an organization does not have business roles, and certain data governance policies in place then the whole project needs a lot of time in advance in consulting services so implementation will be done in a very small time frame.

    – IAM for an integrator has a starting and an ending point as a project. It is not a program for the engineer who will spent hours there for a PoC or an implementation. This means that by default integrator will leave at some point, unless you are ready to train your staff as engineers of the product in place, or simply pay for a very pricey SLA.

    – As mentioned there is always a time point where product will be upgraded or even migrate to a newest version. This means that besides the tech difficulties there is also the need to apply a new model , by using consulting services again unless you have an engineer of the product in your team. If you are not ready for it, migration/upgrade is the least of your issues.

    – It is true that suites are built by acquisitions of software modules which are integrated between them in order to work with a high level functionality (I/O). But i dare also for someone to try to do that on his own with different modules bought by different vendors (e.g. RSA SSO, NetIQ IDM, Oracle Advanced Authentication, etc. ). I would gladly hire him if he completes a big project like this.

    My closing argument is that sometimes you need to take a closer look and do that by placing yourself in other people’s shoes so you will be able to have a complete opinion of all things.

  • Thank you for your opinion. But I have to disagree:

    Ad “organization should be mature enough”: In fact, almost any reasonably-sized organization is mature enough for IDM project – assuming the project is sized and managed properly. IDM project does not necessarily need to reach the deepest levels of IDM, it does not need to include governance and so on. The trouble with commercial IDM solutions is that there is a huge up-front cost for the project (product license). Therefore the projects tend to be very big to justify such up-front cost with a lot of benefits. But there is no license cost for open source. Therefore the up-front cost is much lower. Iterative and incremental projects are possible with open source. Therefore even organizations with lower maturity levels can implement IDM solutions to match their needs and readiness.

    Ad “IAM for an integrator has a starting and an ending point as a project”: Yes. But this is quite a selfish point of view. I dare to say that if IDM deployment is managed as a project it is almost certainly doomed to fail. It has to be managed as s program, either by the customer or by the integrator. I also dare to say that good integrators do not abandon the project after it is “finished”. Good integrators stay and support the customer in a long run. IDM/governance without a long run is completely pointless exercise.

    Ad “product will be upgraded”: Yes. There are “flag days” in the lifecycle of almost any project or product. The difference is how often they happen. Whether there is a huge upgrade effort for each new version of a product. Or whether you can easily upgrade twice a year for almost a decade. That makes huge difference.

    Ad suite integration: Agreed that it would be very difficult to integrate products from different commercial versions. Customers using commercial products are therefore often locked-in to a particular suite. Luckily, there is open source. Things are very different in open source world.

    Ad “other people’s shoes”: I did. I made my living by deploying IDM systems since early 2000s. I was in in integrator’s shoes. Otherwise I would not dare to make those claims.

Leave a Reply