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 follow 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.
Above shown image represents a
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. 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 for 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.