No, I’m not referring to how quick you can pull a table cloth - something my mother insisted I stop trying, and failing miserably at, at a young age. In technology circles, human latency refers to the delays incurred when waiting for people to complete a task. I don’t believe (I hope not) that the term was coined to suggest that certain employees are slow to meet expectations, but more to do with the fact that people have finite bandwidth and, therefore, when the workload exceeds what they can deliver businesses will experience delays. This is ‘human latency’. Putting something in a request queue (the business) waiting for something to be done (human latency).
Human latency can be the result of many things:
Workload exceeding the capabilities of a delivery team.
Procedural delays (policy) caused by anything form budget constraint, key decision makers being unavailable, possibly even interdepartmental disputes over prioritization.
Knowledge limitations of engineers working beyond their comfort zone.
Why are we suddenly so interested?
In more recent times, the speed of business has increased significantly. Far, have IT departments progressed, from the days of sitting around in sun-loungers (I jest), to todays more competitive, information-consumer driven priorities. Driven largely by competition and the ‘immediate gratification’ generation, expectations on the delivery of ‘everything now’ have never been so prevalent.
What effect will this have?
Have you seen Terminator 3: Rise of the Machines? In case you haven’t, it’s the one about the robots deciding to eradicate the human race from planet earth. Turns out the robots realized that we, their creators, were the weakness in evolution. I’m hoping that said movie has socialized the importance that we (humans) stop before anything gets quite so bad <CR><LF>. However, back to the title of this section, it’s the human latency problem that is driving technology integration and intelligent orchestration.
Not this integration (man inserts RFID chip into hand), and not this (musicy thingy) kind of orchestration. Five years ago (that’s 2009, to the future alien race), I was talking with a customer who told me of a most excellent policy within their team. “NEVER do something more than 3 times without committing effort towards the automation of that task.” Unfortunately, my suggestions toward building a shrine in honor of this customer were laughed off, but can you deny the genius behind this policy? In their environment, one was ‘busy’ and unavailable for other assignments should they be reviewing a historical task for the purpose of never performing it again. BRILLIANT!!!
What can we learn?
For a long time, cloud computing was heralded as the solution to IT’s bottleneck. “Move workloads to the cloud so that IT can focus on strategic projects”, they yelled from the rooftops (via twitter). Cloud-based technology didn’t solve problems, it merely moved them elsewhere, or created new ones. With IaaS we have the same service delivery problems as private data centers, just on someone else’s hypervisor, and with a utility licensing model. With SaaS, its great that someone else is handling feature requests and execution, but with SaaS also came access problems: increased password fatigue and a reduced security integrity. And no, I didn’t forget PaaS. PaaS just brought confusion as it primarily solved problems for coders and, while I think PaaS is AWESOME, there’s still an education phase for this one.
A new hope (coincidentally, Star Wars, Episode IV)
While pushing better business, the efficiency (automation/orchestration) drive is definitely creating headaches – how many different/conflicting SDN pitches did you hear in 2014? New terms like SDN create for new stories, but lets keep the focus on reducing human latency. The best people I’ve ever worked with are those who have focused, primarily, on removing themselves from policy validation (safely) to ensure rapid execution.