A big part of adopting DevOps involves changing an organization’s culture. At Open Source Summit in Los Angeles, Matt Micene will host a birds of a feather session discussing how and why culture change occurs and why collaboration is the cornerstone of successfully implementing new practices.
Micene, a Senior Evangelist at Red Hat, has more than 15 years of experience in information technology, ranging from architecture and system design to data center design. He has a deep understanding of key technologies, such as containers, cloud computing, and virtualization. In this interview, Micene describes some of the challenges of DevOps adoption and the need for culture change.
Linux.com: How do you define the DevOps movement? Is it a restructuring of teams to break down silos or is it more than that?
Matt Micene: I look at it in terms of Conway’s Law — to change the way you design a system you have to change the way you communicate. Conway may have been thinking about smaller units (across teams), but I think it holds across departments and divisions. Breaking silos is about building those new bridges and paths.
You can trace the existing silos to organizational thought. “We need to control risk associated with changes, so we need a change control board. We need to limit who has access to sensitive data, so only this team has access to production systems.” With enough history, you can trace any policy to a specific event that broke production. DevOps challenges the way that organizations think about their IT processes.
DevOps methods find new ways to address the same needs; smaller changes introduce less risk than large ones, responsibilities should be on accountability not roles. Communication and collaboration are important to make sure that all of the voices involved in delivering value via an application are considered; not just in IT but also the lines of business.
Linux.com: What kind of challenges that organizations and employees generally face?
Micene: Many people look at DevOps as the next Agile or how to run an IT project. You’ll see a focus on automation and software delivery. New tools will be built or introduced, and they won’t provide the sweeping change promised.
The bigger challenges come from changing people’s points of view on where responsibilities end and how to step outside their comfort zone. “Why should a developer carry a pager? That’s why operations is here, we write code and fix bugs, they manage the application.”
And IT isn’t the sole player, getting the person who owns the bottom line to accept that 10 deployments a day to production is less risky than one big deployment a month can be difficult. Sometimes we need to change the definitions of words that we’re used to using. There’s a big difference between a “deployment” that updates a 100 lines of code to fix a feature and one that takes a whole weekend to change database schema and deploy a new version of an application that has 100s of changes and new features.
Linux.com: Does focus on culture really matter? Isn’t it all about technology?
Micene: Culture can have a lot of different definitions, especially when talking about a business. Let me offer this one without getting too academic: culture is a shared set of learned knowledge, habits, and beliefs about what is right or wrong.
The key there is that culture is shared and learned. To change culture you need to build a new consensus on what works, and then communicate it broadly. Corporate culture often isn’t planned; it’s a living aggregate of all of the experiences, and policies are the written expression.
If DevOps is about people, processes, and tools, then two-thirds of DevOps is about culture; the why and what we do things as a group. If you can’t change those, changing the how by introducing a new tool won’t get the result you want. The technology improvements are important, too. You won’t get the results you want if you’re still thinking “don’t break the nightly build” and not “the pipeline always delivers deployable code even if though build broke.”
Linux.com: A lot of companies are now consuming open source; it’s becoming a norm. Is it also creating some cultural changes?
Micene: Absolutely. Introducing new ideas into a culture sparks a reaction. Open source software makes people think differently about their IT solutions, even if you’re working with vendor-supported open source software. The rise in “inner sourcing” practices within organizations is tied to the normalizing of open source. Open source introduces the idea of collaboration to organizations that may never otherwise consider it.
Linux.com: Who should attend your session and why?
Micene: DevOps is all about people collaborating, and that’s my goal for this “birds of a feather” session. Rather than listen to someone else talk, I want to get people together to talk about their issues, ask questions, and hopefully hear some success stories too. If one person goes home with a way to un-stick a stalled effort or how to better introduce a new idea from a talk they heard at Open Source Summit, I think that’s a win.
Check out the full schedule for Open Source Summit here. Linux.com readers save on registration with discount code LINUXRD5. Register now!
