Top 10 Laws of a Virtual Directory (Part II)

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?

Advertisements

3 Responses to “Top 10 Laws of a Virtual Directory (Part II)”

  1. Fernando Garcia Says:

    This is a great post, Larry, you have touched on some very important points
    that will prove valuable to IT professionals who are considering using
    Virtual Directory software within their infrastructure.

  2. Matt Pollicove Says:

    Larry,

    Interesting post. I’ve been saying the same basic things for years. I can’t say that I agree with you on custom coding though. While not a fan, it is sometimes needed when you need to include attributes from other authoritative sources that you do not have access to. So there might always be some custom connectors that need to be custom coded.

    Here’s some of my blog links to my thoughts on the Virtual Directory space, most of which go back to my MaXware days (So yes, I do have a bias)

    http://idm-thoughtplace.blogspot.com/2006/07/virtual-directory-models.html#links

    http://idm-thoughtplace.blogspot.com/2009/02/when-is-virtual-directory-not-virtual.html#links

    Cheers,
    Matt

    • virtualdirectory Says:

      Thanks for the feedback Matt. My point with the custom coding should be the 80/20 rule, where customizations should be limited to special (odd) needs. Some of our competitors, require custom development to do very basic things that ‘should’ be out-of-the-box. If a given product requires custom coding in all of their deployments, then that should be a warning sign. Keep in touch!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: