Single Team Owned Service Architecture (STOSA)

February 10th, 2019 | Posted by Vidya Vrat in Architecture

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.

Non-STOSA-based organization

Above shown image represents a non-STOSA organization, and you’ll notice a couple 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. 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.

You can follow any responses to this entry through the RSS 2.0 You can leave a response, or trackback.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.