DevOps

Business change is the new norm and software development became Agile in order to cope with this. But software development then hit a barrier when it encountered inflexible Operations deployment processes – particularly at scale. DevOps is, at basis, about extending Agile techniques to Build and Release management – deployment by operations – and is possible because Build and Release can now be coded (automated). And, of course, Agile requires end-user involvement in its process.

The tension is around preserving existing business outcomes – if moving code into production is easier, is there a risk that code that isn’t fit for purpose, or that the business no longer needs, reaches production and adds waste to production processes (that is, it adversely impacts the business outcome)? Where is the quality gate, which ensures that the right code moves into production as well as ensuring that it moves right? And there’s a stakeholder issue – the stakeholders in DevOps include regulators and business strategists as well as coders and business users – the higher levels of the ITIL service delivery model are a guide.

The answer is to take best practices from Dev and Ops and combine them to deliver something more than the sum of these parts – and then governance comes, in part, from the active collaboration of all of the stakeholders in automated business service delivery in assuring the business outcome.

The evangelists for DevOps will be the change champions in the organisation. It needs top management support for the cultural changes involved – people are comfortable in technology silos – but it’s been driven bottom-up – by bright developers who see traditional ops as a barrier to adoption and want to adopt a continuous delivery culture; and, probably most importantly, by bright Ops people who see the way things are going.

The DevOps value proposition is around “time to market” agility – the business runs on software, the rate of business change is increasing and the business demands agile responsiveness from software development; ergo, the organisation needs to remove barriers to getting its software released into production – whilst still managing risk.

Continuous build and continuous deployment automation tools are the key features of DevOps currently, supported by test automation tools. In the future, “social business” collaboration tools such as Fuzed may well have a role in facilitating appropriate stakeholder involvement.

The DevOps market is just starting up the hype cycle and mainstream value is several years out in the future. Nevertheless, there are some early adopters (as you’d expect) and large companies such as IBM are already exploring “DevOps at scale” – see, for example, IBM’s Scott Ambler on “Disciplined Agile Delivery” here. DevOps may well become seen as central to Cloud Computing adoption (itself early in its hype cycle). If everything is a virtualised cloud service, automating the orchestration of cloud services delivery – essentially, DevOps – is a no-brainer.

Currently, the market is being driven by early adopters and comparatively small vendors, especially from the Cloud space. Thoughtworks, e.g., is an interesting thought-leader with a good grasp of Agile at Scale to build on.

However, the big management software companies – IBM, CA Technologies, HP, BMC – are gearing up to dominate this market – and, as was seen with Agile development, DevOps at scale will be a key issue for mainstream adoption, several years out.