No off-the-shelf IDM solution matches customer requirements perfectly. All IDM solutions needs to be configured and customized to be useful – and all self-respecting IDM products are built to support this. However, if the solution is customized too much, it can cause huge problems. This is known as “customization trap”.
Back in early 2000s I was a young software engineer. Our team has been preparing for a relatively big IDM project. IDM was quite an obscure technology back then. There were directories, meta-directories, virtual directories, but only a very few real IDM solutions. I have selected a relatively unknown product called “Waveset Lighthouse”. Preparation was successful, the product was a good choice and the project went on. Just in the meantime Waveset was acquired by Sun Microsystems and the product was re-branded to “Sun Identity Manager”.
Customer expectations were very high. Some requirements would not be easy to satisfy even with today’s technology. Being customer-oriented and having a decent product we were set to satisfy all customer requirements. This was our first real enterprise IDM project. But we were a good team and therefore in the end we were successful. But there was also a dark side to this project. A very dark side indeed. But at that time it was all hidden deep inside the code and waited for the right moment to show its ugly head.
Couple years later it was time to update the solution to a new version of the product. And that’s where we have realized that we cannot do it. The customizations that we have made were entangled into the system. Any attempt to upgrade the product broke almost all of the customizations. The easiest way was to start with new product version and re-implement the customizations. Again. This was very painful process. Also, some requirements have naturally changed as the customer used the system for some time and gained more experience. Therefore, the “upgrade” project was almost the same effort as the initial deployment. Although technically both projects were a success, the “upgrade” part was a miserable financial failure.
This is the “customization trap”: If you customize the product too much you won’t be able to maintain the solution.
I was a young engineer at that time. Our team was exploring an emerging enterprise IDM field. We had decent technology, but the technology was proprietary and it was still quite new. In the hindsight it is quite obvious that we could not possibly avoid this trap. Hindsight is a strange thing. It seems perfectly clear now. How can anyone ever make such mistake? But I did. And lot of other engineers did the same thing.
But, wait a minute! Isn’t this some kind of inherent trade-off? Maybe, if we need a maintainable system, we have to avoid customization and just use off-the-shelf functionality. Good idea – in theory. But in practice every IDM deployment is different. You won’t be able to have an IDM business without customizations. Does this mean that we are doomed to maintenance nightmares? Will we burn in software engineering hell for all eternity? In late 2000s the IDM future was not exactly bright. And then it got worse.
In 2010 a disaster happened. Sun went down. Sun Microsystem got acquired by Oracle. And a while later Sun Identity Manager was practically dead. But how much damage can one dead product make? At that time there was a lot of products on the IDM market already. We have tried a few, but we have soon realized that they are really bad. We were desperate. Desperate times call for desperate measures. But fortunately, there was a good result at the end: Evolveum midPoint.
Seven years of hard work later, MidPoint is now the most comprehensive open source IDM and identity governance system available on the market. But when we created midPoint I have sworn to learn from my past mistakes. And the mistake of falling into the customization trap still rings in my memory up to this day. But how can we possibly solve this unsolvable problem? Turns out that this problem is unsolvable only if you insistent on “closed” mindset. In traditional closed/proprietary world it really seems to have no good solution. But things are very different in open source world. Open source is not just about publishing source code and getting software for “free”. Open source is also about innovative business models. And surprisingly, the business model also brings an obvious solution to the customization trap problem. A solution so simple and elegant that you won’t believe it really works. But it does.
All IDM deployments are different. But they are not radically different. Roles as a concept are always the same in all IDM solution. Just the details are different. The same principle applies to provisioning process, error handling, approval logic, policy rules … and almost any part of the solution. Therefore, let’s implement generic mechanisms in midPoint. And let deployment engineers to configure them to adjust for the details. So far so good. But this is no innovation yet. Every reasonable product works like this. The problem is, of course, when a product feature is missing. Maybe you cannot configure particular aspect of role behavior. Or user interface does not display particular page the way you want it. Traditional approach would be to create workarounds and/or use a lot of custom code. But that way leads directly to maintenance hell.
That’s where midPoint is different. MidPoint is open source project. If a product feature is missing then there is a way how to implement such feature. An obvious option is to implement it yourself. But midPoint is big and it takes a lot of experience to implement a new feature. And midPoint is a dynamic software which is continually evolving. Therefore it may be even harder to maintain such feature in the long run. And that’s where Evolveum business model comes in. Evolveum has a team of experienced professional developers. There is a way to “hire” those developers to work on the features you need – and to maintain those features for as long as you need them. This method is called platform subscription.
Platform subscription works like this: you let us know what features are needed for your project. We will estimate the effort to implement and maintain such features and we will give you a price quotation. The service is delivered in a form of an annual subscription that you will pay during the duration of your project. During that time we will make sure that the feature works for you – even if you change your mind slightly or even if you missed something in the original specification. We won’t charge you any extra. After your project is deployed and you do not need any new features any more you can switch to ordinary support program. And we will maintain your new features as part of that program.
But how does it solve the problem of customization trap? If the mountain won’t come to Muhammad, then Muhammad must go to the mountain. Therefore, the solution is simple. Avoid heavy customization. Make the product do the heavy lifting for you. Do not waste the time on workarounds and tons of custom code. Let the professional team of midPoint developers do it. Then take the improved midPoint and just configure it. It will work for your project now. And it will work in future midPoint versions – as long as you are covered by ordinary support agreement. Upgrades will be much easier. And the customization trap is gone.