light My Insights: Modern Software Architects cannot anymore purely focus on the Technical systems anymore. They must be “Sociotechnical Architects”: be able to consider the organizational and technical systems in the problem & solution spaces. Ignoring this is recipe for partial optimizations and in most cases a lot of “synchronization overhead and waste”. Why? Because if you ignore the influence that organizational and technical systems have on each other, you will not get teams with clear boundaries, owning decoupled parts of the product (value streams), and as such you will spend huge efforts on synchronizing all the teams developments. This is what many “Scaled Agile” frameworks focus on (“synchronization ceremonies”), however these are a temporary/poor remedy if the underlying sociotechnical architecture is not properly set up. Team Topologies provides a lot of interesting elements that Modern Architects can use on to address these sociotechnical challenges.

Analysis & Summary

In this podcast Manuel Pais and Matthew Skelton talk about several elements of Software Architecture and traits of modern Software Architects - many well positioned on their book Team Topologies. I couldn’t agree more with the core remark of the conversation, which I summarize as: the Modern Software Architect is a Sociotechnical Architect. Like Manuel says: “the focus purely on technology is not relevant anymore… the shape of the organization is a constraint on the solution search space. If your organization is set up in a particular way, we may never find a particular solution…”, i.e.: purely focusing on “technical architecture” will lead to to sub-optimal results - or even more bluntly put will lead to “working against forces in place” (the organization and its communication structures - as Conway’s Law states).

Given this, and also the fact that many of the things that traditionally a software architect would focus on are now provided “out of the box” by cloud providers, a modern architect needs to widen her focus and bring together, facilitate many of the relevant conversations around the sociotechnical architecture and how it enablers the organization and teams to move at high velocity. This may mean having to zoom-in and out in different perspectives of different systems, and work with different people in the organization, i.e.: being able to understand and speak the different languages and bring them together. But this position as a facilitator, enabling teams and organization to define the direction to move forward more strategically makes clear we need these socio-technical leaders in our organizations.

Team Topologies brings a lot of language, principles and guidelines to help architects on this job. Using these will help Architects a lot on having conversations about teams organization and their evolution. This is a great insight from team topologies: organizations are dynamic and as such, we need to accept that and continuously adapt as we see fit. This is also an important aspect for modern architects, and anyone that is in any way related with driving how the organization is setup. For example: if a product team grows too much in complexity and the team cannot work “well” anymore (i.e.: team has no “cognitive load” available to operate at its best), something needs to happen. For example: Team gets support from Platform to simplify complex elements that take a lot of effort from them, when building and deploying their product - releasing that cognitive load. Or we may need to create another team to take part of the elements of the team (with a clear scoping needed for that). All of this sort of discussions are not purely technical, they are sociotechnical and this is why modern architects should know about these different elements.

I really loved and resonate with a point made at a given point of the podcast, namely: If you ignore Conway’s Law and continue trying to keep an architecture that is not loosely coupled and with clear ownership boundaries, and you focus on “adopting scaled agile methodologies and frameworks” you will be drowning your teams into continuous and tedious “synchronizations” - they are all inter-tangled and need to sync with each other at each small step they take! I have shared this view many times in many places: adopting some agile practice and ignoring your sociotechnical architecture setup is not going to solve your problems… it will be just a light-pain-killer for a few days and a huge waste of time and efforts from many people.

They cover several other elements very relevant to Modern Software Architects, namely helping on scoping the Platform. Example, strive for the “thinnest platform” (i.e.: don’t follow the classical Platform patterns of building whatever seems interesting and then development teams can use that). Switch things around instead, i.e.: focus on the minimum platform needed and build it based on its customers (i.e.: the needs of the product teams building the product for the end customer of the organization, a.k.a.: “Stream Aligned Teams” in Team Topologies). This means Platform teams become also product-oriented too.