The topic of DevOps in the enterprise has been discussed extensively. There are many people who have made a meaningful contribution here due to their level of expertise in both. There are others however who know only one side well and whose contributions are adding quite a bit of noise to the conversation. At times I feel that we are not moving forward on the subject but going around in circles.
I approach devops in enterprise as an end state. Aspirational end state that we are targeting to reach. Developers and operations sharing responsibility for the production environment, culture of collaboration, adoption of software development best practices in operations, heigtened awareness in development of run time and supportability issues - all these still stand. But the path to devops in the enterprise may end up being very different from that of a startup or a greenfield app.
(Side note: Devops is the same whether we are talking about a startup, a greenfield app or an enterprise - but paths to it differ. It's an important distinction.)
Devops is not easy in a typical enterprise. Discussing why this may be so is beyond the scope of this post. Instead, I want to focus on what to do about it.
I suspect that most enterprises could reach devops end state with fewer problems and sacrifices by introducing an intermediate step before devops. I couldn’t care less what it’s called but it can be described as platform/product alignment.
Take whatever org chart you have and identify all of technology. Draw a line not based on dev/ops but based on platform/product. Product is stuff you do for your customers, it implements your business logic. Platform is the rest, these teams focus on shared services and libraries as well as automating your runtime environments. Define what product delivers to platform (usually a set of binary artifacts like for example a WAR file to be deployed to a java container), sit back and enjoy watching your people's technical curiosity make things happen (or in other words - get out of the way of engineers).
The main trick here is that platform part of this alignment will consist of both developers and operations folks. Developers in these roles tend to be somewhat more inclined to adopt devops which helps this strategy a lot - instead of trying to convert everybody at once, you focus on those who are the easiest to convert to begin with.
One important note - under no circumstances should you draw any further lines within the platform team as it will kill the strategy. It’s extremely important to make sure your platform is one team, not two separate team reporting to a Senior Director of Platform. Everybody on the platform team is a Platform Engineer (with numerals like Platform Engineer IV if that’s how you roll), even if their current responsibilities are not the same. Remember that in ideal devops, a developer’s day is identical to operations folks’ day - writing code, planning code, peer reviewing code, deploying code, meetings (yes, I remember that we are still talking about the enterprise) and there is no need to have different titles for folks in dev and ops.
As platform part of your technology organization starts solving problems they are tasked to solve, they will inevitably stumble upon techniques and practices that constitute devops. Remember that devops is not an edict that was invented in a locked room and sent to the rest to follow - it’s a set of techniques and procedures that emerged in the trenches, from bottom up. When facing similar issues, smart people are more likely than not to effectively rediscover the principles that devops is all about.
And after platform reaches devops end state, I am confident that devops methodologies will gain critical mass in your organization sufficient to generate enough momentum to let your entire organization (product included) reach devops.
This idea is not rocket science. It’s simple and straightforward and I am sure there are a lot of organizations in the world who are aready doing it this way. It’s relatively painless and easy to implement, especially if you consider alternatives.
It’s good time to act now - please consider this reorg to set your team up for success in 2015.
Finally, please note that the title of this post says “a path,” not “the path.” I think it’s the easiest way to reach devops for a typical enterprise but it’s not the only one. The key is to realize that devops is not something you adopt - it's something you achieve.