STOSA, or Single Team Oriented Service Architecture, is an important guiding principle for large organizations with many development teams that own and manage services comprising one or more applications.

Modern organizations, operating modern applications at scale, require an ability to scale *their organization* as much as they require the ability to scale *their application*. As their application grows in complexity and grows in sophistication, a larger development organization must build and manage the application. As their development organization grows, the organization’s natural ability to respond quickly and decisively to everything from customer requirements to ongoing operational issues can become stifled. To prevent this from happening, your development teams need to be organized in a manner that allows and enables the application growth that your organization demands.

This is where STOSA can help. Having a STOSA compliant application and a STOSA compliant organization operating and managing the application can go a long way towards enabling the growth and expansion that your business requires.

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

  1. Your application must be constructed using a service-based architecture or a microservice-based architecture.
  2. Your development organization must be divided into multiple independent development teams. Each development team should be between 5-10 people in size.
  3. Each and every service in your application must be assigned to a development team. That team owns that service. The service->team assignments should be well documented and readily available to everyone in the organization.
  4. Each service should be assigned to ***exactly*** one development team. An individual development team may own one or more services.
  5. Each service’s *owning team* is responsible for all aspects of managing the service. This includes service design and architecture, code development, testing, deployment, service monitoring, and incident resolution.

These are the basic service ownership and organization responsibilities for a STOSA organization. Figure 1 shows pictorially how this organizational structure is created. Here, the blue boxes (labeled “A” through “L”) represent the individual services that constitute your application. These services can be services such as “Catalog Service,” or “Shopping Cart Service,” or “Pricing Service,” for example. The dashed circles represent ownership responsibility for each team (Team 1 through Team 6).


It’s important to note on this diagram that each team has a well-defined set of services that it is responsible for. Additionally, each service is within the ownership bubble of a single team.

In future articles, I will go beyond the basic structure of organizing your team and talking about how your teams need to work together to build and operate a scalable application.


You can find more information on STOSA in my book, Architecting for Scale, 2nd Edition, published by O’Reilly Media. The book is available for purchase at Amazon.com or from the O’Reilly Safari library. This book can help you build a modern organization and build and deploy a modern application that can scale to meet your customer’s and your business’s needs.