I’ve had the unique opportunity over the last 30+ years to be involved in multiple large, enterprisewide, mission critical application development projects. I’ve also had the opportunity to develop and bring several products to market. In looking back at these projects, the common thread in the successful ones (yes, some were not successful) was the ability to respond quickly and effectively to the changing needs of the end user. Whether these were because of vague or misunderstood requirements, a changing technology landscape or competitive pressures, the ability to react quickly and change directions without regressing the end product was a critical factor in their success.
Getting these projects and organizations into an agile posture and reactive, adaptive position was not without its trials and tribulations. In every case, we had our share of setbacks and missteps along the way. And as more and more organizations embark on their journey to DevOps, each of them will undoubtedly encounter some of these same challenges.
I would like to share these past experiences and observations, both the success and particularly the failures with others so they can benefit and avoid these pitfalls and hopefully smooth out their road to a successful adoption of DevOps.
I wrote an article several months ago titled “Including Ops on the Journey to the Cloud,” highlighting how the operations function in IT organizations has not embraced the DevOps movement with the same enthusiasm as developers, testers, product managers and end users.
The feedback on the article from the editors and colleagues was pretty consistent. Yes, you’ve identified the issue and made a good argument to fix the problem. But you left the elephant in the parlor. You didn’t come up with reasons why Ops should embrace this DevOps movement—which appears to bring nothing but upheaval and change to their world. What’s in it for them and how do we get Ops engaged and contributing in this brave, new DevOps world?
Let’s look at some simple, straightforward measures management can take to alleviate this fear and uncertainty and help Ops make sense of moving to the cloud and better understand where they fit into the service delivery model of DevOps.
First is the development of a solid message from senior management on where the organization is going and why. Management needs to articulate its road map and how moving to this new platform 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 are a priority. These sporadic declarations from management tend to fall upon preoccupied and overwhelmed ears.
In this case, if management wants operations to understand the “what” and “why” of moving to the cloud 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 operations 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 an infrastructure-as-a-service platform, 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 the 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 now fully participate as a member of the team that delivers services to the end user. They can help guide how these services and applications are architected and how they can most effectively 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.
Operations 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.
So as a release candidate migrates into a pre-production environment, 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 and be reevaluated in order to stay relevant. The days of pulling cables, maintaining HVAC and power along with procuring hardware, software and networking is largely a thing of the past.
In the early days of electricity, neighborhoods had their own utility generation and distribution plant—located and maintained right in the neighborhood. It quickly became apparent incredible economies of scale could be realized by having electricity provided by a general distribution plant, thereby offloading the responsibilities and costs of day-to-day operations. Homes could then tap into their electrical plants and pay for what they needed when they needed.
IaaS and cloud computing platforms are the utility plants of computing. They’re not going away. In fact, they’re going to be the rule rather than the exception. 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 the cloud and DevOps, don’t overlook the value Ops add to your organization’s journey. Too often, management forgets the rank and file is heads down executing on day-to-day tasks and often miss critical management messages and vision statements.
While management may fully understand these visions, it should assume others do not and consistency and routinely emphasize and reinforce them. This is particularly important when it’s not obvious, as in the case with Ops, what the future holds for them. Be cognizant of the fear and uncertainty in their situation, and take the time to spell out their new role and the value they can bring to the organization.
This is the fifth column in a series. Read the previous ones here.