DevOps Driven Demand

This is a guest post from John Willis (@botchagalupe)

What if DevOps created more defects, tickets, requests, and more overall work? Would that be a good thing or bad. Let’s take a look.

Information Technology Asymmetry

Let’s face it, IT has historically had an asymmetric relationship between it’s suppliers and consumers. In fact one of the core tenants of the “DevOps” problem statement is the relationship between developers and operations. DevOps is only about three years old but the concepts have been around a lot longer. This is nothing new, historically developers want rapid change and operations wants stability and slow change.

I once spent six months in a cubical adjacent to the change manager for one of the largest US based insurance companies. I wish I had a copy of my tweets about the hijinks she had to deal with from people trying to game their change management system. You enterprise guys know what I am talking about. Think of all the wasted time in IT that goes into trying to game the system due to lack of information and access to resources.

Another true story, I once spent a year at the Federal Reserve doing Tivoli consulting. On my first project I needed to get an Oracle instance for a Tivoli database. I created a change request. A year later I left the Fed with two things 1) a new Oracle instance I didn’t need anymore and 2) My wife.

Latent Demand

A situation where demand cannot be met: a business environment in which demand for a particular product cannot be met by existing suppliers or is temporarily suppressed.

Unfulfilled latent demand is root of all evil in IT. In my Oracle instance example I never again asked IT for resources (“Why Fight City Hall”). I was a consultant and I had to get things done on time. I had to steal database space from an already existing Oracle instance and it never fulfilled the true requirements of the project. I wasn’t the only one on the project that behaved this way. In the end this particular project ultimately failed at the Federal Reserve. There were other reasons for the failure… but what if we would have had a new Oracle Instance? or received that SAN based file system? or … the list goes on. Maybe Tivoli would have run better. Maybe customers of Tivoli would have seen it’s true potential. Maybe if…

Another great IT story is a customer of mine that is a large New England based bank. The last time I checked they were still waiting (18 months) for an approved new server. Of course they created their own “servers” during that 18 month period – it just didn’t happen to be that one they originally purchased for $30K. In fact, this is a common meme in the early cloud success stories – “I can go to purchasing and have them beat me up for 3 months or I pull out my credit card and just get it done.” However, this is still the exception rather than the rule. Most consumers of IT wind up waving the white flag and just don’t ask.

Supplier Induced Demand

The idea of supplier induced demand encourages consumers to demand a greater quantity of goods or service. What if IT could create an environment where consumers of IT were informed and felt empowered? What if IT gave them the freedom to get things done? What if freedom and a getting-things-done attitude became habit forming? Imagine if change requests were auto approved due to repeatable automation. What if, in the 18 month server example mentioned above, automated provisioning and configuration management were used to build that system in minutes? Imagine if the 10 or 15 people involved in the process of verifying that server had stored their process in a configuration database. Then automation could be used to deliver the best of both worlds. The consumer gets the server faster and the supplier has a secure and repeatable process. The business might create a lot more servers, a lot more services, and a lot more happy consumers.

One of the core principles of “DevOps” is about changing cultural habits to induce productivity. In DevOps we talk about breaking down the “Wall of Confusion” between developers and operations in order to become more agile as a whole. Most DevOps discussions focus on models of automation around provisioning, configuration management, continuous integration, monitoring and continuous delivery to enable that business agility.

What if Devops?

So let’s get back to my original question. What if DevOps created more demand, would that make things better? Let’s take one last detour before we answer that question. A few years ago Eli Lilly did a Webex on how they used Amazon’s cloud. One of my best take aways from that Webex was how they described the cultural habits that were changed by using Amazon’s cloud. One of the quotes in the Webex was – “Amazon has redefined the concept of time here at Lilly”. What the presenter meant was that it was great that they significantly decreased provisioning time; however, what was even more important was they had significantly changed a cultural behavior pattern. Prior to the “cloud” their researchers would have to either fudge or ignore short computations that were needed. Why? Because if they had to wait 8 weeks to get the server(s) or, even worse, ask purchasing for 100 physical servers for 2 hours, they would opt for the fudge method. In their cloud world the “new” definition of time was that they could ask for 100 servers for two hours to calculate the number they needed for a much larger computation. The end result was that Eli Lilly asked for and received a lot more servers than they did before the cloud. The question I like to ask IT organizations is – “Who are your most important consumers and have you identified their latent demand?”.

So back to the original question, “What if Devops created more defects, tickets, requests and more overall work?”. What if the support group actually fixed bugs faster? Consumers might actually start reporting more bugs. The product might improve and demand might increase. The end result could be that you make more money. What if you have created a self service environment for service requests. More service would be created and hopefully the consumption of those resources will create increasingly positive business results. Therefore, my answer to this question is yes, Devops will create more work. However, if the correct automation is applied the “more” work will actually cost you less, create more demand, and make your company more $money$.

About the author

John currently works at DTO Solutions, Inc. located in San Mateo, CA. With over 30 years of experience in ESM/IT Management, he is the author of numerous Tivoli books.