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.