Delivering application experiences to the masses has been a rocky journey for Enterprises not born of the Internet age. Even those started early this century struggle with software delivery because their delivery models were based on the models born from a prior age. Now that companies are directly interacting with customers via software 24/7, it is imperative that the application delivery teams re-align their incentives for success.
What gets measured, gets…stuck
I discussed wind up top monitoring – wherein early system administrators of batch applications felt the best way to do their job was to provide a resource pool and get out of the way. Providing computing resources at Enterprise scale at the dawn of computing was extremely hard. Keeping up with computing demands was challenging and pushed system administration specialization, and naturally, a division arose. Providing computing resources was the administration team’s responsibility and creating applications was the application team’s responsibility.
This silo between systems and application teams became reality for every medium and large company. Armies of IT administrators’ primary incentive was to provide “working” compute resources in data centers around the world. The representative metrics for “working” were network connectivity and machine uptime; two metrics in the purview of Infrastructure Monitoring.
Measuring and evaluating yourself on those two specific measuring sticks drives two specific behaviors. One, you become hypersensitive to letting anyone have access to your systems and networks, throwing up roadblocks either technically or politically. Two, after everything was set up and working, you would abhor changing anything. Change introduces variability, and variability inevitably translates into fluctuations in your key connectivity and uptime metrics.
When all the keys to computing resources are provided by teams that prevent access and actively resist change, the folks creating applications are in an awkward place. As the Internet age evolved, these application teams were driven more and more by emerging competition from all sides. Reacting and enacting became the name of the game, and the application team’s incentives banked on measuring the number of features, fixes, and widgets added.
These two incentive systems are clearly not aligned. Instead of working together, the operations team and application teams ended up pitted against one another. Stability vs. change –and when issues inevitably arose, there was more finger pointing than problem-solving.
Moving the lines
Three important industry shifts have changed the narrative of this battle. One, the Cloud emerged and transformed the expectation of computing resources from one of scarcity to available-on-demand. Two, virtualization, and ultimately containerization, abstracted the app away from the infrastructure. Three, successful businesses recognized that the only thing that matters for software delivery is their customer’s perception of interacting with it.
The last point is the lynchpin in this incentives transformation. Success must focus on the work done on behalf of the consumer. When the metric of success changes to customer experience, it’s no longer one group of folks providing computing and another group writing applications. This unifying metric focuses on customer satisfaction and site reliability, forging the collective will of the organization into an effective devOps team.
Are you part of a team keeping applications running in a customer-focused devOps environment? Drop me a DM on twitter @NateIsley or leave a comment below – we’d love to interview you as we flesh out our MVP!