Why Is Single Ownership So Important to a STOSA Organization?
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 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 a 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, I briefly discussed service ownership. In this article, I will go into service ownership in greater detail.
In a true STOSA organization, your development organization will be set up into 5-10 person teams and will have clear ownership of the services that construct your application. This is illustrated in Fig. 1 below.
Fig. 1: A STOSA organization
Non-STOSA organizations
Unfortunately, many organizations today have an organization that looks more like Fig. 2.
Fig. 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 Fig. 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.
Learn more about STOSA
DON’T MISS: 8 Things You Don’t Know About Architecting Your Business Infrastructure for Scale