Fail Tales #1 – The Highlander Constraint – Designing for 65% Availability

In this installment of Fail Tales, we’ll take a look at the business, user experience and  technology design implications of the Highlander Constraint and a few fundamental mitigation tactics.

For those unfamiliar with the Highlander tale of film and television, the worlds fortune rests on one person who, by virtue of competitive mortal combat, wins The Prize of ultimate knowledge and power. The thing about depending on the Highlander is that “there can be only one”. When the Highlander is “unavailable”, you are out of luck.

The Highlander Constraint is not new and it appears in a broad variety of solutions, however for those developing social media experiences it can be particularly vexing and easily ignored because it is counterintuitive to consider the situation where social media does not exist, when designing a social media experience.

Ordinarily, a client requirement stating that a given application be functionally available to end users for say 99% of the time is addressed with tried and true engineering approaches such as n+1 or 1+1 architectures –  no single point of failure: two data centers, multiple network backbones into your data centers, 2 power supplies in each computer, 2 NICs, belt and suspenders, etc. Furthermore, critical services are contracted with SLA’s (Service Level Agreements). With all this risk mitigation in place, the probability that the system will be unavailable is so low, the UX solution can be reduced to something as simple as telling the user “Please Try Again Later”.

In the social media space the usual interplay of UX and Technology is disrupted because social media platforms and their APIs, such as Facebook, are Highlanders and Highlanders don’t sign SLA’s. To make matters worse, every Highlander you bring to the party increases the odds of your experience being unavailable.

Consider a solution that requires that the simultaneous functional availability of four different APIs. If each of these has an guesstimated functional availability (remember you don’t have an SLA, and Highlanders don’t brag about their fails) of 90%. The availability of your solution would be calculated by multiplying 0.9 x 0.9 x 0.9 x 0.9 = 0.6561 or 65%.

This is not to say Highlanders are lazy or uncaring. It’s hard to suddenly find yourself to be a lynchpin in the social fabric of the world. So in the process of becoming a more dependable Highlander, you may find yourself – suddenly and without notice – unable to contact the Highlander (API changes) or that the Highlander no longer makes appearances at charity events (Terms of Service changes).

The Highlander Constraint can be tamed with a few fundamental business, user experience and technology design tactics.

These include:

  • Client Education – make sure your clients understand the constraint and make sure they are not doing anything that is mission critical with a Highlander just because it seems like a cool idea.
  • Get to know your Highlander – build relationships with your Highlanders and share the hopes and dreams that you and your clients have. As we know, they are constantly evolving; perhaps you can take part in that process.
  • Be Self Sufficient – Design experiences that stand on their own, but are enhanced by a Highlander. A martial arts practitioner will have a better chance of survival than the town drunk, if the Highlander is unavailable.
  • Trust but verify your Highlander – once you have a Highlander on the job, you need an active monitoring and remediation strategy so you can cope when the inevitable happens.
  • Don’t depend on multiple Highlanders to show up at the same time, all the time – design solutions so each Highlander can add value IF they show up independently.

 

Join us for next time for Fail Tales #2 – Catastrophe Assurance – Embracing Interactive Complexity

 

highlander2