DevOps isn’t only for startups

I’ve been hearing a lot about DevOps lately. Every ITSM conference that I attend has at least one presentation on the wonders of DevOps, and I’ve seen lots of blogs and posts in social media from people who say we should all be using this approach to managing our IT services.

I guess there may be some readers of my blog who aren’t familiar with DevOps, so here is a very brief description of what it’s all about, to set the context for the rest of the article. (My apologies to any DevOps gurus out there who will no doubt let me know where this is not 100% accurate).

• DevOps is a way of working that improves communication and collaboration between people who develop software and IT services, and people who manage and operate them.
• DevOps can deliver a very high throughput of changes, enabling organizations to adapt very quickly to changing environments, and changing customer needs.
• DevOps works well with Agile software development. The combination of these can enable very large numbers of small software changes to be delivered very quickly.
• DevOps tools support infrastructure-as-code, continuous integration and continuous deployment
  • Infrastructure-as-code uses an automated process to create operating environments in the cloud.  This ensures that the correct infrastructure is in place every time, and that it has been created accurately and reliably, so you can be confident that production and testing will always run in the same well defined environments. It also supports configuration management by deploying the infrastructure from a source controlled data file.
  • Continuous integration merges all new code into a single stream. It does this very frequently, and with automated testing. Consequently there is no need to run multiple separate development streams and no need for complex integration at a later stage. This can result in simplified releases.
  • Continuous deployment automatically deploys the tested code into production environments. Since each change that is introduced is very small and the process of introducing it is fully automated, the risk of any errors being introduced is very small too. This can enable very high rates of production change with minimal risk.

People who advocate DevOps tend to be very passionate about it. . They think that this way of working will completely replace the old fashioned, legacy approach, which can be resistant to change. They contrast nimble DevOps outcomes with old fashioned long projects that deliver complex software after months or years of development. This complex software is then typically handed over to operations teams with inadequate testing and documentation and many bugs are found after the service goes live.

It’s certainly a very powerful story, but almost every organization that actually uses DevOps is an Internet based business that started out with DevOps and had no legacy IT systems to manage. When I talk to organizations working in other industries such as finance, manufacturing or healthcare I hear a very different story. IT managers in these companies tell me about regulatory requirements, the need for very high levels of security to protect the confidentiality, integrity and availability of information that is critical to the survival of their business, and a belief that the DevOps approach would not fit with their organizational culture.

What does this clash of cultures mean for the future? One possibility is that we end up with two completely different approaches, each used exclusively within the types of organization where it fits best. So the Internet startups could continue using DevOps and the legacy organizations could continue to use their established methodology, and they could effectively ignore each other. I think this would be a great pity as there is a lot of value in the DevOps approach if we could see how to integrate this into other types of organization, so here are my thoughts on how DevOps could be introduced to legacy IT organizations.

In my last blog, titled Do you really need all those cumbersome processes?, I wrote about how IT organizations could categorise IT services to help them respond to different needs. I mentioned the Gartner Pace Layered Application Strategy which distinguishes between:

• Systems of Record. These support an organization’s critical data and transactions. They typically have a low rate of change and may be subject to regulatory requirements.
• Systems of Differentiation. These support unique company or industry capabilities. They need fairly frequent reconfigurations to meet evolving business or customer needs.
• Systems of Innovation. These are often built or modified on an ad-hoc basis to meet new requirements or opportunities.

I have heard people talking about bimodal IT recently, where they just distinguish between two categories of IT services. I’m not sure who coined this term, but it is definitely used by Gartner.

One approach that legacy IT organizations could take is to introduce DevOps for their systems of innovation, while protecting their systems of record with a more traditional approach. This would involve setting up what are effectively two distinct IT organizations, with different ways of working, different tools, and most importantly with different attitudes, behaviour and culture. This would certainly allow them to gain some of the benefits of DevOps while maintaining the security of the critical business systems, and is definitely better than ignoring DevOps altogether, but I think that it is possible to do better than this.

DevOps has a number of key ideas that I think should be adopted for even the most critical systems.  IT departments have complained for as long as I can remember about development teams that “throw software over the wall”, and how this causes major problems for both IT and their customer. DevOps provides a model for fixing this once and for all. Don’t keep those old walls between the different parts of IT, here are some DevOps ideas that will work for every category of IT service:

• Form cross-functional teams that own both the development and the support and operation of software. Give these teams targets that relate to real business outcomes and motivate them to deliver what your customers want.
• Involve operations staff much earlier in the development lifecycle. Operations staff shouldn’t just give the developers a few “non-functional” requirements and then wait to test the product later. Get involved and provide the expertise needed to make sure that new software can be operated, that incidents and problems can be diagnosed, that performance can be measured.
• Continue the involvement of development until staff much later in the development lifecycle. Let them share in the 2 AM phone call when there is a failure, involve them in collecting the data needed to diagnose difficult problems. Let them experience how difficult it is to perform routine operational tasks so they can help to improve the design next time.
• Develop end-to-end processes. Don’t create a change management process that is only designed to protect operations; instead, create an end-to-end process that joins together collecting requirements, developing code, building a release, designing and implementing tests, submitting and approving change requests, and deploying the final build. If all of these processes are designed together as a single seamless flow then you can optimise the flow. Submitting a change request could be as simple as clicking a button on a form, because all the artefacts needed have already been created and lodged in the correct place by earlier steps in the workflow. You can use techniques like those found in the Theory of Constraints to identify where improvements are needed, and focus your activity on the things that matter.

I’m not saying that this will be easy, but what I am saying is that even if you don’t think DevOps can be applied to all of your IT, you can adopt the attitudes, behaviour and culture that underpin Devops into your entire IT organization. This will enable you to apply continuous integration and deployment where it is appropriate, but to retain the legacy approach where that makes sense, and it will let you do this with one single integrated IT organization, rather than needing to separate out the two approaches into their own space.

Even if you don’t want to adopt all of these ideas, there are probably one or two things that you could do to improve integration between IT development and operations people. So how about it? What change could you make to improve the attitudes, behaviour and culture of your IT organization?

Picture credit: Matt Moor