Analogical Reasoning and DevOps

A couple of weeks ago CIO.com writer Clint Boulton posted an article titled “CIOs aren’t ready for Docker and Container technology“, where he discusses that CIOs are slow to adopt containers and DevOps. It is a pretty good read, providing more substance than other pieces covering emerging technology. In fact, it was largely supported with data derived live from 80 CIOs that were in attendance at a Wall Street Journal event. As an empirical data guy this is a good thing. But I kept finding myself taking issue with the “CIOs aren’t ready” part of the title. At Nebulaworks we are working on DevOps enablement projects daily and containers are a key piece of the puzzle to drive pipeline productivity. So why are CIOs slow to embrace the technology and adopt DevOps?

I went back and reread the article and put myself in the place of a CIO who was sitting in the audience listening to the various speakers, including Docker CEO, Ben Golub. Hearing Ben’s high-level comments, the initial value proposition; i.e., use cases, would be pretty easy to understand for the technical leaders of organizations. But apparently that wasn’t the case. Why? While many explain slow adoption as a function of risk, while others using reasons like regulatory compliance, these and other justifications are the result of:

Analogy.

It is human nature to draw analogies, often with things we know well in attempt to analyze something new and assign value. In fact, in “Analogy and Analogical Reasoning” by Paul Bartha, he asserts this is fundamental to human thought and problem solving. But it isn’t always without error. Depending on how you interpret the information you are receiving, invalid conclusions may be drawn. And for us in the field of technology this can create anti-patterns in the process. Take for instance, containers (the subject of the CIO.com article) and virtual machines. They really shouldn’t be compared…they were created for different reasons and exhibit quite different characteristics. If someone is explaining something and you draw conclusions with superficial similarities your reasoning may be incorrect, skewing judgement. Evaluation of new pipelines, organizational alignment, and toolchains against current processes and existing tools which were optimized for a different goal, potentially from long ago? Just because they both employ tools and refer to IT and/or development does’t mean they exhibit the same qualities. Maybe this happens when DevOps is discussed at a high-level. Let’s face it, we are all guilty of this behavior, but there is a better way.

In order to effectively harness the power of new technology and methodologies and apply them in a fashion which is beneficial, especially to something as complex as IT, development, and business alignment, we require more than a cursory understanding. Certainly more than a feature/benefit discussion. Also, this is a process that takes time: Diligent research, thought-provoking discussion, and hands-on learning. Today, more than ever, time is precious; time is money. How then, do you reconcile the unknown against your objectives without wasting either of these while maximizing your return, and avoiding incorrect inference? Based on our work, here are three suggestions:

  1. Attend a meetup or user group meeting. There are many of these held across the globe, ranging from technology to business.  Those I have attended, rarely, if ever have anyone with a C-level title. Why? They are non-threating, void of sales teams and support continued education in a format with zero pressure. These aren’t just for the technical, hands-on people. You may learn how others are trying to solve problems that could be the very same ones your organization is facing, bringing real-world suggestions back and socializing with your team.
  2. Find a subject matter expert that is unbiased, technically well versed, and from outside your organization. Fact:  Software vendors and purveyors of fine IT technology (cough, hardware) believe in the geocentric model where they are at the center of the Universe. We all know there is no technology or method employed today that is done in complete isolation, so, why continue to trust anyone not seeing the bigger picture. Additionally, your “Brent”, the technical expert in The Phoenix Project, (Behr, Spafford, Kim) is likely someone who sees the world through your organization’s eyes, but not so much as an external contributor. To break the analogy barrier you’ll need fresh insight.
  3. Work with an organization that understands the benefits of agile. Not only how this applies to software development, but to operations as well. Taking it one step further, this partner should apply iteration and sprints to the way that they engage – from training to project engagement – offering a different approach to the traditional consulting model. By providing constant feedback, information flowing freely and openly enables collaboration and communication…the basis for education and learning.

Thanks for taking the time to read this article. I’m always thinking about better ways to work with our clients, and would appreciate feedback on the deep reasons why technology and methods are slow to be adopted. Feel free to comment here, reach out to me with a private message, or give me a call…it shouldn’t be too hard to find my number.