Skip to content
#TeamTopologies

Team Topologies, Software Architecture & Complexity • James Lewis • GOTO 2022

#TeamTopologies #Software #Architecture #SoftwareArchitecture #Management #Processes #SystemDesign

Another interesting one. speech Since the GOTO conference in Amsterdam, the title of which contains terms that I often use myself: team topology, architecture, complexity. The author begins with an introduction in which he talks about the popularity of microservice architecture and why it has become so popular and what lies behind it. The author concentrates in his speech on 4 aspects:

  • componentization via services
  • organized around business capabilities
  • products not project
  • decentralized governance

Next, the author recalls the complexity of organizational design and so comes to the book "Team Topologies", about which I have a series of articles with its review:

  • Teams as means of Delivery
  • Team Topologies that work for flow
  • Evolving team interactions for innovation and rapid delivery And he recalls it in the context of someone at Amazon saying, "The bigger we get, the easier it becomes to get bigger," and the point is that the goal of a successful design organization is to optimize the structure for the flow of value, which is what helps make team topologies approaches. Funny how the author shows what the value creation process looks like (diagrams that are similar to those that remain after Event Storming) How little programming is there:)

He goes on to look at software architecture and how it helps us deal with the complexity of the world around us and our solutions that model it. I recommend reading A Philosophy of Software Design. (I have a brief sammari. 1, 2). This book is very well understood the issue of complexity and combating it when creating software. Then the author comes to the concept. complex adaptive system (Mammals, cities, software creation?) It shows them what their properties are. (self-similarity, self-organization, complexity, emergence) And how power laws work there for economies of scale and diminishing utility as you scale. (Except for Amazon, which does not diminish its utility, but it may be due to the network effects of multilateral platforms.Machine, Platform, Crowd"). As a result, complex adaptive systems are everywhere around us and the hierarchies in them lead to fractal effects with the effect of scaling with an exponent and a number less than one in the denominator.

After that, the author describes corporate metabolism - since organizations are also a complex adaptive system, as they scale, the number of hierarchy levels increases and revenue scales sublinearly and metabolism slows down. The author gives a funny example with the metabolism of an elephant and a mouse. Elephants need to eat much less food as a percentage of their mass than mice. But at the same time, the elephant's metabolism is so slow that it is no more than cancer - the cells simply do not have time to age. The same thing happens in large companies. Next, the author recommends the book "Accelerate", which allows you to monitor the health of the organization through metrics: MTTR, cycle time, change failure rate, number of deploys. Larger organizations have less R&D budgets, more processes and bureaucracy, and more hierarchies.

Finally, the author recalls how cities benefit both from economies of scale and from scaling in the form of increased innovation and draws parallels with companies that work on their organizational structure and culture, optimizing it for the flow of value.

#TeamTopologies #Software #Architecture #SoftwareArchitecture #Management #Processes #SystemDesign