Getting the Last Word In on Metadirectories

I doubt it. I doubt that there will be a last word on metadirectories for a long time to come. Technology that works has a way of sticking around, even when they have outlived their purpose, and are forced into the substrate of a new and improved “solution”. But I did want to respond to a couple of things that Matt Flynn brought up in his post “Metadirectories Aren’t Dead (They’re Just Aging)“.

First, he outlined a use case that he (I think) postulates is best solved by Metadirectory. I won’t recount the whole use case here (read his post to get it), but it involves three identity stores (HR, AD, and a DB) and synchronization between them of attributes that each one is authoritative for. My answer to his question “Is a virtual directory the best solution to meet these needs?” is “No, it isn’t, but Virtual Directory + Provisioning is”. Which is exactly what my post that he was replying to posited.

Now, I’m not trying to be glib here. Metadirectory can definitely solve this use case. But it will be a point solution. The “Aging” that Matt refers to comes into play when you consider that this use case will inevitably be added to with requirements for approval workflows, compliance and privacy controls and upgrade issues. Metadirectory (and Virtual Directory alone) would never be the right solution for those needs because (like Virtual Directory) it is simply an IT tool lacking the Business layer that Provisioning provides. So, the solution will require provisioning. In my experience, there is always a need to look forward to what is coming next before deciding on the solution, which is why in my (relatively medium-term) career, I have seen way too many customer requirements that try to bolt-on provisioning onto an existing metadirectory deployment because it was falling short. A number of times, the metadirectory was stripped down to a mere shell of itself as most of its functionality was moved into the provisioning solution.

I may be biased here (coming from a provisioning background), but nobody is simply looking for point solutions any more. And in any case, my hope is that eventually all of this will go away as we move to Service-Oriented Identity (as Burton calls the Identity Services concept).

Matt goes on to state:

There has been a ground swell of apps that directly support Active Directory as the user store. So, maybe the next versions of the HR and LOB apps in the above scenario would attach directly to AD eliminating the need for any solution here. As prevalent as AD has become, that seems more likely than mass-consumption of virtual directory technologies. And it’s probably what Jackson was alluding to (Quest enables *nix systems to leverage AD).

Well, from the standpoint of a deployer/implementer, I can certainly understand the attraction of the above. But as a product architect and technologist, all I can say is “No, No, No”. Why would we want to tie ourselves into a non-competitive, no-way-out scenario that we see repeated over and over in the OS and Mobile Provider worlds? Choice is necessary, nay vital, to innovation and growth. The minute you lock yourself into a single provider model, you are doomed to forever be curtailed by what that provider dictates. Virtual Directory provides a nice abstraction that frees you from having to make these very decisions on which directory to support (something LDAP was supposed to do, but didn’t).

And how are more applications supporting AD anyway? A lot of that has to do with the emergence of Virtual Directory solutions. A number of applications in the Oracle stable today claim to support AD as the identity store. The mechanism for all these is moving to Virtual Directory NOT because Oracle has a Virtual Directory product, but because maintaining adapters/connectors/plugins and what have you for all LDAP variants is a colossal nightmare.

Metadirectory is aging, but the IdM industry is a lot like the ruthless fashion world, where age has no place except for a few niche areas.