As organizations continue to adopt the DevOps mindset, there is lingering debate as to whether it is more of a philosophy or a role.
I recently had the opportunity to speak with an analyst at Gartner about this. His view is that DevOps is more of a philosophy -- an approach to lifecycle management and how teams are organized around that outlook.
As DevOps is still relatively in its infancy, there’s no one formula to follow or blueprint to work from. But in adopting DevOps into your organization, it can’t be approached as one or the other. It is both philosophy and role, which informs a culture that can align ITOps and DevOps in the rapidly changing IT environment.
The philosophy behind merging IT and development also requires a role that leverages human capital to ensure that this philosophy, this culture of DevOps, is managed, led, and executed. Indeed, you can’t have one without the other.
There are varying degrees of “pace” adopted by organizations who have implemented a DevOps philosophy. According to Jim Duggan, a Research Vice President at Gartner, all companies fit into one of these three paces:
- Webscale: Multiple releases of apps per day - companies like Facebook or Netflix, with as many as 40 deployments per day.
- Agile: One release per day maximum, with as little as two or three releases per month.
- Release-driven: Typically regulated industries that are very disciplined with one release per month, but likely have one release every few months.
Within each of these organizational types, ITOps and DevOps are unique and differ to varying degrees in regard to a philosophy of how to manage processes from an initial requirement definition, all the way through the cycle to production and delivery. The philosophy and impetus behind it is all about organization and making it work better and faster.
And I agree with this, but DevOps cannot be just a philosophy, some kind of invisible hand that guides this process. It must also be a role that embodies the DevOps mindset.
Here’s why…
For starters, many developers are introverted and are not interrupt-driven. They are actually artists. They create things from nothing, and with that artistic mind comes certain strengths. Not all developers are able to work with IT operations and still manage all of their responsibilities related to developing apps, identifying root causes, developing fixes, etc. Working with IT Operations or infrastructure providers is not their forte.
This has led organizations to create an operational-oriented role. It is usually a highly technical developer who understands the inner-workings of the application, but is also assigned to support or availability as the point person for issue resolution. This person is usually a good communicator and very gregarious. And they have project management skills too. So when major issues arise they communicate new requirements, make sure operations get the right resources, and help facilitate the most pressing fix at hand.
This DevOps-as-a-role requires a communication-oriented person who can work well with ITOps, developers, and service providers to make sure everyone gets what they need when they need it.
Most of the time, developers are technology communicators. They like to be in their own world, write their piece of code, and while they understand really well how it works, they can have a difficult time communicating with business owners or ITOps, who don’t necessarily communicate in their same language.
In a way, this role champions the DevOps philosophy by being both a business communicator and, at the same time, a technology communicator, who’s able to understand pressing business needs, while also communicating with operations at the granular level of understanding code and application support.
One of the core principles of DevOps is that developers and operations should work closer together, regularly communicating, and sharing information and tools. DevOps-as-a-role should embody DevOps-as-a-philosophy as a cross-team communicator and collaborator who is both at once project manager and issue resolver, someone who can evolve alongside the changing needs and challenges of the unit, team, or organization.
So is DevOps a role or a philosophy? In my view, it’s both, and you can’t have one without the other. It’s as much about attitude as it is about aptitude, which requires special types of individuals capable of facilitating an ongoing conversation that continuously flows back and forth between ITOps and DevOps.
If organizations are serious about institutionalizing DevOps into their culture, then building that bridge between IT and development requires both the philosophy behind DevOps as well as the role of DevOps to establish the connection, maintain it and build from it as the future of IT continues to evolve.
For more on how you resolve conflict, improve collaboration, and align ITOps and DevOps, read our eBook, "Conflict to Cooperation: Aligning ITOps and DevOps".
