Devops, a term coined to describe the expanding reach of developers into areas typically considered operations tasks, is still viewed as a trend impacting early adopter enterprises – but for how long? What can you do to prepare what should you look for in technology that enables the devops model?
The developer land grab that is devops
The desire to release new functionality faster to end users is high on every developer’s wish list. However, most enterprises have multiple layers of processes, assigned to separate roles, which often increase the time between a new feature being developed and made available to users. However, most IT managers would agree that these processes and separation of roles were instituted to increase the quality and uptime of IT environments, and ultimately the quality of the end user experience.
The growing access to automated, self service, provisioning of IT resources and environments is enabling developers to flatten the roles, if not processes, between a developer and the end user.
RedMonk’s Michael Cote suggests that devops can be viewed as a land grab by developers. Cote writes, “after ejecting every function except writing code, development teams have been bringing those roles back to the core team, starting with QA, then product management, and now operations.”
Not surprisingly, devops is taking hold primarily in startups or smaller companies where the separation of developer versus operations roles is ill-defined by necessity.
The changing role of operations in a devops world
In larger enterprises with established separation of roles between developers and operations teams, the devops term may in fact be counter productive. It can suggest that as developers undertake tasks previously owned by the operations team, operations staff become less critical to the IT organization.
In fact, the reality underlying devops is far from that mistaken belief. Cote describes the changing role of operations staff in a cloud-driven devops world:
Rather, it means that as with QA and product management, their role moves from “keeping the lights green” to “delivering good, productive experiences.” Operations becomes one of the product owners, not just the “monkeys” who hook up wires to servers and increase disk-space.
The451 Group’s Jay Lyman shares a similar view in his research on devops, concluding:
However, in the larger picture and in the long run, particularly at greater scale, there is undoubtedly need for system administrators. One of the bottom line findings of my research on devops is that the trend is very much about a dramatically changed purpose and role for system administrators, who are typically freed up of mundane OS maintenance and other tasks, but who must also embrace openness and transparency in their operations and scripts, which can be very foreign.
Far from developers replacing operations staff, and thereby accepting some of the manual tasks required to keep an environment up and running, new cloud technology removes the need for these manual, and at times mundane, tasks in the first place. As these tasks are removed, operations teams are able to better contribute to the value that their business and end users perceive to be coming from IT.
Transitioning towards a devops model
Much of the transition required by the devops model involves changes to organizational design, processes and a revised definition of roles. These types of transitions can be lengthy in duration and often face resistance initially.
It is for exactly this reason that vendors must offer both an evolutionary and revolutionary option in their cloud and PaaS offerings targeted at enterprises.
An evolutionary approach is required to help IT organizations gain value while they transition to tomorrow’s more responsive and productive IT organization. Without this evolutionary step, the desire to protect one’s sphere of influence in the overall IT process will encourage IT staff to resist change before they can see the benefit of a cloud-enabled devops model.
A revolutionary approach also needs to be delivered in the same cloud-focused tool or product. This choice enables enterprises to shift gears between evolution and revolution in their IT processes without having to acquire separate products with separate skills requirements. More importantly, this choice allows enterprises to shift between evolution and revolution in their IT processes at their own rate and pace.
VMware’s open source-based Cloud Foundry beta and IBM’s Workload Deployer are two PaaS offering that attack the devops opportunity from two ends of the spectrum.
VMware’s beta offering appears targeted at enterprises ready for revolution, with a developer in control of the overall development to deployment process. It’s too early to tell if this is by design, or simply didn’t make it into the developer targeted marketing surrounding the beta. Knowing VMware’s long history with enterprises, one would expect VMware to address the spectrum of stakeholders whose roles are impacted by cloud and PaaS in a devops model.
IBM’s offering assumes that enterprises want to select between both evolution and revolution in their IT processes on a project by project basis while. This choice enables IT organizations to secure buy in from IT employees after proving out the benefits of more closely aligned developer and operations functions in a given project.
Preparing for a devops future
Like any major change in processes or role definition, IT decision makers need to allocate sufficient time for the shift to occur.
Successful transitions will most likely occur if there are proof points, relevant not only to the business, but to developers and operations staff, from a handful of smaller projects. Selecting projects, developers and operations staff that would be best suited for a new way of doing things would be a good fist step.
Additionally, determine the degree to which your IT organization can accept the revolutionary changes to roles and processes as codified by the cloud and PaaS tools you consider. Select your cloud and PaaS tools based on your organization’s unique needs.
Whatever you do, starting to think about devops models sooner rather than later, is the right approach for building tomorrow’s IT department.