IAM Myth: Identity Management Big Bang

This analysis-design-implementation approach is in fact a well-known software development technique called the Waterfall model. While it was first documented as early as the 1970s, it is still being used today. It is elegant, straightforward and easy to understand. The problem is that this method is fundamentally flawed. It just does not work. Any minor problem in the early project phases is amplified in later phases, and the methodology does not have any correction mechanisms to deal with it. This technique was the reason for huge number of failures in software projects in 20th century. Software engineers know this very well, and no reasonable software engineer would ever voluntarily use waterfall technique anymore. It was replaced by iterative & incremental development methods long time ago.

Waterfall technique is flawed and software engineers abandoned it. However, other fields of the industry are still using it. It is even recommended as the best practice! This is simply insane.

What’s wrong with this method, exactly? It looks like a good fit for identity management projects at the first sight. Let’s have a look at it step by step:

Requirements: Have you ever met anyone who knew exactly what he needed? Not what he wanted, but what he really needed. Identity management is one of fields where requirements are especially vague. Existing processes are usually based on human judgement ("if the request looks good I’ll approve it", "I type in a suitable identifier"). Such processes are extremely difficult to formalize. The customers also tend to want features which they do not need (100% automation of process "X") and neglect the aspects that they really need (visibility, reliability, consistency, …​)

Analysis: Before an identity management solution is in place, the data and processes are usually processed manually. People are very bad at objective judgement, especially when it comes to data quality. People easily overlook errors in data sets and correct them without thinking when they process data manually. However, machines cannot do this. Any error in a data set can cause a major delay in the project. Even worse, it is almost impossible to see all the errors if the data from different systems until the data are not analysed by a machine and properly correlated. Moreover, there are usually huge gaps in the input data provided for analysis. E.g. system administrators often do not know exact meaning of each account attribute, they are too busy (or unwilling) to respond at all and so on. The bottom line is that analysis phase is likely to miss many major obstacles in the project.

Design: We engineers often tend to overestimate our intellectual abilities. The sad fact is that there is perhaps not a single person in the world who could design a complex system flawlessly at the first try. Everybody makes mistakes. Even worse, this game is rigged from the start. The old saying goes: garbage in, garbage out. Design is based on requirements and analysis. As analysis already contains a huge gaps and inaccuracies, there is almost zero chance for the design to be right.

Implementation: The system is implemented as designed. As it is extremely unlikely that the design was correct, the implementation is doomed to be flawed. What is worse is that the small mistakes of analysis and design are significantly amplified during the implementation. What was a simple mistake in single paragraph of design specification may easily mean thousands of lines of code that are useless. Huge amount of money is wasted. However, nobody knows about it yet. Everything works just fine in the development environment.

Testing: There two ways to do testing in waterfall model: bad and worse. Bad testing is verifying whether the implemented system satisfies the requirements. However, as requirements are often very vague and cannot be easily formalized, this testing really does not tell much about the solution quality. As it is always very difficult to transform requirements to testing scenarios, an alternative approach is used. This where it gets worse: testing scenarios are based on the design. Therefore, the system is verified whether it was implemented as designed. Which tells almost nothing about system qualities. The design was wrong (we know it was) and the system was implemented as designed. If all the tests pass, then it only indicates that the implementation is as good as the design: it is all wrong.

Deployment: Everybody expects success, applause and a big party at this stage. Yet, this is actually the very first time when the developed system meets the reality. This is not a nice meeting. All the small mistakes were hugely amplified, and the result just does not work. This is the part where everybody panics. Problems are quickly fixed to somehow pass the minimum requirements for system acceptance. Deadlines are missed, budgets are blown, managers go crazy.

All of this usually takes at least a year, sometimes 2-3 years. It produces a lot of documents, diagrams, project plans, meeting minutes and other kind of very expensive but mostly meaningless papers. However, the end result is almost invariably a very expensive but inferior identity management solution - if it works at all.

The solution is the same one which worked for so software engineering: iterative & incremental development methods. Do not even try to deploy identity management solution in one huge project. Divide the effort into several iterations. Each iteration should not be longer than few months. Each iteration should contain all the activities: a bit of requirement analysis, a bit of design, implementation, testing and deployment. The first iterations naturally tend to be more focused on "papers", but they should also include prototyping and testing. The last iterations focus much more testing and deployments, but there should also be manpower available to rethink parts of the design if needed. It is crucial that each iteration ends with something tangible, that it confronts the theory (papers) with the implementation (code) and reality (deployment). This is the way how to identify mistakes early and do not amplify them in later phases.

Identity management deployment is not a project, it is a program. It has a start, but it does not have an end. It is an ongoing, iterative and incremental activity. It is never really "done". Pretending that identity management can be purchased and it can be "done" is not going to do any good. It is much better to admit the reality and adapt to it. Identity management and especially identity governance is an ever-evolving thing. It has to be incorporated as native part of your business.

There are methodologies that have adopted the iterative and incremental approach as their core principle. The First steps methodology developed by Evolveum is a recommendation for deploying midPoint platform in an incremental and iterative way. Even though this approach is relatively young, it has already proven itself many times over. Although it was designed for midPoint, it can be adapted for any reasonable identity management platform.

It may seem that the extra development, testing and deployment activities in each iteration are expensive. However, that is relative. They are much less expensive that the work which is plainly wasted in waterfall-based methods. The sole fact that this method avoids the panic and severe damages caused by the waterfall deployment phase is just …​ priceless.

Iterative and incremental techniques are far superior to waterfall-based techniques. There is no doubt about that. However, there is one business-related drawback: Commercial identity management systems are expensive. The cost is concentrated at the beginning of the project (licensing, support, SaaS subscriptions). This cost is quite high. Therefore, the identity management project needs to bring substantial benefits to justify this cost. Otherwise, the return on investment (ROI) calculation does not go well, and the project won’t get approved. It is just not realistic to bring a huge benefit in a short project. Therefore, deployment project that include commercial identity management products needs to be huge and long …​ and usually quite risky.

This is all very different with open source identity management products. Open source products do not have huge initial cost. There is no licensing cost and the cost of support can scale gradually as the project rolls out. There is no need to purchase expensive licenses or SaaS subscriptions just to start experimenting with the product. Therefore, open source software makes it possible to have a series of smaller iterative identity management projects to gradually develop an appropriate solution. The cost of the project is increasing slowly and gradually, and it is proportional to the benefit that the result brings. Both financial and technological risk is significantly reduced. This is a recipe for a good IGA program that suits the customer needs and, that can adapt to a changing requirements and which is still economically feasible.