How cloud-native needs cultural change

This is the third in a series of posts that delves deeper into the questions that IDC’s Mary Johnston Turner and Gary Chen considered in a recent IDC Analyst Connection. The third question asked:

How will IT management skills, tools, and processes need to change [with the introduction of cloud-native architectures]?

Mary and Gary note that the move to hybrid architectures “switches the IT operations team's priorities from maintaining specific components to ensuring the delivery of end-to-end services measured in terms of service-level agreements (SLAs).” They also note that there’s a huge cultural element. For example, “Line-of-business stakeholders will have to partner with IT operations and development staff, either individually or as part of collaborative DevOps groups, to ensure that services are implemented as expected and that test-and-release cycles are well integrated.

Those of us with technology backgrounds often have to fight a tendency to overly focus on the tools part of the equation. Open source technologies including containers and container packaging systems, container orchestration, platform-as-a-service, cloud management platforms, provisioning, automation, business process management, and continuous integration/continuous delivery are certainly important enablers for both deploying next-generation applications and integrating them with existing IT. However, successfully introducing cloud-native requires spending at least as much time on culture as tech.

While this is easy to say, it’s hard to do. There’s no order form for “culture” and, in fact, there’s arguably no dial labeled “culture” that an organization can directly twiddle. Rather, in the context of DevOps as well as more broadly, culture is often best thought of as an output of things that organizations can more directly influence. Open source practices offer significant insights into these cultural inputs including leadership, organization, incentives, and trust. This reinforces the affinity between DevOps and open source. (An IDC study of DevOps early adopters from last May found that 82 percent thought that open source was a critical or significant enabler of their DevOps strategy.)

For example, successful open source projects depend on vision and leadership but the details of how they are organized differ significantly. Different projects are more or less open to external contribution. Some can best be described as having a “benevolent dictator.” Others follow a more structured foundation model of some sort. (Consider the difference between the organization around the Linux kernel and OpenStack.) The differences may be historical or they may be the natural result of the nature of the project and its goals.

Similarly, there’s no single right way to do DevOps and to adopt cloud-native architectures. The aforementioned survey found some early adopters doing DevOps in dedicated groups and others driving strategy from a variety of existing roles. As with open source, best practices will doubtless emerge but it’s unlikely they’ll converge on a singular approach for all situations.

Transparency and rich communication flows are also important for both open source projects and DevOps. Understand who made changes. When and why did they make them? What’s the state of the project? Open source projects have experience answering questions like these in spite of cross-functional and often highly distributed teams. Again, the details vary but many of the most successful projects recognize the importance of augmenting traditional “low bandwidth” tools like email and IRC with video and face-to-face gatherings from time to time.

Finally, one of most direct ways that an organization’s leaders can shift culture is by putting the right incentives in place because incentives matter. Incentives in a DevOps organization (money--but also advancement and recognition) need to reward trust and cooperation. My colleague Jen Krieger pointed out in a recent podcast that reward systems shouldn’t just be top-down either. She noted that: “It's going to be really hard to encourage a system of collaboration or teamwork, if there's no way for a team member to say thank you to another team member other than just saying thank you.”

Incentive systems also need to allow for failure; otherwise the sort of experimentation that underpins a great deal of open source innovation won’t happen. In fact, arguably one of the key points of DevOps is to allow for better experimentation. Systems have to be designed in a way that failures are fast and low-cost/consequence. But design goes beyond test, integration, and deployment technology or cloud-native infrastructure. Incentive systems also need to be matched with an environment where experiments are encouraged--even though they don’t always work out.

Ultimately, shifting toward cloud-native and integrating it with today’s systems involves a lot of new technology, new workflows, and new processes. However, if the people involved aren’t considered, things will end badly.

Read the accompanying parts of the series:

Part 1

Part 2