Change is always difficult, especially in larger, older orgs - whether through calcification or inertia, as Rich pointed out. And let's face it, we don't use the word 'legacy' pejoratively for nothing. ;)

I do think many of the benefits in capturing and standardizing policy, governance, and risk of change; and the resulting ability to accelerate the rate of reliable change; are core to the automation that enables a more scalable and efficient DevOps execution.

Are those values also inherent to DevOps per se? Or rather just to automation? The technology alone does bring substantial value, even if you don't have DevOps in mind; but it is certainly not sufficient for the fundamental change that DevOps entails.

I will have to look up Cerf's ideas on this. I can guess at the premise, and I do agree.

For sure, it is increasingly clear that older enterprises especially need to do special to enable faster innovation. Almost every day a new technology-based business threatens these older businesses. They must react faster, better. cheaper with inovation of their own.

I wrote in 'The Innovative CIO' about IT leaders stepping up to push innovatve technology ideas to other part of the business, but also enabling those other areas to pull technology innovation for themselves too.

DevOps helps on both sides of this equation too - enabling IT to be more responsive, but also allowing business to more rapidly get from ideation to minimum viable product. It is a no-brainer to me, too.

Am at Future In Review where Vint Cerf talked about the importance of permission-less innovation. Certainly large enterprises need a form of this magic these days, as much as smaller businesses. Devops is the future for organizations of all sizes.

Rich Wolski, CTO of Eucalyptus Systems, comes closer below than CIO Journal writer did in describing why large enterprise systems are calcified and ossified. It's not that these organizations like to fight rationality.

Rachel's point, as I understand it, is that enterprises are slow to adopt DevOps -- slower than SMBs or start-ups. I suspect that fact is true but the reasoning behind the assertion doesn't necessarily seem sound.

Enterprises centralize IT so that they can implement policy consistently at scale. DevOps does scale, but it does so primarily because a raft of new technologies (like cloud computing) make it possible to "code" many of the operational policies so that they can be implemented in an automated and curated way scalably.

The problems large enterprises face is one of legacy policy implementation. It isn't that they are ossified or siloed against reason. Enterprises must convert a centralized system for implementing policy to a distributed one and, unfortunately, there is a dirth of tools and knowledge available to make the transition on the fly. Indeed, IT policy is usually the infrastructure component that is most incrementally developed and thus changes the slowest making it the hardest to "upgrade."

Thus while it is relatively easy (read: inexpensive) to adopt DevOps at a small scale and to bring tooling on board and scale increases, it is much harder (read: expensive) to convert a legacy operation that has already achieved scale from a centralized paradigm to a distributed one.

DevOps may not be the right word but it's more than a buzzword. Mann himself has said that he prefers "continuous delivery" or some other moniker that refers to frequent updates to production systems. Glad Mark Thiele, an IW cloud contributor and executive VP of data center technology at SuperNAP, chimed in.

As usually it's very well written with great supporting info. I tend to agree with the majority of your comments as they pertain to the article by Rachel Shannon-Solomon from the WSJ.

However, I would like to add some caveats that don't often make the headlines in regards to DevOps implementations.

DevOps is as much an organizational movement as it is a technology strategy. The fact that many enterprises are silo'd and would struggle to adopt is true, but doesn't change the fact that it's still the right approach. Many enterprises struggled with the idea of virtualization, and then Cloud and the issues of adoption are similar.

There is no doubt that a small company with little or no structure has the best opportunity to implement DevOps quickly and effectively by the very fact that they are in effect "green field" environments. Virtually any IT solution is easier to implement when you can start with a green field approach.

As I see it there are a number of assumed benefits associated with DevOps. Most commonly called out as a benefit is agility. There's no doubt that agility is a key opportunity, but not all businesses will benefit equally. I prefer to look at DevOps from the framework of the "ops" part. As systems become ever more complex and our environments are more hybrid (data centers, cloud, services, distributed apps, etc), the need to provide guarantees on policy and change management through the lifecycle of test to RTP (release to production) becomes even more critical. The potential of properly implemented DevOps is that policy, governance, and risk associated with change are all captured and managed the same way, every time. Attempting to speed broken, human oriented processes that most of us use today is a dangerous proposition.

Will it be easy for larger businesses to implement DevOps, no, but since they already need to consider different org models to "own" cloud properly, they might as well suck it up and do it right.

Drew, that is the $64 million question! DevOps is very much about cultural change to break down those silos, but I don't think there is a definitive way.

You can work on team-building and cross-skilling; you can second a selection of dev and ops (and probably security, storage, DBA, network admins too) into a short-term 'devops team' (not ideal, but often pragmatic way to get started); you can even change your org structures to align individual staff to business services rather than technology silos; you can push new shared tools for key functions like service delivery or operational monitoring.

But you must be careful not to just create new silos ('the devops team' or 'the chef specialists'), so focusing on the cultural change is a key starting point.

Drew, I am not an expert on DevOps, but from what I've read, you want to standardize the environment as much as possible. Buy variations on one type of server, allow a narrow range of operating systems that will be maintained by someone else and stick to them. Limit the development tools, even though that is viewed as a serious incursion on the development team's preference and authority. Concentrate on the technologies needed by your organization and bar those that are peripheral or personal preferences. By simplifying the environment, you move closer to a DevOps style of operation.

As InformationWeek Government readers were busy firming up their fiscal year 2015 budgets, we asked them to rate more than 30 IT initiatives in terms of importance and current leadership focus. No surprise, among more than 30 options, security is No. 1. After that, things get less predictable.