For more than ten years in software development, I saw companies and software engineer including myself pay most attention on software architecture or how to organize software components such as microservice. I also observed and experienced it myself that there still are a lot of issues moving from monolith to microservice architecture. When I read a book “team topologies”, I came to realization that the problem is not all about technology or architecture but also how we structure our teams to develop or maintain the software.
In this article, I would like to introduce something that I learned or inspired by reading this book.
Point 0 - What’s team topologies
Team topologies is a concept or guideline to organize technology teams to produce software in a fast changing world. The concept is relied heavily on Conway’s law (See Point 1). By thinking about team structure first, it is quite different from traditional software organization which normally thinks about software structure or architecture first. The guideline includes 4 types - stream-aligned, enabling, complicated subsystem and platform team and 3 communication styles - collaboration, x as a service and facilitating.
Point 1 - Conway’s law
Conway’s law indicates that structure of a software system will reflect the structure of the team developing that software. This implies that an organization with a structure that does not match the desired architecture would face a lot of friction to deliver software. For example, if you want a database per service architecture but having a separate DBA team, what you will get is a big database that every services rely on or an obstacle for development team to provision a database for their service.
Point 2 - How teams work
Most team should be stream-aligned teams who make change to the software which align with a business domain efficiently and autonomously. It needs to own everything needed in order to achieve autonomous and this could be difficult. Platform team can help by create internal products that make stream-aligned teams’ life easier. In case that there is some components that need specific skills, complicated subsystem team is needed. Lastly, if team need some new capabilities or skills, enabling team will help train and coach other teams building new skills.
Team communication is also important, not too much or too less. Collaboration between teams is used when building new things that teams need to work closely to make it happen. X-as a service is used between a loosely coupled consumer/provider teams. Facilitating is for enabling team.
Point 3 - Case study: software architecture and team misalignment
A software company uses microservice architecture as main structure. It has around hundreds services that serve a couple of products which service a few different customers. The original goal is to have a platform that can be extended easily to serve more customers in the same industry. Some services are product specific and some are common services. Teams are organized as product team. The problem is that every teams can and is responsible to make change to common services in order to serve their own requirement. This structure results in product specific logics are all over the places in the common services and create unnecessary dependencies. This makes it very hard for team to make change and know the impact to other products. This ended up in distributed monolithic architecture that no one would like to see and maintain.
Point 4 - Team topologies application
Software architecture design is not enough for an organization to success. We also need to design team who develop and maintain that software. As team topologies concepts suggests, we should start with desired software structure and organize teams to match that structure. Moreover, we need to keep monitor if current structure is aligned with business needs, if not, teams should be adjusted accordingly. More importantly, to create a great software, the team structure and communication channel should enable people in the team to be motivated and strive to make a better software.
Point 5 - It’s all about flow
The primary thing we as a software engineer should optimized for is to make the flow of change from requirement to delivery as fast and cheap as possible. Other things are secondary - architecture, methodology, tools or organization. They are there just to help us achieve the flow. For example, you might be a startup with a small team, doing microservice architecture. This can put a lot of load to the team to handle multiple services at the same time and make it hard for them to keep making a quality change to meet customer demands. Monolithic architecture should be a better approach in this context.
Point 6 - Another view on software architect
Team topologies also gives me another view on software architect role. Problems I saw regarding architect role is that they tend to take a lot of effort in initializing architecture blueprint and put it somewhere and hope that developer will follow them and that never happen. One reason is that it is difficult for developers to understand or follow. The suggestion is that architect should design both software architecture and teams or work in an enabling team which coaches stream-aligned team to understand and create a desired architecture. One important difference from traditional architect role is that stream-aligned team needs to decide by themselves on what to do or change.
Conclusion
The reality is the world is changing faster and faster. Organization needs to be the master of agility. Applying software architecture like microservice and adopting agile methodology might not enough. I think business leader, team leader need to understand how to organize their teams to best align with business stream of change and be successful.