Today author, DevOps evangelist and DevOps.com Advisory Board member Gene Kim published an article in the CIO Journal of the Wall Street Journal. The article was a response to an earlier article by Rachel Shannon-Solomon in which the author claimed that DevOps was not likely to be successful in the enterprise at least not at the present time. Rajat Bhargava, CEO of JumpCloud and another Advisory Board member of DevOps.com wrote the below in support of and amplifying Gene Kim’s thoughts in the WSJ article.
Recently an article was published in the WSJ CIO Journal that DevOps likely won’t work for enterprises – at least not now. The author goes on to state that there are structural impediments to enterprises adopting DevOps including siloed organizations, lack of platform technology, cultural issues, and lack of ROI. I completely agree with the author that enterprises face an uphill battle on the implementation of DevOps. She is right that they have different structural challenges than startups or SMBs.
DevOps bring companies close to customers
However, I have to flat out disagree with her conclusions and many of her data points that are extrapolated into the conclusion that DevOps won’t work in the enterprise. Let’s start at the beginning where the author states that DevOps is “…a software development method that stresses communication and collaboration between developers and IT professionals (QA and ops)”. I’m going to respectfully disagree with that definition. DevOps as a name is a misnomer. DevOps is about collaboration and communication, but not just between developers and ops in the enterprise. This is about communicating across the whole company: sales, marketing, finance, security, and any other relevant area. DevOps is about increasing company performance through better IT execution. The hypothesis is that by more closely aligning what cus with what gets built in a more timely fashion, organizations will sell more products and services. That’s not a small company or SMB issue, that’s an every company issue.
The author continues by saying “…the value of implementing devops beginning in the early days is clear—achieving radically higher productivity at lower costs resulting in more reliable systems.” I have to disagree here as well. DevOps is not about higher productivity at lower costs resulting in reliable systems. That may be a byproduct of DevOps, but the goal of DevOps is to more closely build what customers want in a shorter timeframe. DevOps is about cycling a product or service quicker to have it match more closely what the need is in the market. From there, if that holds, the organization will sell more products and services. DevOps organizations hope that it will be cheaper and more reliable but it very well may not be right away. In fact, DevOps may be more expensive if you factor in the time and energy required by the organization to run much faster product release cycles.
DevOps: a cultural shift
Unfortunately with those fundamental tenets at issue, the rest of the article becomes harder to agree with. The author states that there aren’t any real legacy vendors for DevOps which is a matter of perspective. DevOps isn’t about the vendors or tools ultimately. It is about culture. Every legacy vendor out there is going to adapt their tools to work with DevOps methodologies. Some will succeed. Some won’t. “Shiny” new startups will also compete for the business, but in the end, it’s not about the vendors or tools for enterprises. It’s going to be about cultural change.
The author is right that silos will make a difference in the pace of adoption. Enterprises are big, complex animals. Cultural change at these organizations is next to impossible. Add in departmental and divisional factions and it’s even harder. But cultural change has happened before and it will again. Will it be easy? No. Will it be fast? No. Will it be free? No. But it will happen. Or the company will fall behind, because their competitor will be able to move faster, innovate quicker, and introduce new products and services.
The next challenges described focus in on selling to enterprises and the lack of hard dollar return on investment. The first focuses in on vendors trying to sell to enterprises. The author states that enterprises are predisposed to buy. She’s correct that it’s hard to sell to enterprises, but many startups and larger companies have solved that problem successfully before. Historically, that hasn’t been an impediment to adoption of technologies. Does it take longer? Yes, it does, but if the technology is powerful and enterprises believe that it will help them, they will look for solutions to those problems. The lack of ROI is an interesting observation. As with many things in IT, ROI is elusive and it likely will be with DevOps early on as well. Over time, though, DevOps should be a clearly measurable activity. Product cycle time, defects, and ultimately revenue and profit will be measurable. Whether DevOps is contributing to the bottom line or not will be evident and clear – just maybe not in the short-term.
Fundamentally, DevOps is a different animal at a startup than at an enterprise. This is a topic that we have studied before. The WSJ perspective is an interesting one and can be taken in the right light as a cautionary tale. Enterprises do face different challenges when it comes to DevOps – or any cultural change for that matter. DevOps at an enterprise is a cultural challenge first and foremost. Those enterprises that embrace it as such and focus their efforts on that area first will likely have more success than those who treat it more as a tool issue. There are countless successful enterprises leveraging DevOps. Gene Kim’s response makes that clear. Gene, has been studying these “unicorns” and “horses” and so his response is based on the enterprise DevOps adoptions, successes and failures he has observed. I look forward to more data coming out soon that will shed more light on DevOps in the enterprise.
