According to a study done by KPMG in 2009, 75% of IAM projects deliver less than expected. In a study done by McKinsey & Company in conjunction with the University of Oxford, 17 percent of large IT projects go so badly that they can threaten the very existence of the company. The study was done with a sample of 5,400 large scale IT projects (projects with initial budgets greater than $15M). Most of the time, for many software project failures, it’s the poor estimates to be blamed. According to the book, The Mythical Man Month, more software projects have gone awry for lack of calendar time than for all other causes combined. The book points out five key deficiencies in how estimates are done.

Techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite un-true, i.e., that all will go well. Estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable. Since we are uncertain of our estimates, software managers often lack the courteous stubbornness of the rest. The schedule progress is poorly monitored. When schedule slippage is recognized, the natural (and traditional) response is to add manpower.

I do not disagree that estimates play a key role in a successful software project. In many places on the web, when you google for why software projects do fail, the blame goes to the estimates and project management. In this blog, I present a different view. This is mostly related to IAM projects — but I believe some of them equally applicable to all software projects. Since I joined WSO2 in November, 2007 — almost for ten years now, got the opportunity to talk to many customers — and many of the Fortune 100 companies. One thing I cherish in my day job at WSO2 (and in my life) is the each single opportunity I got to talk to a customer. Listening to customers help you understand their pain, expectations and challenges. Not everyone I talk to, end up as a WSO2 customer — but still they leave us something to think. Below, in ten bullet points, I share my experience, in my view why not all IAM projects the cross finish line successfully.

All You Can Eat RFPs/RFIs

As a product company we get lot of RFPs/RFIs — and I’ve personally taken the pain of filling some of them. An RFI (Request For Information), is a formal means of getting general information from vendors, while an RFP (Request For Proposal) is a highly formal and structured way of getting specific vendor information, possibly including pricing. An RFI asks general questions, while an RFP asks more specific questions. Either way, most of the RFIs/RFPs are filled with tons of questions.

RFPs/RFIs are done at the very early stage of a project — and most probably people write those do not exactly know what they need — so they take the safest or the easiest path. They know they need an IAM project — so they look for couple of products out there in the market, possibly from a set of well-established vendors — copy the feature list as the requirements and publish as an RFI/RFP. This will cover well more than what you need — and some features you will never use — finally ends up with an ‘all you can eat RFP/RFI’.

Most of the RFPs/RFIs carry simple yes/no questions — with a ‘comments’ column. Everything in the real world is not boolean all the time. There are answers in between yes and no. During the evaluation process of an RFP/RFI, what matters mostly is the number of ‘yes’s. A vendor having most number of ‘yes’s will go through the first round of selection. The devil is in the details — when you start looking at the ‘comments’ column. Also you might have easily lost your perfect match during the evaluation, as you have flooded the RFP/RFI with unrealistic requirements, and will finally end up in buying a product from a vendor at a very high price. Only after few months or may be a year later during the license/subscription renewal you’ll find out how much more you pay for a set of idling features sitting on your server rack.

There is a more scary part. Since each question does not carry a boolean answer, some may say ‘no’ and in the comments column explain how things can be done probably by writing some extensions at a cost. Also — a similar proposal can be made by a vendor who’s having an ‘yes’ — but with a very high cost. Just relying upon ‘yes’s and ‘no’s in the RFP/RFI, you lose the best deal. Let me give you an example, a question like, ‘do you support multitenancy?’ — is quite open ended. Some vendors do have first class support for multitenancy, while others can support multitenancy by having independent instances of the product deployed per each tenant. Both would say ‘yes’ — but the latter is a very costly solution. In case they manage to secure more ‘yes’s than the first one — they still have a better chance of winning the deal!

I do not argue that we should totally eliminate RFPs/RFIs, but — producing ‘all you can eat RFPs/RFIs’ is not the right way to kick-off your IAM project.

Disconnected Decision Makers / Internal Politics

Few years back we (WSO2) worked with a large financial institute in USA to build a unified access control platform across the company. They had more than 70 teams internally, and each team had developed their own way of controlling access. Some have used a database to store access control rules in their own schemas, while some have just hardcoded them into the application code. These applications have evolved over many years — and in some teams, no one even knew how things work — and was hesitant to do even a minor change. Also in some teams there were people who were very much comfortable with what they have — but then again were reluctant to move away from their comfort zone. Technically itself the project was challenging — but the most challenging part was to bring all the teams to a common understanding.

Another company I talked to, for more than 2 years now still struggling to kick-off their IAM initiative. It’s not because they have not enough budget, or technically competent people — but mostly the disconnected decision makers. In this particular case, the key challenge was to come up with a model to build a unified identity model across all the applications. They had more than 30 identity stores used by multiple applications — and the same user is duplicated in each identity store with no correlation handle. These applications were developed by different teams with different technologies — and each department manages the users in their own identity store. It’s a quite feasible problem to solve technically — but first, each department must make it clear how they would need to proceed with.

These are not isolated stories — I am pretty sure it’s the story of many large enterprises who have not planned the growth carefully. When an organization grows, the best approach would be to have small functional teams. Jeff Bezos, the Amazon CEO calls this two-pizza teams — any team should be small enough to feed with two pizzas. Netflix follows a similar approach, with their microservices based architecture. Each team owns a set of microservices. The book, The Connected Company by Dave Gray talks about a similar model with pods. Dave argues in his book that if you want an adaptive company, you will need to unleash the creative forces in your organization, so people have the freedom to deliver value to customers and respond to their needs more dynamically. One way to do this is by enabling small, autonomous units that can act and react quickly and easily, without fear of disrupting other business activities — pods. A pod is a small, autonomous unit that is enabled and empowered to deliver the things that customers value.

Let me share with you couple more examples (stories). These are in fact good ones. Few weeks back we met a company, which is in the pharmaceuticals industry. It’s a huge one — with more than 60,000 employees. They have a very good organizational structure with multiple business units. Each business unit has it’s own CIO — and each one of them can operate autonomously — making their own technical decisions. At the same time, they have a corporate IT team which provides shared services for all those business units — such as IAM services. But, then again, if one business unit has some IAM requirements, it’s their decision to build it at the business unit level or get it from the corporate IT team. To win a deal, even the corporate IT team has to compete with outside vendors. This model of empowering each business unit to make their own decisions, helps organizations to move forward rapidly, without waiting to build an all-in-one solution for the entire company. I have seen a similar model being used by another customer. They do have more than 10,000 employees — and once gain operates in different business units. Each business unit has their own IAM products — and the shared services team has built an Identity bus, linking the trust between the business units.

Seed What Harvests Soon

Graham Williamson highlights in his latest book, Identity Management: A Business Perspective, that in many cases business managers are unaware of the changes in technology that now make identity management, a viable option for small organizations. Whereas a few years ago it was typically difficult to justify the deployment of an identity management system in a company with fewer than 10,000 employees, organizations with as few as 1000 employees can now afford a full-featured identity management system.

The evolution of cloud based identity management systems and many open source identity management products have brought down the cost of IAM initiatives immensely. The need to pump in millions of dollars to ‘big’ names is no more required. At WSO2 we build a completely open source IAM product — and our business model is to provide production support. This is the business model most of the open source businesses do follow. The production support, gives you a guarantee that in case anything happens with the product, which critically blocks your business operations, there will be a team to look after that issue and provide a solution under an SLA (service level agreement) — it’s like an insurance. But still at WSO2 we have seen, many people using our product in production, without paying us a penny. Once again, that’s totally fine with us too, given that you take the responsibility of managing it.

Okay, then — what’s the challenge? As Graham highlighted in his book quite rightly, not many top level managers do not understand this change happened in the IAM domain — and reluctant to think about IAM as a function, that will directly have a positive impact on the day to day business operations. They are ready to pump money on massive ERP (enterprise resource planning) solutions — but not on IAM. They are ready to invest time and money on projects where there will be quick ROIs (return on investment). Even though open source software save millions of dollars from their annual budget — there are cases some managers do question, the need to invest on buying production support.

The resistance to invest on IAM initiatives — and trying to keep them under a low budget prevents anyone from enjoying the benefits of it — hence leads the way to another unsuccessful IAM initiative. For those who are interested in learning what real (and direct) benefits IAM initiatives can bring into your enterprise, I would invite to read this blog I wrote few weeks back.

Do It Myself! — I Build My Own IAM

There are few reasons why some enterprises prefer a homegrown IAM solution over a vendor developed product: limited budget, complex requirements, control over the code and historical reasons.

I do not argue that, homegrown IAM solutions are always bad. Many larger enterprises, who have enough budget, time and people to invest on such IAM initiatives have no reason to fail. Google, Amazon, Salesforce and many other top technology companies build their own IAM solutions — and later even make it ready to sell as a service to the rest. Not just IAM, the big technology companies do it almost for anything they need. This is mostly to keep control over the code — so that they can innovate at their own pace. Also, this necessarily does not mean they build everything from scratch — they probably will start with open source software, fork them internally and start building on top of that — and probably later contribute their improvements back to the community as well. For example, the Marketplace data team at Uber has built a scalable complex event processing platform to solve many challenging real-time data needs for various Uber products, using WSO2 Siddhi. Siddhi is a lightweight, easy-to-use open source streaming complex event processing engine (CEP) released as a Java library under Apache Software License v2.0 — developed by WSO2. We only knew Uber is using Siddhi, by following one of their meetup talks.

Not many business are at the scale of Google, Amazon or Uber. Their preference for a homegrown IAM solution is not always the control over the code. IAM wasn’t as prominent as today ten/fifteen years back. Many companies started building their own solutions — then again the requirements weren’t complex as they are today. They mostly worry about managing employees for the payroll, possibly enable employees to login to couple of web applications with the credentials stored in an Active Directory or an LDAP server. Under the Forrester Identity Management Maturity Model, these IAM infrastructures fall under level-0 or level-1. Now the challenge we face today is, these IAM systems evolved over the past — making them more bulky and fragile. And, the most scary part is people still want to live with them, move forward with them.

Forrester Identity Management Maturity Model: Nonexistence (level-0): No identity management system in place — and do not realize the need. The Human Resource (HR) department possibly maintains a spreadsheet to manage all the employee information and their salaries. Ad hoc (level-1): Occasionally, not consistent, not planned, disorganized. Not all the applications require users to login and access. Repeatable (level-2): Intuitive, not documented, occurs only when necessary. Defined (level-3): Documented, predictable, occurs only when necessary. This is a better version of level-2. Measured (level-4): Well-managed, formal, often automated, evaluated frequently. Optimized (level-5): Continuous and effective, integrated, proactive, usually automated.

Many of the WSO2 customers I have spoken with, carry complex IAM use cases. Very rare you get a chance to start fresh — specially with large enterprises. They carry lot of baggage with them, which cannot be thrown away immediately. I do not think, you have to either. Integrating with legacy systems and custom protocols are two key challenges any IAM product will face. For some this is a driving force to use open source software — and get the vendors to build the features they need on top of it. I like that approach (not because I represent a company which produces open source software), because it takes out the burden of managing those components from the business — and hand it over to the vendor. At the same time, this same reason forces some to build homegrown IAM solutions. I remember a couple of customers I spoke with picked this path — mentioning there are no IAM vendors out there to support what they need. It’s a risky path to take if you are not ready to do the right level of investment. Also — some who pick a homegrown IAM solution because of the budget, end up in spending few times more than what they would have paid for a vendor.

You should not try to build a homegrown IAM solution in-house, if you do not have the right-level of expertise. IAM infrastructure is the most sensitive part of your business. One little account hijack can end up your company in bankruptcy. Also — if you are a small company, you can focus more on what you can do better, by delegating the management of the IAM infrastructure to a vendor whose expertise is in that domain. Not just small companies — but even big companies like, Coca-Cola, Netflix, LinkedIn, Toyota, Nissan and many more prefer outsourcing IAM infrastructure to a third party vendor.

Buzzword Lovers

Several years back SOA (service oriented architecture) and ESB (enterprise service bus) are the most popular buzzwords. Everyone wanted to have a SOA or an ESB. Buzzwords are best for the vendors who are willing to sell crap hidden in those. Then came the slogan, no SOA deployment exists with no ESB. Happy and crappy, ESB vendors lobbied around that — and many architects bought into the idea. Good luck for them! Some of those projects never hit production deadlines and went over-budget. Fast-forward to today, both SOA and ESB faded incrementally — long live Microservices and API Gateway. I am sure the industry is much informed today not to fall into the same trap again. What drives your business is what you need — not the buzzwords.

Let’s get back to IAM. Go to an identity conference, you’ll get an earful of buzzwords. Buzzwords give most people an adrenaline rush. Some time back, I met a person who was a great fan of XACML. XACML is an OASIS standard for fine-grained access control. It defines a reference architecture, an XML-based policy language and a request/response protocol. It’s extremely powerful. The power of XACML comes with an overhead in usability and manageability. To dig a little hole in your garden, you do not need a huge excavator — but a small hand fork. If you are looking for a simple access control model based on roles — you need not to invest on XACML. Unfortunately in this case, our XACML fan drove the project to use XACML and spent months in building XACML policies — just to represent simple access control rules — and ended up with hundreds of XACML policies. This created a maintenance nightmare and the project went well passed all its deadlines. I don’t blame XACML — you need to equally weigh both the pros and cons of any technology, before using it.

Let me give you another example. A couple of months back we got a lead asking about UMA (User Managed Access). UMA is a very promising standard developed under Kantara foundation. At WSO2 we have an UMA 1.0 implementation and at the moment working on upgrading it to UMA 2.0, which was released very recently. UMA to add value, there needs to be a strong ecosystem around it. In this particular lead, they try to drive the project in the direction of UMA — but only thing they need was to have a way to define policies at the identity provider (or the authorization server), which can control how the tokens are issued. UMA is an over-kill for such use case, and in fact UMA does not define such a policy language.

The Green Swan

The identity standards are not born alone. There are many committees under the standard bodies such as W3C, IETF, OpenID Foundation, OASIS, Kantara Initiative and many more, working day and night with absolutely amazing people, discussing the problems in the identity space, building solutions and standardizing those. Once you define your problem, you should spend some time and see how the identity standards out there, help you in building a solution. Once again, do not get driven by the standards, but by your own problem statement. There is always room for an improvement. If you do not find your problem being addressed properly, don’t be hesitant to build the solution by fixing it. Then if you would like, you can take your solution to a standard body and see how it can made its way to a standard. This is how the identity standards evolved over the years. That’s my take on the standards.

No matter what, you will find people in some project teams, who hate standards. They will simply find some article or a blog, which says this ‘foo’ standard is not secure enough or dead, and lobby that idea across the team, with no in depth fact finding. In June, 2012, Eran Hammer — who is the lead author and editor of the OAuth 2.0 specification by then, stepped down and launched a fire-fight against OAuth 2.0. He wrote in his famous blog, OAuth 2.0 and the Road to Hell, — They say the road to hell is paved with good intentions. Well, that’s OAuth 2.0. Even through those were early days in OAuth 2.0 — still it triggered lot of discussion. It was the time we were developing OAuth 2.0 support for WSO2 Identity Server, and we were questioned whether we are building a dying standard. Fast forward to today, OAuth 2.0 has evolved a lot — and has become the de facto standard for securing APIs. Most of the developments happened in last two years preferred OpenID Connect over SAML 2.0, where OpenID Connect is a standard built on top of OAuth 2.0.

In May 2013, a Forrester analyst published a blog predicting XACML is dead. Some started quoting this in an effort to not to use XACML. People only see what they want to see. Many critics, who quoted the above, didn’t even notice this other blog, published by Ian Glazer (who is the VP, Identity Product Management at Salesforce today): Anyone can kill off a protocol a.k.a XACML isn’t dead.

Any team should be aware of these “Green Swan” type people — who want to special case them. They hate standards — they hate patterns and they want to treat themselves special and start rebuilding everything from scratch. And finally end up in a mess causing the project to miss all it’s planned deadlines.

Swiss Army Knife

Recently we got a lead having a very interesting problem. They have started building their own IAM solution on top of an ‘open source’ IAM product. As their requirements evolved, they’ve started customizing the original source code of the product, and kept on adding new features. Today, more than 50% of the code running to address their requirements are written by them. Most of these new features are in fact not directly related to IAM — but application specific. For example, they store user information and business data related to users in different data sources. Different applications write into these data sources — and all the data written into these data sources has to be aggregated / correlated and written into another data source. This aggregation and correlation part needs to happen in every 10 minutes. They’ve found a workflow engine and a task scheduler in the IAM product — and wrote their own workflow embedding the aggregation/correlation logic, and using the task scheduler, scheduled it to run in every 10 minutes. This is not an IAM use case — but an integration problem, where they just need to have a BPEL engine.

The scary part is not just this — they have done so many other custom work inside the IAM product to address the needs of the up stream applications. Today, they are very much worried about the support they get from the vendor behind this open source IAM product. But then again, they cannot quite easily move to another vendor, as the custom components they have developed will not run outside this product. To make things much scarier, even though this product is open source, you cannot run it in a production environment without a subscription — so, they cannot even terminate the support from this vendor. To run their own code (more than 50%), this customer is paying for a product vendor — bit hilarious.

This is a repercussion resulted from not identifying clear functional boundaries — and trying to turn the IAM infrastructure into a Swiss army knife. Let me give you one more example. Another lead came to us, who I spoke with, has a set of web applications which do user registration. During the registration process we need to match the user provided data with the data stored in Salesforce. For example, this is a case where you sell something to one of your customers (then updates Salesforce) — and later the customer signs up with you to use your online services. Now the customer has to provide the information related to what he/she bought from you, to sign up — like the insurance policy number, serial number. This provided information must match with what is stored in Salesforce. This particular lead, once again using an ‘open source’ IAM product, has customized the signup flow to check Salesforce, with all the business logic. The user registration web app calls an API in the IAM product — and during the execution of the registration API, it fires the custom code to check Salesforce. This logic has evolved over the years — and whenever there is change in the requirement from the application side, the custom code in the IAM product has to be changed. This makes the IAM infrastructure brittle, and a maintenance nightmare. There are couple of ways to do this correctly. The best approach is to run the business logic out side the IAM product, before calling the API, at the application side. If we are to execute this from inside the IAM product, then avoid having business logic there — but simply call an API, outside the IAM product (hosted in your own application server), and have the business logic implemented under that API.

We should avoid thinking an IAM product as a Swiss army knife — and get all our complex business logic to run inside it for just short-term benefits.

Short Sighted

IAM projects fail at different stages. Some at the very initial stage, even before the kick-off. Some fade slowly — but when they do, they take the entire business down with them. The scalability of the IAM infrastructure is the key to the success of any project. The short-sighted project management will not worry about the future — but just keen to get something up and running to hit the short-term goals. Before evaluating any IAM project, you should have an idea about the load you anticipate today — and at least in 6 to 12 months. Few things you need to worry about are the number of concurrent login requests, number of concurrent login sessions and number of users.

Most of the projects start with a low number of users — and a low traffic rate. The tricky part is, in some projects there is a huge difference between the average load and peak load. One of the customers we work with had a requirement to have 350,000 logins per day, over 24 hours. That is roughly around 4 tps (login requests per second). But they expect a peak load twice each month —which is 5100 tps. That’s 1275 times the average load. It looks bit unrealistic — but it’s part of the business they are in. For example, most people will login into a SaaS based payroll system on their pay day. How do you do capacity planning for such cases? It’s hard. We cannot have both software and hardware, provisioned to handle the peak load all the time. That’s a massive waste of resources. One option is to do dynamic scaling. The system will spin up new nodes, when the load increases and spin off, when the load goes down. When evaluating an IAM product, if you do not worry about the support for dynamic scaling, the project will fail — or you’ll end up paying for mostly unused resources — that’s a failure too.

For any IAM project, extensibility of the underneath product is critically important. If you look at the last 5 years of the IAM industry, you’ll find out how fast it’s evolving. SAML ruled identity federation and SSO domain for many years — and today it’s OpenID Connect which leads with the baton. Also if you look at the history, most enterprises grow today via acquisitions, mergers and partnerships. In U.S only, mergers and acquisitions volume totaled to $865.1 billion in the first nine months of 2013, according to Dealogic. That’s a 39% increase over the same period a year ago — and the highest nine-month total since 2008. What does this mean to enterprise identity management ? You would have to work with multiple heterogeneous user stores — authentication protocols — legacy systems and many more. If your IAM infrastructure is only to address the short term goals, and cannot extend, soon it will become a legacy — a maintenance nightmare. Further, it will be costly to introduce any new features.

Building/Operating In Silos

People in different departments/units often do their own things — which leads into operation silos, but the true advantage for the business comes from linking these different activities. For example, Nike as part of its digital transformation initiative built Nike Digital Sports in 2010 to provide coordination, innovation and some shared resources for the company’s many digital efforts. When systems are designed from the scratch without coordination in mind, even a simple integration will become quite costly.

Many companies do store customer/lead data in different data sources — and possibly managed by different departments. For example, companies may use multiple disconnected data sources/systems, such as: customer relationship management (CRM) systems (like Salesforce, Sugar CRM, Microsoft Dynamics, Net Suite CRM, etc), marketing platforms/solutions (like Dataxu, Appboy, MailChimp, Google Analytics, Salesforce Pardot, etc), e-commerce platforms (like Shopify, Magneto, Oracle Micros, etc), fraud detection solutions, risk engines, content management systems (like Microsoft SharePoint, Drupal, WordPress, Joomla, DotNetNuke, etc), data management platforms (like Blueconic, DoubleClick, Lotame, Krux, etc) and many more. Once things are disconnected, even though the individual project can be successful, still as a whole it will fail, as it will be a very costly operation to build a unified profile of a given lead/customer.

One initiative you should worry about in such cases, to add more value to the company is, CIAM (customer identity and access management). A CIAM system provides ingredients to nurture an anonymous user to a well-known customer — but providing necessary integration between originally disconnected systems. Progressive profiling is one aspect of a CIAM system. It is the process how the system learns about a customer in a progressive manner. First, the anonymous user is just a visitor to the company web site. His/her preferences can be tracked via cookies and can promote the content that is more interesting to him/her. At one stage, the anonymous user will become a lead, by filling a contact form. Now the CIAM system has the opportunity to link all the preferences tracked against the anonymous user with the new lead. Over the time the preferences of the lead can be tracked in a much meaningful way — and the company’s marketing/sales team can work in a collaborative manner to make him/her a customer. At this point you collect the most reliable data about the customer — with proper verification. Then again from there onwards, the CIAM system will keep tracking customer preferences — and will produce more meaningful data to the company management to make much informed decisions.

Having a vision to the company’s IAM initiative is critically important. Once you have a vision — you can set the directions to each department towards what needs to be done — and finally how everything can be integrated together to produce more value to the company.

Vendor Lock-in

You will not experience vendor lock-in in short term. But in long run, when you start building your IAM infrastructure on top of a vendor product, you will get more and more dependent. Already we talked about a company who developed 50% of the running code themselves, but got locked into a product due to the nature of its license. Due to the large amount of customization they did in a vendor dependent manner made them tightly coupled to the product. Some companies — not just develop extensions to their IAM product — but also build their entire application stack, based on the vendor APIs. Once again, this is a result of short-sighted project management and engineering. Application data can also make you locked in. This could mostly happen with cloud based IAM vendors. If they do not provide an option to export your data, you will find it hard — and also quite expensive to move away from the vendor. Even if these cloud IAM vendors do support data export, it will be still hard and expensive to build tools to interpret and make them meaningful (and also functional).

Vendor lock-in is one reason why one should pay more attention to open source and open standards. I may be little bias to open source — as I represent a company which produces open source software, but then again I invite you to do a self-validation against the facts I present here. Any open source software released under Apache 2.0 license gives you the freedom to do anything with it. It’s the most business friendly open source license. You can use any software under Apache 2.0 license freely in a production environment — also can extend it’s functionality — and the best things is, you can develop something proprietary out of it and even sell if you’d like to.

GPL is another open source license. Unlike the Apache 2.0 license, the GPL embeds the decision as to the code’s open source nature into the code itself: if you use the software, you must release any derivative work as open source. You have no choice. In other words, the GPL is a copyleft license, which means that derivative work can only be distributed under the same license terms. LGPL makes GPL little flexible. Unlike GPL, if you use any libraries/products under LGPL, when you redistribute you only need to have the same LGPL license for those those components only — for the rest you can pick the license of your choice.

Common Development and Distribution License (CDDL) is another open source software license, produced by Sun Microsystems based on the Mozilla Public License (MPL) version 1.1. CCDL permits commercial licensing for the executable software (what you download as a binary) while retaining open source requirements. In other words none of the CCDL products (if you download as binaries) can be used in any production setup without a commercial subscription.

Even if you use open source software, you should alway try to stick to open standards between your applications and the IAM product. In case if you have written code against a non-standard product API, then make sure first you develop a wrapper from your application side to make sure your application is not tightly coupled to the IAM product’s API. If you decide one day to go for another IAM product, you only need to change the wrapper. That will be a less costly option.

Summary

In this blogpost we discussed ten reasons what would cause an IAM project to fail. Some IAM projects fail at the very initial stage, even before the kick-off, while some fade slowly — but when they do, they take the entire business down with them. The blogpost also shared some tips to avoid such failures to build an IAM project under a healthy atmosphere. You may agree or disagree on the points/facts presented here — in either case, I would like to invite you to share your thoughts in the following comments section. Let’s build some constructive discussion around this.