This blog in part 2 of my previous blog “Top 10 Laws of a Virtual Direcctory (Part I)“. I will now cover Laws 6-10:
Law VI: A Virtual Directory MUST NOT have a large footprint: Optimal IdM’s Virtual Identity Server, for example, takes up less than 5 MB of disk space. If you add in the Compliance Management system and the SharePoint integration, it climbs to only 25 MB. The bottom line here is that VIS uses a single XML file for its configuration information, and relies on NO registry information to function (just a simple Windows service). For requirements, the 2.0 Framework (or higher), is all you need to go. Be careful of other solutions that require ugly JVM’s, and/or complicated configuration elements.
Law VII: A Virtual Directory MUST NOT be difficult to support: Optimal IdM’s Virtual Identity Server, runs on both Windows Server 2003 and Server 2008 in a single code-base. For this reason, VIS is easy to support. No worries of platform supportability here, in fact, VIS is officially certified on both Server 2003 and 2008 (including 64-bit).
Law VIII: A Virtual Directory MUST be a VALUE ADD: Since Virtual Directories are in essence LDAP Servers, there is an opportunity to make your LDAP experience “better”. LDAP V3 has been around since 1997 (that’s a lifetime it technology years). A Virtual Directory can provide features that should be built-into LDAP (perhaps standard one day in V4). We like to refer to VIS as “LDAP++”, because it improves the users experience around LDAP. (Watch for a future blog on LDAP++, or “LDAP on steroids”).
Law IX: A Virtual Directory MUST NOT introduce too many proprietary elements: A Virtual Directory should not introduce ANYTHING proprietary to your environment. That includes proprietary data stores, caching, ports, etc. Optimal IdM’s Virtual Identity Server, is complete WITHOUT any proprietary elements. Be careful of systems that include complex proprietary elements. (Complex & Proprietary = additional administration costs).
Law X: A Virtual Directory MUST NOT require custom coding: One of the most comment features of a Virtual Directory is handling joins and merges of data. If it’s so common, why do vendors require you to write custom code to handle it? How about caching? Same problem, some vendors requires custom development just to handle basic elements of virtualization. Optimal IdM’s Virtual Identity Server, is point-n-click for 99% of all features (with NO coding). However, extensibility is available and in a common in-expensive langue (.NET). Be careful of customization costs/efforts of other vendors and the language they require development in. All this time, I thought Python was a snake…. How many people actually know what “Python” is anyway?