Single Team Owned Service Architecture (STOSA) is a guiding principle for large organizations that have many development teams that build and own microservices to cater to one or more enterprise-wide application(s).
A Microservice must be owned and maintained by a single development team within your organization. To be a true STOSA based team/organization, you must meet the following criteria:
- Have application(s) which is/are developed using a Service (monolith/microservice) architecture.
- Have multiple development teams that are responsible for developing and supporting the application.
- Each service should be assigned to only one development team.
- A development team may own more than one service.
- Teams are responsible for all aspects of managing the service, from service architecture and design, through development, testing, deployment, monitoring, and incident resolution.
Typically, a STOSA-based organization follows the above-mentioned criteria and each service team is of a reasonable size (typically three to seven developers also known as a two-pizza team). If a team is too small, it cannot manage a service effectively. If it’s too large, it becomes cumbersome to manage the team.
Non-STOSA-based organization
The above-shown image represents a non-STOSA organization, and you’ll notice a couple of things. First, Service "Shipping" does not have an owner. Yet, services such as Order and Billing are owned and maintained by more than one team (Team1, Team2, and Team3). There is no clear ownership. If you need something done in Order and/or Billing service, it’s not clear which team is responsible. If one of those services has a problem, who responds? Who do you contact for Shipping service? This lack of clear ownership and responsibility makes managing a complex application even more complicated.
STOSA based organization
The ovals represent development teams that own the enclosed services, for example, Team1 owns Payment, and team4 owns Shipping and Address. All the 6 services are managed by four teams. You’ll notice that each service is managed by a single team, but several teams may manage more than one service, for example, Team3 and Team4. The main point is that every service has an owner, and no service has more than one owner. Clear ownership for every aspect of the application exists. For any part of the application, you can clearly determine who is responsible and who to contact for concerns, clarifications, questions, issues, or even changes.
Advantages of a STOSA Application and Organization
Clear and definitive ownership of a service is the key to the success of any application or the organization. As applications grow, they grow in complexity. A STOSA-based application can grow larger and be managed by a larger development team than a non-STOSA based application. As such, it can scale much larger while still maintaining well, documented, supportable interfaces within the established SLAs, and it’s all due to well-defined ownership.
A STOSA-based organization can handle larger and more complex applications than a non-STOSA organization. This is because STOSA shares the complexity of a system across multiple development teams effectively while maintaining clear ownership and lines of responsibility.