On May 13th, Rachel Shannon-Solomon wrote an opinion piece in the Wall Street Journal’s CIO Journal section entitled “DevOps Is Great for Startups, but for Enterprises It Won’t Work-Yet.” In this piece, Ms. Shannon-Solomon implies that DevOps—a loosely-defined IT initiative oriented toward creating higher quality and more resilient systems—currently faces too many hurdles to see broad-spectrum adoption. Unfortunately, this assertion is incorrect and based on some rudimentary mistakes individuals make about what defines DevOps and what is required to be successful with DevOps adoption.

First, I will address Ms. Shannon-Solomon’s premise and then propose alternative thinking from other industries that will work well for enterprises. Ms. Shannon-Solomon’s initial point that silod-structures and organizational change are necessary to institute DevOps is an area of debate and contention among many leading the DevOps charge. There is an entire school of DevOps influencers that do not believe silos are the enemy and, indeed, serve a purpose in large IT organizations for ensuring focus and a level of specialization needed to ensure that the prime operational mission—keeping the systems available and secure—is met. The issue Ms. Shannon-Solomon uncovered relates to organizations that have been indoctrinated into the school of thought that DevOps requires cultural change. One of her later points in the piece explicitly states that the hurdle many DevOps tools vendors are running into is related to attempts to sell this cultural revolution.

This entire line of thinking is spurred by the perspective that DevOps fosters greater collaboration between various facets of IT that need to work more closely to ensure successful completion of the tasks. Moreover, the cultural change is not revolutionary, but evolutionary, with regard to instituting accountability for the availability and security of the corporate assets across all of IT. The outcome being reduced finger-pointing, reduced outages and faster recovery times in cases where outages do occur (and they will).

Ms. Shannon-Solomon’s points around build vs. buy illustrates another common misunderstanding regarding DevOps, which is that tools are an essential element of adoption. It is true that a key element of DevOps is automation as it provides consistency and reduces configuration drift—the issue where application and infrastructure configuration changes are instituted with loose control leading, a leading cause of outages—and increases productivity through the reduction of time spent on repetitive tasks. However, there are a bevy of tools already deployed in enterprise environments that can be used to drive an end-to-end design-build-test-stage-deploy-operate process. Indeed, I, and other DevOps throught-leaders, have indicated caution with regard to tools adoption around DevOps as it can lead to new IT silos and a significant increase in code and scripts that require their own architecture and maintenance lifecycles.

Finally, with regard to her point about return on investment, Ms. Shannon-Solomon addresses, anecdotally, one aspect of the DevOps process focused on engineering and development. Specifically, she addresses a lack of ROI with regard to agile development projects, when it’s important to examine and measure impact on all facets of application delivery including those that touch security, network operations, data center operations and help desk, as would be expected of an effective enterprise DevOps strategy. However, the real value to any business in successfully adopting DevOps is the increase in focus on depleting backlog and supporting innovation that is currently lost to just keeping the lights on. As with cloud computing, the greatest value proposition to the business is increased agility.

Where I agree with Ms. Shannon-Solomon is that the same tactics used to institute DevOps in a startup will not work in an enterprise setting. These are very different environments with extremely different goals and requirements. She is correct in her assessment of enterprise as resistant to change and stymied by organizational structure. However, requiring a “rip-n-replace” approach has never been popular in enterprise settings and tearing down the silos to gain efficiencies or achieve IT modernization are simply utopian follies.

Interestingly, an answer to this problem domain can be found in military strategy. Armies are simply a group of individualized regiments each with a specific responsibility toward an overarching mission. Within each regiment, the commanding officers institute rules and procedures based on military guidelines and the specific situation on the ground. Each regiment carries out its assignment based on a specific timeline as part of a bigger plan that leads to completion of a whole mission. In this scenario, DevOps comprises the military guidelines plus the individual commander’s input.

The real hurdle that lies in front of enterprises is the lack of well-understood missions as defined by the executive office. Often when speaking with IT management I will ask, what are the top 3 initiatives of the CIO and CEO for this year and next. Quite often, the answer to this question is unknown or unclear. In some cases, they just haven’t been clearly laid out by the CEO, in other cases, the information does not get disseminated beyond a certain point of management. In lieu of of mission directives, the regiments will aimlessly execute the last known set of tasks. To those who have experience in enterprise IT organizations, this can easily be translated into, “because it’s the way we’ve always done it!,” which is a curse of death for adoption of well-intentioned DevOps initiatives.

Ms. Shannon-Solomon’s perspective is greatly skewed by her association with those attempting to sell DevOps; those is attempt to implement change through the introduction of new tools and cultural revolution. This approach is akin to Woodstock. It produced great music, raised awareness of what was happening in Vietnam, but did little to dramatically change the lives of the majority of individuals living in the United States. Impact on the scale of the enterprise occurs through accountability, incentive, and management directives. The cultural change is one of constant improvement. DevOps initiatives approached with this as a goal and following something akin to the regiment model can achieve great strides in delivering on the larger mission and obtaining the known benefits of agility.