With the continued growth and transition to microservices it’s important to ensure modern, cloud-based solutions are at the forefront of your organization’s goals. In this multi-part series, we’ll look at all the different components and considerations that must be taken when modernizing to microservices. 

In this blog, we’ll look at why it’s important to define an ownership model.

Define an Ownership Model and RACI for Microservices

Product team members have a shared responsibility to produce business value, no matter where they are from in a matrixed organization (BA, Dev, QA, support, etc). A product should belong to one team, but one team can also have multiple products. When developers from different teams update each other’s services, it blurs the lines of accountability and ownership. It’s challenging enough for a product team to share the responsibility for quality in what used to be a siloed approach; if contributions start to originate from different teams, it becomes very chaotic. You start having cross-team pull requests, different expectations on how to test, and, at worst, the added complexity of managing new issues found. Is it because of what that other team has done? Who is responsible for the quality, now?

Those decisions are typically made because a team has extra capacity, and program management is trying to shorten delivery time. In our opinion, the availability of that extra team should be used differently; paying down their own technical debt versus trying to add features in other teams’ microservices that are actively being modified by another team.

Previously, we looked at the importance of starting with the team. In part three, we’ll explore process management and production capacity.

Ready to modernize your organization’s microservices? Oteemo is a leader in cloud-native application development. Learn more: https://oteemo.com/cloud-native-application-development/