Service Ownership

Introduction

Every enterprise relying on highly granulated microservices-based applications greatly benefits from service ownership, a best practice that creates increased customer satisfaction, aligns teams and reduces incidents. In fact, even smaller organizations that use microservices are advised to adopt the “you build it, you run it” mentality.

And here’s why: Instead of decoupling the creators and the owners of an app, they remain the same team or person who sees the service through its entire lifecycle. This means that they also take full responsibility for its security, performance, quality, and reliability.

Once you achieve better accountability when it comes to your microservices, teams can maintain a much better level of reliability and software can be shipped quickly and effectively. This also means it’s much easier to outperform the competition in terms of market share, profitability, or any other metric that would matter to you and your business. 

However, service ownership is not a natural practice, especially in more traditional organizations that are still used to monolithic systems. In order to adopt the competitive structures that work in a microservice environment, it’s necessary to redesign existing teams so they can claim ownership and ultimately be closer to the customer.

Learn more about the significance of service ownership and how to provide better products and services by successfully transforming your company culture.

What is Service Ownership?

Service ownership, also known as the “code it, ship it, own it” philosophy, is based on the assumption that developers or developing teams who create a product or service remain responsible for its respective code and performance even after it is shipped.

There’s no doubt that regardless of the industry, companies are moving away from on-prem technologies and towards cloud environments and microservices that offer more flexibility, better scalability, and easier maintenance. What usually starts with a few coarse-grained services, quickly develops into services with high levels of granularity.

This is completely normal as the microservice architecture matures and services are being split up and adapted. After all, services are much easier to maintain and deploy when they’re on their smallest modular level.

Once you have achieved high service granularity, many applications tend to consist of multiple purpose-built microservices that are required to fulfill a single customer job. In case of an incident, it should be easy to reach the owner of the affected microservice who would be responsible for fixing the issue.

However, if there is no real service ownership, it’s difficult to address the problem as soon as possible. So naturally, redesigning the IT infrastructure of your company and integrating more and more microservices also requires redesigning its organizational structure.

If a company holds on to a centralized organizational structure, meaning IT teams in long-established silos and clear separation of duties, it loses out on the benefits that the microservice architecture can offer.

The centralization of IT operations is based on monolithic systems and emerged in the late 2000s and early 2010s when larger consolidated components initially seemed to save costs. But even back then, this rigid model slowed down performances, which is also why smaller and more nimble companies were able to disrupt big industry leaders.

Service ownership is a way to mitigate problems that arise in monolithic structures. That’s why a new mentality or cultural mindset needs to be adopted alongside new microservice technologies.

Note that even though microservice ownership assumes that a dedicated team feels responsible for the security, performance, quality, and reliability of service, the service code should still be open and accessible to the entire organization to support collaboration efforts. This ensures that other developers can jump in when the service owner isn’t available or has departed the company.

In the next section, learn about the responsibilities of service owners and the importance of service sponsors and service managers.

What is the role of a Service Owner?

The role of a service owner consists of managing one or more microservices throughout an entire lifecycle. Service owners are crucial in the development of service strategies and in charge of the entire service portfolio content, regardless of where the different technology components or capabilities are located.

A service owner’s job goes beyond technical fixes or service code maintenance, even though full knowledge of all technical service components is required. The role is comprised of various disciplines and can therefore be compared to the one of a General Manager – just for a particular service. A GM needs to have a sound “business plan” and understand and articulate the value of the service in terms of the business service delivered and how this value will change over time.

Service owners manage the service portfolio (catalog) and the risk of operating the service. In case of a major incident, they also serve as the point of escalation. And next to taking care of security measures, they also design a service roadmap, prioritize initiatives and keep an eye on innovation that could lower the cost structure of the respective service. It’s also vital for a service owner to have clear communication with stakeholders and align operational processes with overall business goals.

Some companies not only have service owners, but also service sponsors and service managers. Even though there might be some overlaps when it comes to their responsibilities, all three have their designated place within a microservice-based IT infrastructure. Service sponsors usually provide funding and resources needed to deliver the service. They also approve things like the risks or costs associated with the service and weigh in on the strategic direction of service before the service owner makes a decision.

A service manager can be regarded as a business relationship manager or process manager who manages the lifecycle of a service for business strategy development, vendor relations, costs, and all inventory related to the service. The service manager also conducts competitive benchmarking or market assessments and oversees internal supplier management efforts. Further responsibilities include the analysis of financial and customer metrics.

In the next section, find out how to successfully restructure your teams and how to create a service ownership mindset that will transform how your business operates.

Start at the team level

Enforcing a new company culture or mindset is a tall order and requires patience. After all, such a fundamental operational shift doesn’t just happen overnight. In fact, it’s a balancing act that poses a challenge to engineering leaders who need to get teams with competing incentives on board.

Since teams who work against each other are detrimental to a microservice ownership culture, it’s important to start directly at the team level. This means that you need to unite teams and make sure that their goals align. And if a team’s goal is not contributing to the overall business goal, it needs to be reframed.

But how can teams have competing goals, to begin with? When developing a new microservice, each team can have different incentives. While one team might be focusing on security issues, another team mainly cares about product innovations or new feature development.

Leadership can initiate a service ownership mindset by bringing these teams together through a shared, common goal. Ideally, this goal would be focusing on what’s best for the consumer as this will ultimately also be best for the company.

Plus, when one team owns a service, it becomes cross-functional and will be responsible for security, reliability, and implementation of new features.

Get the engineering managers involved

Once team goals are aligned, the next step requires getting your engineering managers on board. In this phase, make sure to recognize the importance of engineering managers as the success of service ownership depends on their cooperation.

In their leading role of reporting on service health at the executive level and being in charge of capacity planning and tracking business needs, they have to understand the advantages that a culture of service ownership brings to the table – and how they can actively promote it.

If done right, microservice ownership doesn’t threaten the role of engineering managers but helps them to ship high-quality service code as there is a shared sense of accountability for the delivery of more performant products. This increased sense of responsibility also leads to fewer points of failure and better damage control.

When service interruptions do occur, there’s no middleman as the developer who created the code can be called directly. Service engineers can help instill this culture and empower team members by giving them full responsibility.

Learn in the next section how to cultivate a service ownership mindset by applying two tried-and-tested methods.

Building a culture of Service Ownership

Since service ownership is a lived culture and not a tangible tool, it needs to build over time. However, there are ways to actively foster a shift in mentality, so teams thrive in an environment where they have more responsibility and where better services are being delivered to the customer. The two methods below are proven ways to initiate this change and get everyone on the same page.

Customer-first mentality

As mentioned before, service ownership can’t possibly develop if teams have opposing goals. And the best way to align them is to establish a common goal like focusing on the customer’s needs. Of course, a customer-first approach not only unifies teams, but also leads to satisfied customers, more growth, and profits. To support a culture of service ownership, you can use SLOs (service-level objectives) for aligning metrics with incentives.

Celebrate failure and courage

Taking accountability and responsibility for anything can be frightening. That’s why developers might resist the idea that they’ll be the first point of call if their service code breaks. That’s why leadership has to create a psychologically safe environment for all team members. Nobody should be worried about losing their job or making a mistake. On the contrary, with service ownership, there should be a common consensus that mistakes are a learning opportunity and improve products.

Conclusion

In recent years, microservice ownership has become a best practice as microservices with high levels of granularity add complexity to any IT architecture. This is because redesigning monolithic web applications into smaller, more agile components is only one side of the coin.

In order to reap the full benefits of lighter and more agile applications, redesigning centralized IT teams and turning them into cross-functional service owners is just as important.

However, achieving a shift in mentality and fostering a true service ownership culture takes time and effort. You have to start at the team level, involve all leaders including engineering managers and define shared goals that focus on the customer. And last but not least, you need to create a safe environment that celebrates failure and rewards courage.