The Complexity Funnel

Today, I was contemplating to myself all of the times I have folks attempt to justify to me why they do not want to follow a best practice.  I thought about the implications for quite a long time and I side with following them, for the record.  This is not a matter of conforming for the sake of appeasing a vendor or making a positive impression on an executive.  Following best practices is about implementing a well supported deployment.  This holds true for any discipline that I can imagine.  While attempting to come up with a means to illustrate the point, I kept thinking of sales funnels: these charts about targeting customers and how much work that you have to put in to the top of the funnel to trickle down into the desired results that come out of the bottom.

The idea of the Complexity Funnel is simple: the more complexity you pour into the funnel, the more difficult it is to find success as an output at the bottom of the funnel.

Now, I truly believe the Complexity Funnel to be agnostic to industry, but I can readily relate it to technology, and specifically to Office 365 and Azure Active Directory.

There are a set of various best practices surrounding implementations of Azure Active Directory.  The various best practices revolve around the identity model that you plan to implement: Cloud-Only, Managed (AKA: Synchronized), or Federated.  Each model has its own set of established best practices, so this is why there is such a variation.  However, one that sticks out in my mind is related to Federated identities.

Federated identities allow an organization to establish single sign-on in their environment with the most complete set of features.  Microsoft has their own solution for this approach and would be deemed the best practice; along with this implementation are various other practices that are advised to establish high availability, which is rather important because having the federation infrastructure unavailable means that nobody authenticates to Azure Active Directory.  Now, there are 3rd party federation solutions that exist, like Ping Federate, OneLogin, Okta, and Oracle Identity Federation.  You may have good reasons to implement one of these solutions.  However, based on feedback from Office 365 for IT Pros, only 3% (6.5% according to Microsoft in later referenced Microsoft Ignite session) of all Office 365 deployments utilize any 3rd identity federation solution. UPDATE: Ping Federate is the next largest Identity Provider (IdP) behind ADFS and supports 1.6MM users, just for a reference point (September, 2016 – Microsoft Ignite: Discover What’s New in Active Directory Federation and Domain Services in Windows Server 2016)

So, as much as you might find compelling reasons to implement one of these solutions, consider the magnitude of this decision: a key service infrastructure that you will be implementing can have dire impacts to service availability for Office 365 or anything else that you integrate with Azure Active Directory.  The totality of all 3rd party solutions implemented amounts to 3% of all deployments.

So, let us say that you implement one of these solutions.  Things go great, of course, until they don’t.  What happens now?  Obviously, there is a strong possibility that you have a support contract, but that doesn’t guarantee timely resolution to your issue (even if the terms of the support agreement state otherwise).  So, this is where the Complexity Funnel comes into play.

At the top of the funnel is all implementations of Azure Active Directory.  For the sake of this discussion, let us assume that of all implementations of Azure Active Directory, the total percentage that operate with Federated identities is roughly 50% (I think this rough estimate isn’t far off, but new implementations are mostly going with Managed identities).  So, for all customers of Azure Active Directory, you align with roughly half of them when considering which identity model you have implemented.  Next, compare your solution (any given 3rd solution for Federated identities), to that… you are down to 3% of the total, or 6% of Federated identities.  From there, you would break things down to your specific solution choice, which would be something smaller.

Just to simplify things, let’s say that your chosen solution amounts to 1% of all Azure Active Directory deployments.  Now, we must consider the percentage of deployments that run into issues.  How many deployments that implement your chosen solution have outage producing events?  Let us be conservative and say 50%.  So, half of 1% of all deployements have experienced downtime with the solution that you have implemented.  There could be various reasons for the event, maybe they amount 4 different circumstances that account for 80% of said events, and you experience one of these 4 issues.  So, 0.1% of all implementations have experience an issue arising from broadly similar circumstances as your own.

Now, out of all of the times that you have experienced events like this in your career, how many times have you detailed the events, the circumstances, and the resolution?  If you happen to document the situation, how many times do you publish it to the Internet for others to see?  I would wager that each of these statements starts chopping away at the percentage.  I would say that it would be rather generous to assume 1% of events produce publicly released documentation… so, in total, the published results account for 0.001% of deployments.

Now you have to have some level of comfort for these results if you happen to find them.  This assumes that a search engine or other tool has led you to a URL and that when you click on that URL the page still exists.

As we add various considerations, the chances of finding reliable and actionable documentation that can lead to resolution of your issue diminish further, approaching zero.  Don’t forget, we have only added a single deviation from best practice to the scenario.  I am sure that each of these 3rd party solution vendors have their own published best practices.  How many of those did you rationalize away as being unimportant?  Now, considering risk and failure domains… these things aren’t added together, they are multiplied against each other.

Now, you may very best have a valid reason to deviate from a best practice.  However, I beg of you to take it under consideration that it may not be worthwhile.  Your understanding of the perceived benefits may be askew or your choice may be emotionally charged.  If you deviate, do your best to limit deviations to the most minor and least impactful.  Don’t create a situation that increases your own risk or long-term risk to your team.  Further, if you are a leader on your team, do leave a legacy that promotes such things.  We have all witnessed situations where years after a decision has been made and the solution implemented that we hear people complaining about the wake of problems experienced since.  You know this happens… and the lead up to these decisions has likely been the result, at least in part, by the rationalization of deviating from some best practice.

However, don’t let me discourage deviations that are made in the short term meant to bring about a better long term vision.  I have witnessed situations that are truly unnerving and the folks left holding the bag are in a pinch.  They don’t have any solution that aligns with best practices based on their situation.  So, they have to implement something in the short term that delivers them to a better solution which has an outcome that is ultimately rooted in best practices.

Your mission should be to simplify and avoid unnecessary complexity.  Any necessary complexity is more than enough to deal with.