From buzzwords to definitions, much has been discussed and debated about DevOps. Yet what it really means is solely up to the IT professionals running the show at thousands of organizations around the world. This article describes building a DevOps culture organically, with less reliance on automation tools and more focus on contextual collaboration, information federation, and visualization.
I love tech tools. During my career I have worked for and consulted with many companies, and every time I begin a project I immediately look for tools or frameworks to help me complete things faster. For a guy obsessed with new tech tools, now is a great time to be in IT. Git, JIRA, Jenkins, Selenium, Puppet, Chef, Bladelogic, uDeploy, Docker, and Wily (just to name a few) are providing IT with a big-box hardware store full of tools designed to help solve technical problems. These tools are variously pitched, sold, praised, and cursed during DevOps initiatives—primarily because they are good enough for most needs but still leave some critical gaps.
With such an availability of tools, you can check off a lot of the items listed in one of those "X Things You Need for DevOps" blog posts that are published almost daily. Continuous integration . . . check. Automated testing . . . check. Continuous delivery . . . check. Automated configuration management . . . check. Application monitoring . . . check. So, now could you say “DevOps . . . check”? I would argue you will never be able to check that box with the above list of tools because unless your IT department fits in one room and goes for beers together every Thursday, you are missing the most important concept of DevOps: the need for continuous collaboration about your applications in all of their states, from development to retirement.
Most organizations I have worked with aren't even close to achieving this level of collaboration across development and operations. They are often dispersed across the globe working in different chains of command with different goals, and despite investments in SharePoint sites and using email, instant messaging, and endless conference calls, information is not effectively shared to those who need it. How does a developer in Singapore collaborate more effectively with an operations team in Atlanta? Why can’t the incredible number of tools in our arsenal be enough to fix this?
You might say, "We'll give the operations team accounts in JIRA, Jenkins, and Selenium, then give the developer access to Puppet, Wily, Splunk, and the production VMs. They can send each other links and paths to information in each of the different tools and they can collaborate through email, IM, conference calls, and a wiki or SharePoint site." That sounds OK—until you realize that each of the email threads or chats filled with useful information gets buried in employee Outlook folders or chat logs. When was the last time you heard someone ask to attend yet another conference call or use yet another SharePoint site?
A likely response might be, "We should have them save the chat logs and email threads in the Operations wiki, the Development Confluence site, or that new SharePoint site." With those kinds of approaches you might be able to find the threads based on string-based searches after a lot of hunting through off-target responses, but more importantly, anyone reading them has no context about how all of the data points in the discussion relate to actual applications, servers, or any other IT asset.
In addition to the lack of context, your IT personnel will spend their days hunting for a needle in an ever-growing haystack of data generated by those amazing tools. Some estimates indicate that as much as 38 percent of knowledge worker time is spent hunting for information to make a decision. [1] Often we give up and make our best guesses based on the information we have at hand. A lot of the time that approach works out fine, but in those cases where it doesn’t, it can mean the difference between a smoothly executed project or one that fails and impacts the business.
What if, when your middleware administrator needs to discuss a problem with the UAT messaging engine, she could do so in context with the other experts in your organization? What if her conversation were automatically saved and directly related to the messaging engine, and if the conversation leads to fixing an issue, the lesson learned can be turned into a knowledge entry specific to messaging engines? Now any IT employee can quickly find this knowledge and see who contributed to it the next time there is a messaging engine issue.
And here’s another practical example. What if, when developers want to collaborate with system administrators about higher memory requirements for their applications due to new features, they can pull them into a discussion in each feature's individual activity stream? The admins could be alerted that they have been added to the conversation by their mobile devices and then contribute to the activity stream and even add other participants, such as the operations manager, so he can weigh in on the need for devoting more memory to the correct VMs. This can all be done no matter where the team members are and what they are doing.
That’s my vision for what DevOps needs to close the tool chain gap. No one can drop in a DevOps culture for your organization—data federation, visualization, and contextual collaboration are critical to enable that cultural change. Since time immemorial, tools have driven changes in culture. Culture doesn’t change on its own or through sheer will of managers. You have to give your teams the tools they need to improve their collaboration. Automation tools and the other types of tools described at the start of this article are important to DevOps, but don’t forget the importance of collaboration tools—and don’t assume the general-purpose collaboration tools you are using today will cut it, because they won’t.
1. McDermott, Michael. "Knowledge Workers: You can gauge their effectiveness." Leadership Excellence, Vol. 22.10. October 2005, ABI/ Inform Global, p. 15.
