Proliferation of Multiple LDAPs

I was questioned today by someone who read my post on Synchronization versus Virtualization, which is topical given the recent blog debates by many of the big names in identity blogging on whether metadirectories are dead. Back then, I was trying to convince the world that there are cases that require a virtual approach. Now, the tables seem to have turned. I've stayed quiet on that debate, but I believe there's still a place for each method. Honestly, I'm not sure why there's such intensity behind that debate – they're just tools. My idea for Enterprise Identity Services Architecture included a layer for Identity Data Services, which is analogous to the proposed Identity Hub or Bus. It has a box for both synchronization and virtualization because there are use cases for both types of technologies often within the same infrastructure.

End of digression.

The question proposed was about how large enterprises (hundreds of thousands of users) are addressing the proliferation of LDAP directories in their environments. The person asking comes from a well-known and reputable company. The first thing I thought is here's the exact reason why we still need metadirectories. Many companies still haven't dealt with the user-store sprawl. In a general sense, I think metadirectory technologies can help get you to a place where you refine and consolidate your infrastructure and can then leverage virtual directory technologies where appropriate for applications that need access to data in multiple stores and/or multiple formats.

What the questioner was really looking for is research that discusses how other companies have handled the challenge. Here's my answer:

My recommendation is to find an experienced group of consultants who have tried various approaches with different clients. There are a number of them out there and I'm happy to give recommendations privately based on geography, technology, comfort-level with small vs. large companies, etc.. Whether you engage them contractually or enter into discussions via user groups, trade shows, etc., real world experience is priceless. Anybody that pushes one particular approach to this problem is probably biased (either by product or by their own limited experience). My experience suggests that most scenarios require a unique approach based on business goals, actual technologies, future plans, etc.. But you probably need someone to spend some time understanding your own scenario before recommending an approach.

Some questions you'll want to explore:

• Which data stores have overlapping data and which are unique?
• Does it make sense to consolidate?
• Is the data mappable across systems? Do they share unique identifiers?
• Where can multiple applications share a single store?
• Where do given applications require access to data in multiple stores?
• What applications or uses are coming in the future?
• Which stores are used for critical apps? What is the up time demand?
• In what format is the data stored?

The answers to these questions will drive your architectural decisions and help you prioritize next steps.

If you'd like to comment and provide a pointer to field research, whitepapers, or contact info for how you can help with this situation, feel free.