Draw a DevOps adoption roadmap by learning from current users

peshkova - Fotolia

Barrier-busting tops organizations' DevOps goals

Every IT shop is different, which means implementations of DevOps are just as diverse. A cross-functional group of DevOps adherents shares what success looks like in action.

DevOps promises ingenious development, lightning-fast IT provisioning, delighted customers and spontaneous group hugs between sys admins and architects with testers squished in the middle. That's the goal anyway.

In reality, DevOps goals and definitions change as adoption moves from unicorns to horses to donkeys -- from the Twitters of the world to the largest manufacturer in your state to the regional bank with a branch in your hometown. DevOps translates from philosophy to toolkit in different ways from company to company and even from project to project, depending on the existing talent, company size and approach to tasks as well as the agreed-upon metrics for success.

SearchITOperations asked a sampling of adherents, from an Agile coach to an infrastructure leader, to share how they define successful DevOps implementation.

Most DevOps adopters agree that the term is synonymous with collaboration -- whether that means dedicated infrastructure teams share input on the requirements for a new project, or silos disappear in favor of a mix of quality assurance (QA), development, infrastructure, security and other people in a cross-functional group.

Organizations' DevOps goals go beyond this shared focus to include what consultant J. Paul Reed of Release Engineering Approaches called "moments ... where the team gets it" or "did something that they were not ever able to do before because the constraints were changed." Continual improvement is good -- revelatory transformation is better.

While DevOps definitions vary among IT professionals, they all know what it looks like when implemented correctly.

Download this podcast

Rob Dull, Agile coach, defines DevOps in the context of Agile and lean.

Rob Dull, an Agile coach for a large software-as-a-service provider, gave a succinct interpretation of what DevOps shops should strive for: "a more IT-specific perspective on lean culture." Dull sees a nested set of modern operational cultures encompassing DevOps with lean, Agile and Kanban:

Lean, originating in manufacturing, espouses continuous improvement and reduction of waste. Incremental change is favored over large, momentous change that happens less frequently. Companies achieve leaner operations by defining steps in a process and identifying unnecessary or poorly executed steps.

Agile, originating in software development, encourages iterative, simple development of code, where any large project can be broken into constituent pieces. Agile relies on continuous approval or rejection of changes during development rather than at project completion.

Kanban is a visual system of lean organization. Kanban standardizes the flow of parts or tasks to complete a project using cards with order or project information on them. In a DevOps context, a Kanban board organizes work, particularly across functional groups, and identifies how much work is in progress at a given time.

IT organizations are not monolithic, Dull said -- they apply various degrees of lean, DevOps methodologies to different applications depending on vulnerability, app architecture and other factors.

The paradox of DevOps is that it is all about the right tools -- and at the same time, there's no such thing as a DevOps tool. "It's not a tool; it's a philosophy," said Nadia Makhnovskiy-Linares, who does QA automation and testing for a company that offers marketing automation to recruiters. It's fashionable to call any IT capability or development advancement DevOps, but Makhnovskiy-Linares emphasized that the term truly emerged as the answer to a question: "How can we continuously improve and deliver the product to the customer, to continuously get the customers' feedback to make them happy, and to withstand competition?

Download this podcast

Nadia Makhnovskiy-Linares, QA tester, defines DevOps and its effect on the IT team.

DevOps is cradle-to-grave tight collaboration facilitated by automation and standardization on technology stacks, said Yemi Oshinnaiye, an associate chief at the systems engineering division of the office of information technology for U.S. Citizenship and Immigration Services in the U.S. Department of Homeland Security.

While Oshinnaiye sees DevOps in action as collaboration between groups -- a problem in the ops space requires developers and product owners, and a development project requires operations involvement for the proof of concept -- he suggests anyone with a siloed job put full-stack skills on their list of DevOps goals.

"I was a software developer and I then moved to the infrastructure side," Oshinnaiye said, and he credits that knowledge of both sides for his ability to lead change. "When something happens … my development brain always kicks in, but I still have to think of infrastructure."

Full-stack knowledge empowers team members to understand what changes happen and why: Developers understand the platform structure and technicians conceptualize resources as versioned code.

"This whole idea of silos needs to go away," affirmed Kevina Finn-Braun, director of product infrastructure service management at tax and finance management software provider Intuit. Her DevOps goals are all about delivering better-smarter-faster to the customer and using anyone in the organization in any formation to make that happen. DevOps works, she said, when there are no functional boundaries between people with different areas of expertise.

As a consultant who educates and reshapes enterprise IT teams, Reed avoids one single DevOps definition and instead focuses on the goal of exposing a team to a new way of doing things. Experiments allow for new ideas without risk to live systems. For example, Reed worked with a team to launch a product on Amazon Web Services rather than their usual deployment process. The experiment took 48 hours, well below the typical six- to eight-week lead time and drastically shorter than the two weeks they allocated for the experiment.

"This is where all of this hard work that we do ... pays off," he said. "That's what DevOps looks like."

Next Steps

When DevOps goes right, you know it. You also know when DevOps goes wrong, whether because of common pitfalls, a bad strategy or simply because old habits die hard.

Dig Deeper on Scripting, Scheduling and IT Orchestration