Architecting for Scale, 2nd Edition

Chapter 6. Service Ownership—STOSA

In Chapter 3, we discussed what a service was and how it could be utilized to help take the complexity of an application and divide it among many different development teams, each working on its own code base and supporting its own services. We discussed how to size services and how services should interact.

But we didn’t delve deeply into the specifics of what it meant for a team to “own” a service, and why this ownership is important. In this chapter, we will explain what is meant by service ownership, and what is necessary for a Single Team Owned Service Architecture to work.

Single Team Owned Service Architecture

What is Single Team Owned Service Architecture (STOSA)? STOSA is an important guiding principle for large organizations that have many development teams that own and manage services comprising one or more applications.

What does it mean to have a STOSA application and organization? To be STOSA, you must meet the following criteria:

• You must have an application that is constructed with a service-based architecture.

• There must be multiple development teams responsible for building and maintaining the application.

• Each and every service in your application must be assigned to a development team, who owns that service. Who owns which service should be well documented and readily available to everyone in the organization.

• No service should be assigned to more than one development team.

• Individual development teams may own more ...