Why Not All IAM Projects Cross the Finish Line

According to a study conducted by KPMG in 2009, 75% of IAM projects deliver less than expected. In a study conducted by McKinsey & Company in conjunction with the University of Oxford, 17% of large IT projects perform so poorly that they can threaten the very existence of the company. This study used 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, the poor estimates are to be blamed. According to the book, The Mythical Man Month-Month by Frederick P. Brooks Jr., more software projects have gone awry for lack of calendar time than all other causes combined. This book points out five key deficiencies in how estimates are done:

1. 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.
2. Estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.
3. Since we are uncertain of our estimates, software managers often lack the courteous stubbornness of the rest.
4. The schedule progress is poorly monitored.
5. 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 instances where you google for why software projects fail, the blame goes to the estimates and project management. I would like to present a different view. Although my discussion mostly relates to IAM projects , I believe some of them are equally applicable to all software projects. Ever since I joined WSO2 more than ten years ago, I have had the opportunity to talk to many customers  - many from Fortune 100 companies. One thing I cherish in my day job at WSO2 (and in my life) is every single opportunity I get to speak to a customer. Listening to customers helps you to understand their pain, expectations, and challenges. Not everyone I talk to become a WSO2 customer , but they leave me with something to think about nevertheless. Here, I will share my experience and views as to 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 completed 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, whereas an RFP asks more specific questions. Either way, most RFIs/RFPs are filled with tons of questions!

RFPs/RFIs are done at the very early stage of a project — and most probably people who write these do not exactly know what they need — so they choose the safest or the easiest path. They know they need an IAM project, hence they look for a couple of products out there in the market (possibly from a set of well-established vendors),  copy the features list as the requirements, and publish as an RFI/RFP. This will cover more than what you need — some features will never be used — and 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. Yet, not 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 the 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. 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 will you find out how much more you pay for a set of idling features sitting on your server rack.

There is a scarier 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. A similar proposal can be made by a vendor who’s having an ‘yes’,  but with a very high cost. By solely relying on ‘yes’s and ‘no’s in the RFP/RFI, you lose the best deal. For 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 completely 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 at 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 ed— and were hesitant to do minor changes even. In some teams there were people who were very much comfortable with what they had but  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 had been struggling for over 2 years to begin their IAM initiative. The delay was not due to lack of budget or technically competent people  but mostly due to 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 was duplicated in each identity store with no correlation handle. These applications were developed by different teams with different technologies  with each department responsible for managing the users in their respective identity store. It’s a quite feasible problem to solve technically — but first, each department must establish clarity on how they would need to proceed.

These are not isolated stories . As an organization grows, the best approach would be to have small functional teams. Jeff Bezos, the Amazon CEO calls these 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 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. 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.

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. 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, whereas organizations with as few as 1000 employees can 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 longer required. At WSO2 we build a completely

I do not argue that homegrown IAM solutions are always bad. Many larger enterprises with sufficient budget, time, and people that invest in such IAM initiatives have no reason to fail. Many top technology companies build their own IAM solutions  and later even sell these as a service to the rest. Such companies maintain control over the code  so that they can innovate at their own pace. This also does not necessarily mean they build everything from scratch — they will probably start with open source software, fork them internally, start building on top of that, and later  contribute their improvements back to the community as well. Yet not all businesses prefer to build their own IAM solution to maintain control over the code. IAM wasn’t as prominent as it is today ten/fifteen years ago. Many companies started building their own solutions, when requirements weren’t as complex as they are today. Their main concerns include managing employees for the payroll and possibly enable employees to login to a couple of web applications with 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. The challenge we face today is that these IAM systems evolved over the past — making them more bulky and fragile. And the scariest part is that people still want to live and move forward with them.

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 account hijack can result in bankruptcy for your company. 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 an expert in that domain. It's not only small companies that outsource IAM infrastructure to third party vendors - even larger ones prefer to do so.

Buzzword Lovers

Several years ago, SOA (service oriented architecture) and ESB (enterprise service bus) were the most popular buzzwords. Everyone wanted to have a SOA or an ESB. Fast-forward to today, both buzzwords have faded incrementally, and it's  long live Microservices and API Gateway. What drives your business is what you need — not the buzzwords.

The Green Swan

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 these. Once you define your problem, you should spend some time researching identity standard, to help you build a solution. Once again, do not be driven by the standards, but by your own problem statement. There is always room for improvement. If you do not find your problem being addressed properly, don’t be hesitant to build the solution by fixing it. Then you can even take your solution to a standard body and see how it can made into a standard. This is how identity standards have evolved over the years.

You will find people in some project teams who hate standards. They will simply find some article or a blog, which states that a particular 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  (lead author and editor of the OAuth 2.0 specification back 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 though those were early days in OAuth 2.0 , it still triggered a lot of discussion. This was the time we were developing OAuth 2.0 support for WSO2 Identity Server, and we were questioned as to why we were building a dying standard. Fast forward to today, OAuth 2.0 has evolved a lot  and become the de facto standard for securing APIs. Many developments in the past two years have preferred OpenID Connect over SAML 2.0, where OpenID Connect is a standard built on top of OAuth 2.0.

Any team should be aware of the “Green Swan” type of people who dislike standards and patterns, decide to start rebuilding everything from scratch, and would eventually end up missing all planned deadlines.

Swiss Army Knife

I once deal with a very interesting problem. An organization I came across had 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 continued to add 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 are in fact 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  - all the data written into these data sources have to be aggregated/correlated and written into another data source. The aggregation and correlation part needs to happen every 10 minutes. They’ve found a workflow engine and a task scheduler in the IAM product , 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. Furthermore, they have done many other custom work inside the IAM product to address the needs of the up stream applications. They cannot switch their vendor easily, as the custom components they have developed will not run outside this product. To make things rather frightening, even though this product is open source, you cannot run it in a production environment without a subscription . Hence, they cannot even terminate the support from their vendor. This customer is now paying a product vendor, to run their own code (more than 50%)!

This is a repercussion which has resulted from not identifying clear functional boundaries — and trying to turn the IAM infrastructure into a Swiss army knife. We should avoid thinking of an IAM product as a Swiss army knife   and get all our complex business logic to run inside it merely for short-term benefits.

Short-sightedness

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

Many projects start with a low number of users  and a low traffic rate. The tricky part is that in some projects, there is a huge difference between the average load and peak load. For example, many people will login into a SaaS based payroll system on their pay day. How can 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 decreases. 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 — which is 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 has taken the baton. In addition, when looking at the history of these enterprises, many grow today via acquisitions, mergers, and partnerships. In the US alone, mergers and acquisitions volume totaled $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 for enterprise identity management? You would have to work with multiple heterogeneous user stores , authentication protocols , legacy systems, and many more. If your IAM infrastructure only addresses short term goals and cannot extend beyond that, soon it will become a legacy —and  a maintenance nightmare. Furthermore, introducing any new features will be costly.

Building/ Operating in Silos

People in different departments/units often do their own thing, leading to operation silos. However, 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 scratch without coordination in mind, even simple integration will become quite costly.

Many companies do store customer/lead data in different data sources , possibly managed by different departments. For example, companies may use multiple disconnected data sources/systems, such as: customer relationship management (CRM) systems (Salesforce, Sugar CRM, Microsoft Dynamics, Net Suite CRM, etc.), marketing platforms/solutions (Dataxu, Appboy, MailChimp, Google Analytics, Salesforce Pardot, etc.), e-commerce platforms (Shopify, Magneto, Oracle Micros, etc.), fraud detection solutions, risk engines, content management systems (Microsoft SharePoint, Drupal, WordPress, Joomla, DotNetNuke, etc.), data management platforms (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 since 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, and which will also 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   by providing necessary integration between originally disconnected systems. Progressive profiling is one aspect of a CIAM system. It is the process by which the system learns about a customer in a progressive manner. First, the anonymous user is simply a visitor to the company website. His/her preferences can be tracked via cookies and can be used to promote content that is more interesting to him/her. At one stage, the anonymous user will become a lead by completing 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 time the preferences of the lead can be tracked in a more 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  to produce more meaningful data that enables the company's management to make more informed decisions.

Having a vision for the company’s IAM initiative is critically important. Once you have a vision  you can guide each department to achieve what needs to be done so that everything can be integrated together to produce more value for the company.

Vendor Lock-in

You will not experience short term vendor lock-in but in long run, when you start building your IAM infrastructure on top of a vendor product, you will become more and more dependent. I've already mentioned a company that developed 50% of the running code themselves but got locked into a product due to the nature of its license. Some companies  not only develop extensions to their IAM product   but also build their entire application stack based on vendor APIs. Once again, this is a result of short-sighted project management and engineering. Application data can also lead to lock-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 nevertheless be hard and expensive to build tools to interpret and make them meaningful and functional.

Vendor lock-in is one reason why one should pay more attention to open source and open standards. (I may be little biased towards open source  as I represent a company which produces open source software, but 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 , extend its functionality, and the best things is, you can develop something proprietary out of it and even sell it if you’d like to!

You should alway try to stick to open standards between your applications and the IAM product. In case you have written code against a non-standard product API, then make sure you first 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 to use another IAM product someday, you only need to change the wrapper. This will be a less costly option.