A case analysis of enabling continuous software deployment through knowledge management

The field of software engineering has seen many advances over the past decades that have made it possible to deliver products and features to customers at rates that would have been considered unachievable in the past.

Continuous software engineering is one of those advances: it increases the rate of software delivery by automating large parts of the software development process.

Continous software engineering offers many benefits, like increased customer satisfaction, shorter time-to-market, higher developer productivity, and better quality. But it’s not a silver bullet: continuous software engineering requires tools and a culture change, neither of which are easy to integrate into existing organisations. It may also lead to increased quality assurance efforts (side note: Apparently this has been described in literature, but the article doesn’t provide any citations.).

DevOps is one of the best known examples of continuous software engineering, which integrates development (“Dev”) with operations (“Ops”) and quality assurance (side note: Conveniently left out in the term “DevOps”, because nobody likes QA).

The success of DevOps is based on four principles:

• A culture in which people bear joint responsibility for delivered software;

• Automation of development and operation steps;

• Measurement of how things are going so that they can be continously improved;

• Sharing of knowledge, enabled by tools.

That last principle suggests that proper knowledge management is crucial for a successful implementation of DevOps. Most studies that look at the adoption of DevOps focus on knowledge management tools. This one tries to do… something else I guess.

The article describes a case study in which researchers conducted a set of semi-structured interviews with DevOps engineers at Meta4, a multinational company that specialises in human capital management solutions.

Application of grounded theory yields insights into organisational matters, tools, and people.

Organisations are faced with two types of pressure to adopt DevOps:

• External pressure, which consists of industry buzz/hype and evidence that DevOps and specific DevOps tools actually work very well.

• Internal pressure, due to customers and sales departments that demand shorter release times and better quality. DevOps also makes it possible to improve existing processes (which are already partially automated) and is a more natural fit for an era in which software is often deployed via the cloud.

Respondents mention that partial adoption of DevOps is a good way to minimise risks when one needs to deal with existing systems, and makes it possible to transition gradually to “full” DevOps.

At the time of writing, the impact of DevOps on the company as a whole was limited. However, a transition to a microservice architecture might increase the importance of DevOps throughout the organisation in the future.

DevOps adoption clearly improves cycle times and quality of delivered software. While there are no hard numbers about the cost and benefits of transitioning to DevOps, respondents felt that the payback period is about a year. This is pretty close to what is reported in literature for a company of this size.

DevOps tools not only automate the configuration of systems, but are also a way to codify knowledge. This codification makes it easy for Meta4 to keep multiple near-identical environments consistent with each other.

Commercial DevOps tools are widely available nowadays and work very well.

However, Meta4 also has internal tools, which have been built in the past to support processes that are nowadays associated with DevOps. These existing tools are still useful after the transition to “real” DevOps, as DevOps is more about the agile culture and knowledge-sharing than about specific tools.

The (recently formed) DevOps team at Meta4 consists of three types of people: those that come from the quality assurance and operations departments, those that work on the development of the company’s software, and new hires that have mixed backgrounds in both development and operations. The latter act as a “glue” between the first two groups by mentoring the culture shift process.

Other things that are important for (a smooth transition to) DevOps include:

• Professionals who are able to understand business requirements and translate those into working systems
• Having both people who know a lot about the business and people who know a lot about DevOps and its tools
• Managerial support for DevOps-related initiatives, like communication infrastructure, and the creation of a community of practice
• Team culture, low turnover and good personal relationships