A Framework for Scalable Organizations
Single Team Oriented Service Architecture
A guiding principle for large organizations managing service-based applications across multiple development teams. Clear ownership. Scalable teams. Reliable systems.
What is 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.
A STOSA-compliant organization requires the following:
- Service-based or microservice architecture with multiple development teams managing the application
- Each and every service in your application must be assigned to a development team who owns that service
- No service is shared between teams; a team may own multiple services
- Owning teams are responsible for all aspects of their service's management
- Strong service boundaries with fully documented APIs
- The service owns its own data; data is accessed by others only through the service's API
- Services maintain and monitor internal SLAs
Typically, each team should be of a reasonable size (between three and eight engineers).
STOSA vs. Non-STOSA
The core distinction of STOSA is clear, unambiguous service ownership. Every service belongs to exactly one team.
STOSA Organization
Each service belongs to exactly one team. Ownership is clear and unambiguous.
Non-STOSA Organization
Shared ownership (C, D) and unowned services (I) create accountability gaps and confusion.
Advantages of a STOSA Organization
A STOSA-based application can grow larger and be managed by a larger development team than a non-STOSA-based application. With STOSA, your organization scales while maintaining clear accountability.
- Clear ownership enables faster decision-making and fewer coordination bottlenecks
- Teams can grow and scale independently without disrupting other teams
- Incident response is faster and more focused when responsibility is unambiguous
- Services can evolve at their own pace within clear API contracts
- Organizational scaling becomes manageable because team boundaries are well-defined
What Does it Mean to Own a Service?
In a STOSA organization, the team that owns a service is ultimately 100% responsible for all aspects of that service.
API Design
The design, implementation, testing, and version management of all APIs, internal and external, that the service exposes.
Service Development
Design, implementation, and testing of the service's business logic and behavior.
Data
Management of owned data, schema, access patterns, and lifecycle. Data is part of the service.
Deployments
Determining update necessity and deployment processes including verification and rollback procedures.
Deployment Windows
Safety determination and enforcement of deployment blackout windows to protect service stability.
Production Infrastructure
Load balancer settings and system tuning for the service's production environment.
Environments
Managing production and all non-production environments for the service.
Service SLAs
Negotiating, setting, and monitoring SLAs, along with the responsibility of keeping the service operating within those SLAs.
Monitoring
Setup, management, and regular review of service monitoring systems and alerts.
Incident Response
Ensuring pager notifications are generated when the system functions out of specification, and responding to those incidents.
Reporting
Internal and management reporting on service health, performance, and reliability.
Shared Infrastructure
Even when aspects are handled by core teams, the service owner is ultimately responsible for ensuring activities are handled to the required level.
STOSA Organization
Service-owning teams operate as peers, each fully accountable for their services. Core and support teams provide shared infrastructure, but the service-owning team retains ultimate accountability.
The service failure is the responsibility of the service-owning team, even when external teams contribute to issues. Teams receive requirements but control implementation details within system-wide compliance constraints. With strong ownership of results also comes strong ownership of decision-making affecting your service.
Often-delegated functions
Certain infrastructure functions are often managed by central teams. Even in these cases, the service-owning team remains ultimately responsible for their service meeting its obligations.
Servers / Hardware
Operations teams or cloud providers manage underlying infrastructure, while service teams remain accountable for their service's performance on that infrastructure.
Tooling
Centrally owned deployment, compilation, monitoring, and incident response tools are shared across teams, though teams may choose alternatives when needed.
Databases
Central teams manage hardware and database applications. The service-owning team manages schema, access patterns, and data usage.
This model provides strong motivation for centralized teams to offer high-quality services, since service teams retain the ability to seek alternatives.
About Lee Atchison
Lee Atchison is a software architect, author, and recognized voice on cloud computing and engineering leadership. He is the creator of Single Team Oriented Service Architecture (STOSA) and author of Architecting for Scale (O'Reilly), which covers STOSA and high-availability system design in depth. With more than three decades in the industry, including seven years at Amazon and AWS and eight at New Relic, Lee currently writes and consults through his practice, Atchison Technology. He lives in Seattle, Washington.