Enterprises looking to make the transition to the more agile DevOps model of IT management quickly confront one of its basic tenets: This is not just a transition to a new technology but a new way of working.
It’s been said many times that DevOps requires new thinking in terms of workflows, processes, job responsibilities and a host of other factors, basically leading to a new corporate culture and perhaps an entirely new business model. But at some point, this high-level thinking must translate into practical reality, as in, how exactly are DevOps projects and the newly configured DevOps teams supposed to be managed?
Clearly, there is no one right answer for all enterprises, and even the basic template will vary according to a wide range of circumstances, such as the size of the enterprise, the level of regulatory scrutiny it faces, and the markets it plays in. But from an extremely broad perspective, a number of common elements can help the enterprise chart a successful course through what is likely to be a very challenging transition.
The Right Time for DevOps
One of the first things to recognize, says Bob Davis, chief marketing officer of software management developer Plutora, is that not all applications are suitable for the DevOps model. Large organizations in particular are heavily invested in back-office infrastructure and applications, and these will likely continue under traditional development and support models for some time. DevOps is most likely to have the biggest impact in customer-facing applications, which by nature must evolve more quickly in order to capitalize on fast-moving business opportunities.
“The whole notion of DevOps is to push bits into production faster,” he said. “Eliminate the big testing cycles. Design fast, fail fast, push to production fast.”
The fundamental concepts of DevOps can be traced back to the 1950s when car companies like Toyota were striving for greater efficiency on the assembly line, said Dominica DeGrandis, director of digital transformation at software integration developer Tasktop and author of “Making Work Visible – Exposing Time Theft to Optimize Work & Flow.” The idea was to view the manufacturing process as an integrated, end-to-end system, rather than a collection of distinct steps. When applied to knowledge work, the idea is to ensure cohesion throughout a given project and ensure that the transfer from one phase of the project to another goes smoothly.
“IT operations are where the process suffers the most pain,” she said. “As the agile movement started and developers began to deliver code faster to operations teams, they couldn’t keep up because their processes were not automated.”
To get over this hump, IT leadership must focus on deploying the right tools to automate and streamline the operations side of DevOps, while at the same time working to overcome the cultural differences that inhibit workflows.
“It takes a new mindset that is more focused on flow and the constraints that exist across the entire system,” she said. “In a traditional setting, the idea is to push work onto the next team and hire more people to solve problems. But simply hiring more operations staff just slows everything down because that is a very specialized skillset designed to address one small piece of the project.”
New Roles
In all likelihood, DevOps will require some shifting of job responsibilities, with some functions merging into others, and some perhaps fading away entirely. Two key examples are the classic systems administrator, responsible for provisioning resources and other manual tasks, and the quality assurance (QA) specialist, responsible for integration and performance monitoring. Neither function will go away entirely, but they will likely be folded into a more streamlined process.
“The roles of software developer and systems administrator are starting to converge,” said James Smith, CEO of monitoring software developer Bugsnag. “Coding is becoming more about where software is running, while sysadmins care more about code.”
“The QA position has had the writing on the wall for some time,” he added. “It’s being squeezed from two directions: from automated testing tools for simple tasks and from the conversion to production-level monitoring.”
No matter how the enterprise chooses to define and staff these roles, however, the overarching theme in DevOps management is collaboration. By removing the hard lines between development, testing, provisioning and the like, DevOps requires a higher degree of interaction between team members. Rather than wait until all coding is finalized, for example, testing is already pointing out the weak spots and operations is already starting to figure out the infrastructure requirements.
This can be somewhat challenging at first, but in the end should lead to a much more rapid development cycle and the ability to push upgrades into the pipeline much faster.
None of this is possible, however, unless the entire project team gains a cohesive view of the process. This means the myriad tools and platforms that typically cater to each discipline will have to start talking to one another so that the project itself benefits from an enhanced feedback loop that ensures critical data can reach key points in the workflow, says DeGrandis. By identifying problems at an earlier stage, the team can correct them quickly without having to backtrack through multiple completed steps. At the same time, this helps maintain the contextual view of the workflow that is crucial to a successful outcome.
“Knowledge work is perishable,” DeGrandis said. “If I am trying to break an architecture into microservices, the more time that occurs between decisions made and the point of implementation, the more rework is needed. Feedback loops should exist through every state of the workflow: design, validation, testing…”
For upper-level management, then, a successful conversion to DevOps will require equal parts leadership and support. Ultimately, the vision of how it needs to evolve and its overall contribution to the business process will have to come from the top, but there also needs to be a mechanism for candid reporting from below to monitor how things are working out in the trenches.
And, of course, the real test is whether your newly agile ecosystem is a hit with the user base.
Arthur Cole writes about infrastructure for IT Business Edge. Cole has been covering the high-tech media and computing industries for more than 20 years, having served as editor of TV Technology, Video Technology News, Internet News and Multimedia Weekly. His contributions have appeared in Communications Today and Enterprise Networking Planet and as web content for numerous high-tech clients like TwinStrata and Carpathia. Follow Art on Twitter @acole602.
