Follow up post to - "A Virtual Directory is not just for "legacy" applications"

I have a short follow up post to my post titled: "A Virtual Directory is not just for 'legacy' applications".

I am sure some folks will read that post and still think that virtual directories are still only about LDAP applications.  On top of that they will probably say to themselves that Federation will solve these problems of abstracting the application from the directory.

To the latter point, yes Federation does provide a level of abstraction, but there are many other factors to consider.   The Federation server (what ever it is) still needs to authenticate the user somewhere.  In the case of Microsoft's AD FS server, it can only authenticate to Active Directory. 

If you utilize Optimal IdM's Virtual Identity Server for Federation Services, however, you can now have an AD FS infrastructure that can authenticate users ANYWHERE.  Our Federation component is an Identity Provider (IP) that leverages our Virtual Identity Server (VIS) virtual directory to authenticate users in whatever data store they reside.   It doesn't matter if they are in another directory such as Sun or eDirectory or even in databases. 

Have multiple Active Directory forests?  Yep, leveraging our solution we make that a snap too.  No need for a ton of AD FS servers, trusts, etc.  Think about it this way. With a virtual directory any application whether it is SharePoint, CRM, or ADFS no longer needs to worry about multi-forest or where users are stored for that matter.  That is a compelling statement when you think about it.

Also, a virtual directory makes it very easy to source identity data (Claims in the Microsoft world) from ANY data source.  AD FS can only source claims from AD or SQL. By plugging our solution in with ADFS, ADFS no longer needs to worry about getting the data from disparate data sources.  The same thing rings true for a host of other applications. 

A Virtual Directory is not just for "legacy" applications

Recently I was talking to someone who is working on "future technologies".  In this conversation, I got the perception that they believe that virtual directories are used only for "legacy" applications. Now keep in mind what "legacy apps" means to folks building infrastructures for the "future".  To them, a legacy app is an application that is currently running in the enterprise right now, not ancient applications from years ago.

In my opinion, trying to pigeon hole a virtual directory as being legacy is flat out wrong.  Sure companies use a virtual directory to solve some very classic problems that applications struggle with (such as multi-forest), but that is only part of the reason they deploy.  It isn't just about their currently deployed applications, but about their future applications too. 

For example, we have some of the largest Fortune 500 companies in the world that are architecting
our virtual directory as a key component in the architecture they are building for the future.  They see the virtual directory as vital element that is absolutely necessary to meet their objectives both known and unknown. It is the unknown that kills you in the future.

Think about this for a moment.   When Microsoft first deployed Active Directory they told everyone to have an empty root forest, right?  Ooops!  Later they changed their minds and said nope you don't need that.  How many enterprises still have that "old" architecture?  How many have multiple forests?  Why? 

The answer is simple.  It is very hard to change.   Without a virtual directory, applications are tightly coupled to the data store.  This, of course, is a bad thing in any IT architecture.  We don't let application developers code directly to the database tables do we? No.  We give them a stored procedure or view.  With a buffer or "black box" that the applications use, we can now change out infrastructure without impacting the applications.  

Our enterprise customers see this and use the virtual directory as their buffer layer or black box.  This lets them architect for the future, now.  They are using this virtual layer to provide this buffer for both on-premise and cloud.    Also, we at Optimal IdM don't stop at just the LDAP support either.  For example, with our integration with Microsoft's Graph API we can translate LDAP calls into RESTful web service calls.  

Nobody can predict the future.  However, when it comes to computer architectures, I do know that we will need to make changes in the future.  A virtual directory enables organizations to make changes easier and without impacting applications.  The cost savings are enormous and very quantifiable. 

So while our customers are deploying the virtual directory on a enterprise scale into the present environment, the key point is that they are doing this to enable flexibility in the future environment too.

That is a key concept that is lost on this person...

Cloud Adoption - The 80/20 rule...

Over the years I have worked for several small companies. These companies were in the 100-150 person range.  Back then (late 90's/early 2000's) the "cloud" wasn't really there with the exception of Salesforce.com. These companies that I worked for all had an on-premise Active Directory with some sort of email system such as Exchange and collaboration portals to share documents, etc.  Each of them typically employed 2 to 3 full time IT folks to keep it all moving. 

In today's world, a 100 person company can easily find ALL of their services in the cloud, without requiring any on-premise infrastructure or servers.  This is the "low hanging fruit" for Microsoft.  The companies are small and can easily log in to a cloud portal application, create their users and passwords and get to the cloud. These are the easy ones. 

Now lets move on up the chain to the medium and large enterprises.  These companies likely have an on-premise environment (i.e. Active Directory) and as the organization grows in size, its complexity grows.  They will have more and more user repositories, multiple platforms, etc.  Moving these organizations to the cloud is more complicated and difficult.  

Here is the rub and the 80/20

While you may be able to grab "80%" of the companies in the world under the non-complicated low hanging fruit scenario, this only represents "20%" of the total user population.  While there are fewer of the medium to large customers, they have more users and thus a greater total population. That wouldn't matter if cloud services were sold on a flat server/company fee, but most cloud offerings sell per user/per month. 

Here is some quick math shown in the spreadsheet below.   In the example, I averaged the "small" company at 100 users.  That would be a mix of some companies that have 5 or 20 people and some with 200 or 300.  As you can see for Microsoft's middle of the road Office 365 plan that would equate to $168 million dollars in annual revenue in my scenario of getting 10,000 of these companies.

Now let's look at my second example.  In this scenario, I assume that only 2,000 companies sign up for the cloud offering.  However, these 2,000 companies have on average 30,000 users (some higher/some lower).   In this scenario, using the same middle of the road Office 365 plan would result in annual revenue of 10 billion dollars...

Which would you rather have?  80% of the small companies or 20% of the large companies?  Obviously these aren't hard and fast numbers, but the 80/20 model is the base premise here.

Now it is probably pretty easy to see why my company Optimal IdM, developed our Virtual Identity Server for Office 365 solution.  This solution eliminates many of the most common deployment barriers for Office 365.  In a nutshell, we make complex environments easier to manage and cloud adoption a snap!   We charge a percentage of what Microsoft charges for Office 365 but as you can see with each new customer (they are typically large) that represents substantial recurring revenue.

It is sort of like target markets in general.  You would far rather have a product that has a target market with anyone in the world, then to have a product geared towards a specific age/gender/ etc.  In terms of cloud, I would far rather have a smaller number of customers that represent the bulk of the user base.

By not supporting multiple AD forests in Office 365 or other data stores for that matter, Microsoft went after the low hanging fruit.  The easy, non-complicated customers.   That's where partners come into play such as us.  We fill the gap and make adopting Office 365 fast and easy. We can take a customer to the cloud in a matter of days regardless of the number of data repositories they have and without changing or touching their existing infrastructure.  It is the easy and no risk way to go to Office 365.