Skip to content

June 16, 2020

Guidance for Becoming a Modern Ops Professional

By IT Revolution

Adapted from the DevOps Enterprise Forum Guidance Paper Modernizing IT Operations in the Age of DevOps by Josh Atwell, Jason Cox, Damon Edwards, Ron Forrester, Jayne Groll, Mark Imbriaco, Mark Schwartz, and Scott Willson.

DevOps adoption continues to rise as enterprises migrate to the cloud as part of their digital transformation initiatives. The combination of DevOps and cloud infrastructure is disrupting the traditional job expectations of enterprise infrastructure and operations (I&O) professionals. Expectations for I&O professionals used to involve “rack-and-stack” provisioning of servers; executing batch scripts; responding to and closing tickets in ticketing systems; and monitoring the status of any number of tasks, systems, jobs, or environments. Now, however, I&O professionals are being asked to do things outside of their comfort zone. This is being driven by not only management or business leaders, but also the acceleration of DevOps, continuous delivery practices, and the migration of compute workloads to cloud computing infrastructures.

This paper is intended to offer guidance for I&O professionals so they can evolve their skill set and become an integral part of DevOps initiatives and competent in cloud infrastructure code. Indeed, it is the view of these authors that the expertise of I&O professionals is needed in DevOps processes. DevOps is not synonymous with DevNoOps. Though the expertise of I&O professionals is necessary and important to DevOps initiatives, the way this expertise is deployed and used may be different than what has traditionally been the case. I&O professionals may need to learn to be comfortable working as part of a line of business or product-focused team rather than a centralized, isolated, interrupt-driven department.

Guidance 1: Change of Perspective

The first step to prepare yourself for these inevitable changes is to recognize that in order to deliver the new expectations we must first change how we view what we deliver; we must change our mindset. It is no longer sufficient to simply keep the lights on. That mentality is why most IT professionals and their departments are seen as a cost center to the business. Instead, your perspective on IT needs to be that it is an engine for innovation and business value. This is what the business wants from IT, and it should be what we want as well.

Being mindful to how we respond to projects and user needs will help change the view of consumers that IT is the department of no. That view is typically well founded, as IT organizations regularly say no for a wide range of valid reasons. (The adoption of cloud, including “shadow IT,” is frequently a direct result of not being able to get required resources in a timely manner.) Instead, IT needs to become more inquisitive and interested in the needs of the business and the challenges being solved. By asking pointed questions and utilizing a consultative approach to your work, you have more opportunities to share your expertise in more valuable ways, as well as identify other potential solutions to the challenges your users are trying to solve. You can move from a “No” response to a “Yes, and…” response.

Changing the way we measure IT is a critical component to drive behavioral change. We should not eliminate MTBF and MTTR from our measurements. Those items continue to be important. Instead, they should be de-emphasized slightly with a greater focus on measurements like time to delivery.

We must also make changes in how we set expectations. We’ll go into this in much more detail in Guidance 3, but for the time being, it is important to recognize that these changes will need to become core to how you prioritize work and interact with the developers, application owners, and other consumers.

Guidance 2: Develop a Code-First Mentality

Given that cloud resources are provisioned and de-provisioned by automated software systems, it follows that software code is the language used to interact with these systems. Most current I&O professionals are comfortable with shell scripts and interacting with a CLI. The problem is that continuous delivery practices, the short cyclical life span of cloud resources, and the scope of cloud environments makes manual or semi-manual Operations efforts inefficient, and Ops quickly becomes a bottleneck.

A development best practice is to tag, track, and test any code changes. In the past, this was virtually impossible to do with infrastructure changes, but the cloud changes this. For the first time, app environment changes can be tagged, tracked, and tested/vetted alongside the apps they host and support. The development practice of using version control systems such as git or GitHub is a skill that I&O professionals will need to acquire.

Remember, rather than logging in and making changes in an ad hoc manner, your changes ought to be edited in code, checked into a version control system, and pushed into your delivery pipeline, where these changes can be tested alongside everyone else’s. It’s not as important that you deliver something correctly once. It is most important that you repeatedly deliver small changes iteratively.

It should be noted that a code-first mentality is not limited to traditional programming languages. PaaS and IaaS, for example, make heavy use of JSON and other DSLs to describe, provision, and maintain many aspects of a cloud application footprint. Learning to code as a first step might start with familiarization with JSON, YAML, XML, and so on. Simultaneous to that, becoming a familiar consumer of an API via REST calls through a client like PAW, utilizing the new knowledge of JSON (for example), is an excellent next step.

Guidance 3: Be a Product and Service Delivery Professional

The accelerating move from traditional infrastructure to platforms and cloud services means that many of the traditional roles of IT are decreasing in relevance. Much like the move to software as a service (SaaS) products, this shift causes executives to reconsider their IT investments and increasingly seek to invest in areas that provide business differentiation. Modern business operations view IT as a series of products that must deliver differentiated value to the organization in order to thrive.

It seems daunting at first to reframe Operations in terms of providing a product, because this shift in thinking makes it clear that you are competing with external products for customers. Rather than being a negative, consider this tension to be a positive aspect of this product focus that motivates you to consider whether your product is providing a solution that is a better choice than competing options. If you aren’t able to make a case for using your product over external solutions, that’s a strong indicator that you should reconsider your approach to that product.

The good news is that you have some very strong home field advantages that your competitors do not. You’re very close to your customers, so things like gathering product feedback, providing education and user support, and even marketing your product are much cheaper and have much shorter feedback loops, giving you an opportunity to iterate quickly to meet the needs of your customers. You are able to design your product offerings in a way that uniquely addresses the specific needs of your organization in ways that would be edge cases if you were an external provider.

It is important to note that you are always in competition with external service offerings (e.g., AWS) and you must, therefore, ensure that you are presenting your services in the same modular, easy-to-consume way that those providers offer.

Guidance 4: Guidance for Leaders

No shift, whether cultural or technological, can take place without the support and involvement of an organization’s leadership. The role of many technology leaders is to prepare their teams for significant change occurring either locally within the teams and organization or externally through industry initiatives and best practices.

It’s important for the leader to keep in mind that the people on their teams have a real emotional connection to the work they do. Indeed, they often self-identify with that work. When a disruptive change results in the redefinition of that work, it is no longer a simple case of training or re-education. Team members need to find purpose in the work they do as they master it.

As a leader seeks to enable a transition into a DevOps model, they first need to become familiar with the specifics of DevOps (the guidance in this paper and the resources included in the reference section can help). Next, have a series of conversations with the impacted roles and teams about a thoughtful plan to train people into the new technologies and processes associated with DevOps. Again, it’s important in this work that the leader keep in mind that this is not just an educational transformation; it’s a personal, emotional, and cultural change, and teams need to feel like they have ownership of the process rather than feel like victims of it. Look for ways to align past passion with future work and responsibility.

A leader seeking to shift to a DevOps model should also work to decompose the work into tasks and goals that are attainable by the teams given their current workload. It’s imperative that the steps teams take toward DevOps not only clearly benefit from their involvement but also can be seen as something they can succeed at. The initial disposition of some may be to show that this new methodology will (and should) fail. This is a natural reaction to large-scale change and should be anticipated.

Conclusion

Traditional enterprise IT professionals can be nervous about the evaporation of physical infrastructure and the technology shifts to software, cloud, containerization, and serverless infrastructure. However, as has been discussed in this paper, there is hope! This new paradigm does not need to be a path to extinction. Instead, it should be seen as an opportunity for evolution. Business leaders and IT Operations teams should recognize this pivotal moment of change, embrace the opportunity, and lean in to the new, more integrated organizational models. They must become the champions of the revolution and help their fellow technologists embrace the tools, platforms, and new operational models that will help propel their organizations into the future.

Download the full DevOps Enterprise Forum Guidance Paper Modernizing IT Operations in the Age of DevOps.

- About The Authors
Avatar photo

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT on Social Media

No comments found

Leave a Comment

Your email address will not be published.



Jump to Section

    More Like This

    Serverless Myths
    By David Anderson , Michael O’Reilly , Mark McCann

    The term “serverless myths” could also be “modern cloud myths.” The myths highlighted here…

    What is the Modern Cloud/Serverless?
    By David Anderson , Michael O’Reilly , Mark McCann

    What is the Modern Cloud? What is Serverless? This post, adapted from The Value…

    Using Wardley Mapping with the Value Flywheel
    By David Anderson , Michael O’Reilly , Mark McCann

    Now that we have our flywheel turning (see our posts What is the Value…

    12 Key Tenets of the Value Flywheel Effect
    By David Anderson , Michael O’Reilly , Mark McCann

    Now that you've learned about what the Value Flywheel Effect is, let's look at…