Every vendor offering you a cloud product touts their ability to provide agility to your IT organization. But, how do you place a value on agility in order to prioritize IT projects? There are a number of economic tools that come up frequently in describing value of software investments. I favor a simple economic approach: Net Present Value (NPV).
Net Present Value is the sum of value provided over time, discounted for the cost of money you’re investing in order to reap that value, e.g. interest. As an IT leader, you may not carry the cost of interest in your budget, but your Line of Business customers are likely affected by it and alignment makes for good partners. Let’s walk through an example.
Once upon a time, Red Hat acquired a company called Ansible. Right before the transaction closed, The Boss called and said, “Erich, I want you to make Ansible part of Red Hat. Don’t @#$% it up.” That’s when my real adventure with automation began.
Ok, the tech is nearly as amazing as the people, but how did it fit into our business? To really get this right, I spent a lot of time learning about the why’s of automation – what’s is really good for, and how it changes work.
Four goals of automation
Do more of the things
Do the things with greater consistency
Do the things cheaper
Less training to do the things
I suspect there might not be a lot of surprise in that list. Once it’s written down or said aloud, it seems pretty intuitive. What I’ve found interesting about, and unique to Ansible, is how much our design principle of “simple” makes all four better. Simple lets you get started faster on new things (less training), and takes less time and lets you do more things. Simple means fewer mistakes (consistency), and all of these together lead to less expensive operations.
But, what about how automation changes work? At the first pass, those four goals are big changes to work in of themselves. But, the biggest impact comes when things change.
Systems are Complex. Snippet of Apache Gora project represented by Chong and Lee (2015a)
Here’s an unpopular truth, if you work with systems of any size, you don’t know exactly how they work. If you’re diligent, you may have a great idea how they work. If you’ve worked with them long enough, you have a great intuition of how they work. You might know how to look up how a particular subsystem works, or who to call when another isn’t performing as desired. But you don’t, with precision, know.
That matters because it also means you don’t know all of the assumptions that lead your processes to work. Automation can break in at least three cases:
Inputs change
Conditions change
Things break
Consumption and use of a robust automation system, one which holds up in light of these expected changes, requires both the users and the technology to absorb these changes.
We can still do more things, but the volume of things can overwhelm when something breaks. Operator workload can become lumpy and unevenly distributed, especially at peak times, we introduce cognitive overload with new metrics, and other changes to the work itself.
The things we automate become more precise, but we see new types of errors emerge: system errors, unmet requirements/edge cases, more complex behaviors to manage.
Things are less expensive at the unit cost, pure replacement with automation is doesn’t happen, and is referred to as the “substitution myth.” Automation changes work.
Things are easier to do, and require less training. But, there’s an increased need for ongoing training, need to know the system as well as the components, with more emphasis on the system.
There are two approaches for creating more robust systems: handle as many edge cases as possible, which introduces more complexity to the system and makes it harder to fix the edge cases you missed; and simplicity. We chose simplicity.
We chose simple to help the teams understand the systems they’re using. When something breaks, they know where to look, and have a shared language to work with others impacted by the systems.
We chose simple to lower the expertise and effort to get started, creating more opportunity to automate little things in a learning, incremental approach to building hyper-scale automation systems.
I have an iPhone 6. It is not a happy phone. It is sad, angry, and generally disappointed to still be in commission and yearns to be put out on a ice flow. It generally expresses its displeasure by passive aggressively inventing remaining battery percentage, rebooting at whim, and pretending storage is full.
So, long preamble over, I was out for a jog this weekend. An embarrassingly rare occasion, and one I take to listen to podcasts. This run’s selection was the Dave and Gunnar Show with Bob St. Clair. And it was great! I was full of thoughtful humility, and smart dogged drive to be better at that ugly transition from individual contributor to leader of leaders. I’m a big fan of the show any way, and this was an exceptional episode. I’m glad I get to work with these three, even if we rarely cross paths. Thank you.
Needless to say, my phone crapped out just as I turned for the run back home.
Should you ever have to repair a 1950-something Crown Range, they’ve done something smart. I had to figure it out, but it’s smart.
Philips head screws are for holding things together (like sides the over doors), and slotted screws are for attaching things onto other things (like hinges). They provided a clear visual signal about what things did. Makes me feel like whomever came up with this idea would have enjoyed data visualization.
And yes, I now have two working over door handles.
A couple of years ago, Massimo Ferrari and I created the most extensive and thorough financial evaluation of OpenStack, which we called Elephant in the Room. We talked about it a lot, met a lot of customers doing amazing things, and received a lot of nice press coverage. Pulling together this type of research is a lot of work, and the hope was it would do more than help a few customers. The hope was it would help change the conversation we, as an industry, are having around cloud. That’s ambitious, I know, but I’m an optimist and was convinced we needed more understanding of financial implications of our technology choices.
Using some quick R¹ for statistical testing on the results of search phrase “cloud tco” on Google Trends, there is a sustained 42% increase in that search phrase following our blog post. I don’t know whether our blog post and talks around the world caused it, but the stats are significant (p << 0.01), and it sure is a heck of a coincidence.
Despite the guest, Dr. Iain McGilchrist, explicitly rejecting the metaphor that the brain is like a computer, I can’t help but think about the process of building and incorporating machine learning models.
Psychiatrist and author Iain McGilchrist talks about his book, The Master and His Emissary, with EconTalk host Russ Roberts. McGilchrist argues we have misunderstand the purpose and effect of the divided brain. The left side is focused, concrete, and confident while the right side is about integration of ourselves with the complexity of the world around us. McGilchrist uses this distinction to analyze the history of western civilization. This is a wide-ranging conversation that includes discussions of poetry, philosophy, and economics.
M.R.D. Foot tells a story of an underground agent forced to transport a B-2 wireless set (radio) through a railway station in which German forces were conducting random checks of luggage and personnel. The radio which the agent was carrying was a distinct size and shape and thus easily recognizable to alert police forces. The underground operative, realizing the precariousness of his situation, initiated a cunning security measure he presumed would reduce his risks.
He, reached a big terminus by train; carrying only his B2 in its little case; saw a boy of about twelve struggling with a big one; and said genially (in the local language) “Let’s change loads, shall we?” He took care to go through in front of the boy; there was no trouble. Round the first corner, they changed cases back. The boy said “It’s as well they didn’t stop you; mine’s full of revolvers.”
If you’re like me, with a wife nursing in the other room and an infant distracted by any noise or movement, then your mind naturally drifts to the topic of entropy[1]. I saw something on “TV”[2] about music, and began wondering about whether different musical styles had different entropy.
Slashing around with a little Perl code, I hoped to look across my music collection and see what there was to see. Sadly, I don’t have the decoding libraries necessary[3], so instead I just looked at the mp3’s themselves. While most genres did show a good range, they are also relatively distinct, and definitely distinct at the extremes.
While I can’t make any conclusions about how efficient mp3 compression is by genre, we can safely say that the further compressibility of the mp3 file is affected by the genre. I.e., there is room for genre specific compression algorithms. Which only makes sense, right? If you know more about the structure, you should be able to make better choices.
Entropy is the measure of disorder in a closed system, with the scale ranging from completely random to completely static. It is used as a model in information science for a number of things, including compression: entropy can be used as a measure of how much information is provided by the message, rather than the structure of the message.For example, the patterns of letters in words in the English language follow rules. U follows q, i before e…, etc. The structure defined by these imprecise rules, in English, dictates about half of the letters in any given word. Ths s wh y cn rd wrds wth mssng vwls.The thinking is, should you agree to what the rules are, you can communicate with just the symbols that convey additional meaning. Compression looks to take advantage of this by eliminating as much of the structure as possible, and keeping just the additional information provided.
Mathematically, the entropy is often referred to by the amount of information per symbol averaged across structural and informational symbols. English has an entropy around 0.5, so each letter conveys 1/2 a letter of information, the other 1/2 is structure[4]. ↩
Rodney Brooks, co-founder of iRobot and winner of the individual award for IT Hardware, made the joke that it was nice to have a hardware category, because we software guys never give hardware credit. I can think of a few jokes in the other direction, but he does have a point: none of us will be successful without each other. That’s why the evening was so much fun…
The room was full of customers and even some partners getting recognition for their work. These are the folks who have made us successful. I can’t wait to see what’s next!
This award was also personally rewarding, as I had to leave my very jet-lagged wife at home with our very jet-lagged and cranky 4-month-old, after a week away with my mother. So, it’s probably good for me that we won.
I know you’re dying, so here’s a goofy photo of me in my tuxedo…
