Contact ITInvolve

DevOps Needs a Place to Work

Because of the roots of DevOps within the Agile Software Development movement, there is a strong theme of “individuals and interactions over processes and tools” within the DevOps community (see for more). To a significant extent, this attitude has been taken to mean tools are not really necessary and everyone can or should roll their own approach so long as they follow DevOps principles (for a good DevOps primer, check out the Wikipedia page here and the dev2ops blog here).

More recently, the DevOps community has begun to embrace a variety of automation and scripting tools, notably companies like Puppet Labs and Chef, because DevOps practitioners have recognized that doing everything by hand is both tedious and highly prone to error. That has led to a new term “infrastructure as code” (Dmitriy Samovskiy has a quick primer on his blog here.) But beyond automation (and, to a lesser extent, monitoring tools), the DevOps community hasn’t fully embraced the need for other types of tools to aid in DevOps work.

What’s more, despite this evolution around the need for automation tools, and the recognition that individuals and interactions are key, there are still a lot of walls in most organizations that impede the DevOps vision for continuous delivery of new applications. Quoting from dev2ops:

Development-centric folks tend to come from a mindset where change is the thing that they are paid to accomplish. The business depends on them to respond to changing needs. Because of this relationship, they are often incentivized to create as much change as possible.

Operations folks tend to come from a mindset where change is the enemy.  The business depends on them to keep the lights on and deliver the services that make the business money today. Operations is motivated to resist change as it undermines stability and reliability.

Both development and operations fundamentally see the world, and their respective roles in it, differently. Each believe [sic] that they are doing the right thing for the business… and in isolation they are both correct!

Adding to the Wall of Confusion is the all too common mismatch in development and operations tooling. Take a look at the popular tools that developers request and use on a daily basis. Then take a look at the popular tools that systems administrators request and use on a daily basis. With a few notable exceptions, like bug trackers and maybe SCM, it’s doubtful you’ll see much interest in using each others [sic] tools or significant integration between them. Even if there is some overlap in types of tools, often the implementations will be different in each group.

Nowhere is the Wall of Confusion more obvious than when it comes time for application changes to be pushed from development [to] operations. Some organizations will call it a “release” some call it a “deployment”, but one thing they can all agree on is that trouble is likely to ensue. 

Again, despite the recognition that some level of automation tooling for DevOps is needed, and despite the fact that individuals and interactions are seen as critical, the DevOps community hasn’t really developed a strong opinion on exactly how Dev and Ops should work together and precisely where they should do so.

Julie Craig of Enterprise Management Associates, describes the need pretty well in a recent whitepaper:

“…their tools must interoperate at some level to provide a foundation for collaborative support and Continuous Delivery.”

“DevOps-focused toolsets provide a common language that bridges skills, technical language, and personalities. In other words, they enable diverse personnel to seamlessly collaborate.”

“…tools must interoperate to support seamless collaboration across stages…data must also be shared as software moves from one stage to the next.”

Now, it’s all well and good to talk about the need for integration across tools and more collaboration, but where and how should Dev and Ops functions actually go to get work done together. Where and how do they best exchange information and knowledge about releases that are in process, engage with business stakeholders to validate business requirements, notify stakeholders of changes to functional specs and operational requirements? Where do they go to have an accurate understanding of the full stack required for deployment, to understand disparities and drift between pre-production and production environments, and collaborate together on deployment plans and potential risks that may exist and should be mitigated?

These are just a few examples of the DevOps work that must take place to enable continuous delivery, but unfortunately most DevOps practitioners are trying to use outmoded approaches or rejecting tools as viable to addressing these needs. For example, teams have tried using Wikis and SharePoint sites, “It’s on the Wiki” is an all too common refrain. Or they have fallen back on endless meetings, email chains, and real-time IMs that are limited to only select participants and with knowledge that is shared and then lost in an inbox or disappears when the IM is closed. And most DevOps practitioners will tell you they have rejected the CMDB and service support change management tools as well, because they a) don’t trust the data in their company’s CMDB (or perhaps multiple CMDBs) and b) believe traditional ITIl change tools are far too process heavy and actually work against the goals of agile development and delivery.

What we need instead is a place where Dev and Ops teams can actually work together and collaborate with the business – all the way from requirements planning to post-deployment issue resolution. This new workspace shouldn’t replace the tools that each group is already using and it should work with existing ITIL tools too. Instead, its purpose is to provide a unifying layer that brings together the relevant information and knowledge across the DevOps lifecycle, and employs modern social collaboration techniques to notify and engage individuals based on what they are responsible for and have opted into caring about. What’s more, it should leverage information from CMDBs and discovery tools along with a range of other information sources, and provide a mechanism for peer review to validate this information continuously, fill in gaps, and correct bad information too – so that Dev and Ops practitioners have a place they can go to access all the information they need to do their daily work efficiently and make accurate and timely decisions that move the business forward.

With a new DevOps workspace like this, we can finally overcome the limitations of traditional IT management tools, outmoded collaboration practices, and embrace tools that are built to support DevOps practitioners and their interactions. It’s what we call an IT agility application, and it’s what we offer at ITinvolve. You can read more about how it works in this in-depth use case document.

Matt Selheimer
VP, Marketing

Leave a Reply