Developers develop and IT operations people operate the IT infrastructure. In a traditional IT environment there is a lot of friction between those two objectives. In fact, the goals of developers and IT operations often directly conflict. That’s why so much of DevOps is a function of the culture. Without the right DevOps mindset the DevOps tools and principles are doomed to fail.
Traditional technology roles within an organization function separately from one another. Developers come from a mindset where change is what they’re paid to accomplish. The business depends on them to respond to changing needs, so they’re usually encouraged to create, innovate, and generate as much change as possible. By contrast, operations sees change as the enemy. The business depends on operations to keep the lights on and deliver the services that generate money for the business today. Operations is motivated to resist change, because it undermines stability and reliability.
These objectives make sense independent of each other, but the organization has to be able to function as a whole, which means setting aside conflicting agendas and working for the common good. This is the premise of DevOps.
Developers develop
A developer is someone who writes and debugs code to create software and applications. Once an application is deployed in a production environment, the developer will generally monitor performance and gather feedback from users to implement changes and updates to make the software better. The goal of a developer is to continually create new applications and modify existing ones to make them better—effectively introducing change to the environment on a regular basis.
A traditional developer’s role is measured by his or her ability to effect change. The developer’s worth to the organization—as well as the developer’s salary and bonuses—are typically a reflection of the developer’s initiative and ability to generate new applications and innovative features that help users be more productive.
Operations operates
IT operations or IT admins have one objective: make sure everything is operating optimally. Operations ensures that network resources are available and functioning at peak performance. Once that equilibrium has been achieved, any new demands on the network resources threaten the stability of the environment and require operations to invest time and effort to make sure they’re still performing as expected.
A traditional operations role is measured by its ability to provide a reliable, optimized infrastructure. In effect, that means ensuring as little change as possible in order to guarantee that network resources are available so users can be more productive.
The culture clash
Ultimately, both developers and operations are striving for the same thing: to make the organization as productive as possible. In spite of their similar objectives, though, it’s easy to see how these conflicting roles can get in the way of each other. Developers are trying to create and improve applications as quickly as possible, and operations is doing everything it can to prevent changes from occurring in the environment. Something has to give in order for the organization to function effectively and efficiently.
“In traditional ops organizations, we often have chosen functional-orientation, organizing our teams by their specialties—we put the database administrators in one group, the network administrators in another, server administrators in another, and so forth,” saysGene Kim, coauthor of The Phoenix Project and the upcoming DevOps Cookbook, and a driving force between the currently running DevOps Enteprise Summit in San Francisco. “Among the consequences for this is long lead times. For complex activities such as large deployments, we must open up tickets with multiple groups, coordinating hand offs, with work waiting in long queues, with implementers often having little visibility of how the work relates to the value stream goals.”
You can see the whole story at TechBeacon: When DevOps is realized: Overcoming traditional dev and ops mindsets.
- Tackling Swivel Chair Syndrome - November 14, 2024
- Unlocking Proactive Compliance with Adobe’s Common Controls Framework - October 14, 2024
- Unlocking the Power of Continuous Threat Exposure Management - October 8, 2024
