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 is required to 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.
In the previous article, we discussed how to organize your development organization to build and manage a STOSA compliant organization and a STOSA compliant application. In that article, we discussed service ownership. In this article, we will go into service ownership in greater detail.
In a true STOSA organization, your development organization will be setup into 5-10 person teams and will have clear ownership of the services that construct your application. This is illustrated in Figure 1.
Figure 1. A STOSA organization
Unfortunately, many organizations today have an organization that looks more like Figure 2.
Figure 2. A non-STOSA organization
The problem with this organization is twofold. First, some services, such as service “C” and “D,” fall in more than one team’s ownership bubble. This means there is no clear ownership for these services. If a problem occurs, who is responsible? Team 1? Team 2? Both? Neither? We all have seen services like this, services that are so central to an application that many teams contribute to their development. They all work together, and each team creates different assumptions and makes different decisions—incompatible decisions. Unclear ownership responsibility leads to availability disasters down the line.
Second, some services do not have any owners assigned, such as service “I” in Figure 2. We all have services like this. For the most part, the simple services keep working, and nobody pays attention to them. A spec change occurs, a library goes out of service, a security vulnerability is discovered, and suddenly the owner of the service needs to do work on it…but there isn’t an identified owner, so the work slips through the cracks.
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.
More information on STOSA can be found 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.