Years ago, end-to-end software development involved dividing tasks based on where they fell in the system life cycle. One team wrote the code. Then another team deployed it to production. And yet another team monitored and maintained the service. This led to a lot of friction, needless handoffs, and bottlenecks.
Then DevOps came to the rescue, promising to reduce handoffs and improve operations. But without the missing ingredient of service ownership, DevOps won’t be as powerful as it could be.
Now what does it mean to own a service? And how can we support this organizational pattern within our teams? While sharing ideas on how to take back DevOps, we talked a bit about service ownership. As a follow-up, we’ll now dive deeper into service ownership and how we can spread it across our teams.
Service ownership means that a team holistically owns its services and the service lifecycle.
Service ownership means that a team holistically owns its services and the service lifecycle. That team will build, ship, and operate the service, ensuring that they have both autonomy and accountability for their product.
For some, that may seem like a lot for a team to handle. However, given the right tools and expectations, it can set your teams free to reach their full potential.
But why would teams and organizations take this route?
To begin, let's go back to the model mentioned in the intro where different teams were responsible for building, deploying, and operating a service.
Again, these silos led to friction, handoffs, and bottlenecks. The service ownership approach drives better reliability, improved operations, and more frequent releases.
First, let's consider the friction developed between development and ops teams. Development teams want to ship features quickly, while operations teams wanted to slow the rate of change to production.
Why do ops folks want to slow things down? Typically, more change means more bugs, more incidents, and more maintenance. And without any influence on the development process, this becomes the only route they have.
However, if we take a service ownership stance, the same team that builds the features also deploys and operates the application. They can easily feel the effects of their deployments on the stability of the product. And they then make decisions as to how to deploy, when to deploy, and how to prevent, identify, and fix issues.
Many teams not responsible for operations push observability and monitoring concerns to the back burner. Also, engineers that don't have to debug issues in production don't always make their code easy to debug. They weren't the ones investigating issues at 3 am when a page went off.
On the other side, the operations folks who could really use improved troubleshooting capabilities didn't have the autonomy to improve things themselves.
So how does service ownership help? Service ownership takes the responsibility of building, shipping, and operating a service and combines it into one team's responsibility. One team holds the responsibility for the whole product and not just a piece of the pipeline.
Perhaps you've heard the phrase "build it, ship it, run it." That's the two-second description of DevOps and service ownership. To expand on that, let's break those components down.
The phrase "build it" seems simple enough. Our engineering teams all build software. Does this look the same for teams that have service ownership and those that don't?
Not necessarily. When a team utilizes service ownership, they also gain autonomy and influence over how to build their product.
In fact, when teams own the whole service, you'll find that they appreciate the value of building services with improved quality, appropriate documentation, thorough tests, and observability practices more than when separate teams operate or run the services.
Teams are encouraged to drive better development practices because they can see the results of those practices in production.
Next, when a team owns a service, they own the responsibility of shipping it to production.
This doesn't mean that every team needs a CI/CD guru, with every team re-creating the basics of continuous deployment and automated compliance checks. It could be that the team uses common frameworks, patterns, and libraries provided by others.
However, the team does own the responsibility of getting code in production efficiently. They should also understand the pipelines and fix things when they go wrong. Overall, the goal is not to throw problems over the wall at the release management team but to take ownership of shipping the product to production.
Here, the team that writes the service is also the team that's best equipped to run the service. They know how to resolve issues quickly and make changes that will prevent similar future issues.
When we run our own applications, we also realize the importance of operationalizing the product. So we'll write code in a way that makes it more maintainable, observable, and debuggable. Because we'll be the ones who have to fix it when it breaks.
Here, the team that writes the service is also the team that's best equipped to run the service.
Now that we've talked about how teams will build, ship, and run their service, let's talk a little bit about where that will get us.
You may have noticed that a lot of DevOps concepts sound similar to service ownership. Both combine software development and operations. That's not a coincidence. Overall, service ownership can be seen as the next evolution of DevOps. When teams have clearly defined ownership boundaries, expectations, and autonomy, they can further their DevOps journey.
Service ownership encourages the full ownership of the lifecycle so that teams can work on what matters most to drive their success.
Next, what first steps can you take toward driving service ownership in your organization? In short, we need to move away from telling teams what to do or how to do it and move toward looking at outcomes necessary for customer satisfaction. Furthermore, when multiple teams contribute to an initiative, we need to point them all toward the same outcome. Then we must encourage them to collaborate and work through integrations and dependencies together, always pointing toward the same goal.
When thinking about the implementation of service ownership, we need to consider three facets.
Let's look at each of those separately.
To drive service ownership culture, share expectations around service ownership clearly. Talk about where you see the organization is at today and what you’re working toward. And mention the benefits that not only the customer or organization receives, but also the benefits that the development teams should expect regarding reduced bottlenecks and autonomy. Then ask for feedback and help in getting there.
The expectations must also include autonomy and accountability for the teams. Teams have the autonomy to build the product or service and the accountability for the outcomes and reliability of the service.
But autonomy and accountability require more than lip service. If you tell teams they're accountable but then feed tasks into their backlog, you've probably given the team accountability without autonomy. Therefore, to drive service ownership, the team should focus on a product-related target or outcome. And they own how to get there.
When we talk about teams deploying their own code to production, we don't mean that every team implements its own CI/CD processes (along with the tools) from scratch. Instead, it means that they need the ability to deploy their code when they want and where they want.
In this model, all approvals, auditing, and governance should be covered by either someone that is part of the team or, better yet, through automation. Additionally, all services should establish service-level objectives and service expectations.
For development and operations, processes that drive operational excellence must be included in the way the team works. But how they drive operational excellence may vary from team to team.
For some organizations, this will mean incorporating feature flags or modifying the PR review process. For others, it may mean relying more heavily on pair programming and increasing automated tests.
Without proper tools, organizations may rely on word of mouth, team knowledge, or team-specific methods of identifying service owners.
Without proper tools, organizations may rely on word of mouth, team knowledge, or team-specific methods of identifying service owners. Oftentimes disparate spreadsheets and wikis hold out-of-date information that's difficult to find. And tools often don't integrate well together. Folks have to go to various places to get the information they need to integrate with a service.
Therefore, the most critical tools in service ownership provide centralized visibility. Visibility not only of the ownership of a service, but the visibility of that service's SLAs, monitoring, escalation points, quality metrics, documentation, and more.
All teams should have one place to go.
Preferably these tools integrate with all your existing DevOps tools like your CI/CD, monitoring, and analysis tools. Ideally, the tools integrate with the entire mircoservice lifecycle.
Overall, to reduce the complexity, provide teams with one central and easy-to-use place to get the information they need. For this common problem, OpsLevel can help provide visibility through their service catalog.
Service ownership provides many benefits through increased autonomy and accountability, like encouraging teams to incorporate operational excellence early in the life cycle. Additionally, it gives the team autonomy to do the right thing and satisfy customer needs based on their knowledge and expertise.
To make service ownership easy to see, consider OpsLevel and how you can improve visibility and expectations. Request a demo to see how OpsLevel can drive ownership today.
