As an organization moves to a DevOps model, there will arise new methodologies, new tools and new technologies, but early on the initial cultural challenges for departments, teams and individuals are typically the largest obstacles to adoption. This aspect was the focus in the previous post in this series, A High Level Plan to Win the Hearts and Minds of Dev and Ops.
In this post, we shift the discussion to the nuts and bolts challenges of DevOps transformation including process and communication misalignment, lack of adequate tools and how even the architecture of the software currently under development can present an impediment.
These challenges often appear larger than life, but if addressed step-wise they are tractable. The logical place to begin is to measure the distance to an ideal DevOps environment for every future DevOps stakeholder, which potentially goes far beyond only development and operations teams. Then, outline the paths to your goals and the proper size of steps to take traversing those paths.
In assessing how far is the journey to your organization’s transformation, size is less important than the degree of current alignment between development, operations and any other team or business unit wishing to participate. Measure misalignment by examining the processes within each function and determining how well these mesh with one another. For instance, it is not untypical that the development team operates on a development lifecycle, such as agile, that clashes with IT’s strict and lengthy protocol for managing even small production changes.
Even in smaller companies, where the production team is a single person, the communication and process gulf can be wide. That single ops person may have created code and infrastructure that development is not even aware of, and which is certainly not synchronized with their release cycles.
As part of assessing the gaps, liaisons from each stakeholder should attend process meetings on the “other” side and initiate deep discussions seeking solutions to creating closer alignment. This step demands earnest attention from managers and executives in order to overcome potential drops in morale and to pitch in support when alignment means additional budget for the modernization of tools, infrastructure or training.
Tools or the Lack Thereof
Both the presence and maturity of provisioning, configuration and infrastructure management tools that could create a repeatable, scalable end-to-end continuous deployment process are typically lacking on the IT side. One consequence of this is departments rife with manual processes requiring highly specialized knowledge without shared responsibility for their creation or maintenance, which is anathema to DevOps.
On the other hand, production/deployment monitoring automation may be well-developed on the IT side, but development teams have no, partial or indirect access to such resources even though these tools could meaningfully enhance their own work or allow them to contribute and share responsibility on the production end.
While many available infrastructure management tools typically are not as advanced compared to other tools used by developers, almost any tool is better than manual, specialized, in-house script suites. Such tools for automating infrastructure allocation, provisioning and configuration are rapidly improving, however, so moving IT to a tools/automation track now is preparation for the long run.
Enterprises with large IT/Ops departments with long-established production processes have a significant challenge in melding Dev and Ops sides. That is not to say, however, that the Dev side does not have its fair share of oblique procedures and habits within their silo. Such situations respond well to incremental approaches to lowering process boundaries.
For instance, from a developer’s point of view, the complete setup and provisioning of a new development environment, both software and hardware, should take at most hours not days. They would like a completely self-serve model. Many IT departments are not capable of getting there in a single fell swoop however. In lieu of that, they could close the gap by moving to a services model with clear, simplified, fast-turnaround processes.
At some point, an optimized DevOps culture exhibits a high degree of time synchronicity across the entire development/production lifecycle. If development already practices an agile methodology, getting to that point places the greatest burden on IT to streamline and align processes to durations matching scrum cycles.
Regardless of the development process in place, however, the important point is that approval gates and their timing be examined on both sides. Diligent efforts must be made to bring those into alignment by adjusting their duration, frequency or acceptance criteria in order to eliminate bottlenecks and stalls.
Application Architecture Effects
There are two aspects of architecture to consider when moving to DevOps. One is the architecture of the software application itself, which can impact the ease of acquisition, building, configuring and testing individual components or the entire system. Ops may already have well-formed opinions in this regard that the Dev side would be wise to heed.
The other aspect is the degree of maintenance and support required from the Ops side to support production testing and deployment. A non-workable situation occurs, for instance, when scaling up an application produces a nonlinear increase in the amount of infrastructure needed or a decrease in performance due to shared resources such as databases or communication channels. Anything architecturally that developers can do to reduce costs and time on the Ops side will optimize and shorten the delivery process.
Often a relatively simple architectural restructuring or refactoring of individual components can make the job easier. However, in the absence of strongly aligned processes and increased communication that DevOps compels, these sorts of problems may otherwise lead to non-productive, grudging acceptance or finger-pointing when yet another deadline is missed.
Transitioning to DevOps Using Virtual Teams
When confronting operational challenges, be aware that attempting to leapfrog into DevOps may actually impede progress. This is especially true if focus is placed primarily on procedural aspects without considering the impacts on team interactions.
Based on Trinimbus’ experience working with clients making the move to DevOps, we strongly recommend the creation of virtual transformation teams composed of stakeholder representatives within the company plus our DevOps experts. Together, virtual team members drive the initial transition endowed with responsibility and authority for assessing, adapting and generating compatible processes.
A corollary to process tunnel vision is the temptation to simply assign or hire new people to oversee new processes or tools. This approach overlooks opportunities to cover functions via shared responsibility by multiple individuals or teams. Here again, a virtual team assisted by Trinimbus expertise has proven most effective and avoided inclinations to simply outsource DevOps, which often creates longer term negative effects.
Your organization’s gulf from the current status quo to DevOps may be narrow or wide enough that you have difficulty seeing the other side. While the latter case may require a larger dose of faith, both situations benefit from taking a long-term, incremental approach to DevOps implementation that is mindful of the multidimensional, interdependent challenges, both technical and cultural. Thankfully, the rewards outnumber the challenges through the creation of a more productive, collaborative, and customer-oriented software production capability.