A key requirement in transitioning to a successful DevOps posture is the formation of cross-functional, multi-dimensional teams bringing together members from development, testing, users, architecture, UI/UX and operations — among others.
For the most part, these disciplines have embraced their roles and participation in these new teams. However, one discipline, operations or Ops, has been particularly reluctant to embrace DevOps and their new role.
This reluctance is understandable considering that a key objective of DevOps and Agile practices is to increase deployment velocity, which results in a more dynamic, kinetic production environment. And a rapidly changing production environment seems to be contrary to what Ops is primarily tasked with — maintaining a stable, reliable, highly available environment on which the application stack can reliably operate.
But if we are going to adopt a true DevOps posture and make it successful, we need the full and enthusiastic participation by Ops.
So, let’s look at some simple, straightforward measures management can take to alleviate their fears and uncertainty and help Ops better understand where they fit into and benefit from the service delivery model of DevOps.
First is the development of a message from senior management on where the organization is going and why concerning DevOps. Management needs to articulate its road map and how moving to this new approach fits into this vision. This should include the economic and technical benefits the organization expects from taking this direction as well as anticipated changes in the organization and Ops’ role in that new structure.
The message needs to be clear, concise and convincing. Only then can management roll out the message to the rank and file and expect them to both understand and support it.
Second, it's critical to communicate this message often and consistently to the rank and file. Too often, management assumes the rank and file has the bandwidth to take in the numerous strategic directives that come down from management. Management tends to forget about daily responsibilities that remain the top priority. These sporadic declarations from management tend to fall upon preoccupied and overwhelmed ears.
In this case, if management wants Ops to understand the “what” and “why” of moving to a DevOps posture and the importance of Ops participating, then the message should be communicated regularly. This consistent cadence of information not only reinforces the message but emphasizes to Ops their importance to management and the organization. Only after understanding the why and what can Ops begin to connect the dots between their daily tasks and this strategic initiative.
Third, management needs to identify the new role for Ops in the delivery process. As an organization transitions to a DevOps posture and the cloud, Ops will be increasingly relieved of the daily maintenance and support of the infrastructure and underlying platform.
No longer does Ops need to be pulling cables, ensuring power, maintaining HVAC, procuring H/W and S/W and the numerous tasks associated with maintaining your own infrastructure. Liberated from these tasks, Ops now can move up the food chain and offer a higher-value proposition to the organization. Ops can fully participate as a member of the team, helping guide how these services and applications are architected and how they can best integrate into the current production environment.
Fourth, management needs to articulate the value Ops brings to this new role. Experience in the operational environment and understanding how applications really work (or don’t) is invaluable in the design and development of any new application added to the current application mix.
Unless you’ve been in this environment on a day-to-day basis, it’s difficult to appreciate and understand the problems and challenges the current application portfolio presents. Making Ops a first-class participant and a required member of the service delivery teams begins to move the organization closer to a true DevOps posture, with multidimensional teams focused on the delivery of service.
Ops can provide early guidance to the design and architecture choices in light of the current platform as well as the knowledge and know-how in what's required to deploy and maintain an application in a production environment. And while Ops may play a more advisory role in the early phases of the delivery pipeline, this role will shift to a leadership and governance role in later phases.
As a release candidate migrates into higher environments, those members on the service delivery team with strong Ops background and skills will assume a more front-and-center, hands-on role, with developers assuming a supporting role. This allows for the leveraging of strong Ops skills in the right environment as well as the cross-pollination of skills within the team.
Fifth, the fact of the matter is the world is changing and Ops’ role needs to change with it. The days of pulling cables, maintaining HVAC and power along with procuring hardware, software and networking is largely a thing of the past. Ops need to learn to adapt or risk being replaced by others who will and learn to provide value in this new role.
Remember, as you move forward into the brave, new world of DevOps, don’t overlook the value Ops adds to your organization’s journey. Too often, management forgets the rank and file is heads down executing on day-to-day tasks and many times misses critical management messages and vision statements.
And while management may fully understand its vision, it needs to assume that others do not and consistently and routinely emphasize and reinforce it. This is particularly important when roles and benefits are not obvious and, as in the case with Ops, what the future holds for them. Be cognizant of the concern and uncertainty in their situation and take the time to spell out their new role and the value they can bring to the organization.
