I recently wrote about how the craft of Operations is changing, but is far from being in decline. In an ensuing twitter conversation, Charles T. Betz brought up some excellent points about the need to be precise when unpacking what Operations does.
Charles, the author of the excellent book "Managing Digital: Concepts and Practices," provides a simple yet helpful framework:
First, you'll notice that everything has a Development phase and an Operations phase (the columns). Next, what is being worked on is divided between infrastructure and application (the rows). It doesn't hurt that I've been a fan of using a quadrant design to think about IT activity for a long time.
In his book, Charles also provides a useful definition of what is considered "applications" and what is considered "infrastructure." He bases it on who the consumer is:
- Applications are consumed by people who are NOT primarily concerned with IT
- Infrastructure is consumed by people who ARE primarily concerned with IT
I interpret these definitions as meaning that everything that is leveraged by application developers (those who build applications for end users/customers) to deliver services to end users is "infrastructure" (platforms, environments, networks, tools, etc.).
Charles breaks down what a traditional Operations organization does into two parts: Infrastructure Engineering activity and Operations activity.
(Note: all red annotations on the following images were made by me)
If you look at where companies are going today, Application and Infrastructure Engineering activity is blending. The technologies are starting to look the same, and the trend is for everything to be in code (yes, config is code too) managed through a software development lifecycle (SDLC).
However, the Development phase and the Operations phase are remaining distinct. This makes sense as build (primarily planned work) and run (primarily unplanned work) are fundamentally unique types of activities.
What Does This Mean for Org Design?
To be clear, to this point I've only been talking about the activity. If you want to discuss who does what, then it is far more up for grabs.
Some organizations split themselves into a series of cross-functional product-aligned teams.
For some organizations, traditional boundaries remain. However, Dev and Ops collaborate via a shared responsibility for operations activity (a practice popularized by the SRE movement).
Others are splitting out Infrastructure Engineering into its own cloud-native platform development organization.
How the operations work is being divided up is has become company specific. Rather than thinking there is only one correct way, organizations are doing what they should have been doing all along. Namely, moving the operations activity to the part of the organization where it makes the most sense. And unlike monolithic organizations of the past, we are seeing multiple models co-existing successfully within the same company.
Operations As a Service Enables Ops Activity to Be Distributed
This redistribution of operations activity is of interest to us here at Rundeck because in almost every case there is a sharp increase in the need for self-service. Whether you have cross-functional product-aligned teams or a traditional Dev and Ops divide, your organization can't keep up with the business demand to move quicker if all operations activity needs to first sit in a ticket-driven request queue!
The Operations as a Service design pattern we have been documenting was born from this need. Operations as a Service provides the ability to distribute operations activity to where it maximizes flow and decreases costs (often that means safely delegating control to people outside the boundaries of traditional Operations teams).