???? Key to Breaking Monoliths: Understanding the Power of Team Structure

I often discuss how to address the elephant ?? in the room. The legacy Monolith. And often, the solution is to start an even bigger team to solve the problem with the same thinking we had when we created it.

I recently read Team Topology by Manuel Pais and Matthew Skelton about thinking around team setup and stumbled over the Conways illustration. These methods are also included in The unFIX Company model by Jurgen Appelo .

One of my biggest takeaways was realising that our organisation's structure would shape how we design and communicate our software systems. If we want to move away from the Monolith, we must reconsider our team structure and break down silos.

This will help us evolve better communication and collaboration and ensure that our systems reflect the needs and goals of the organisation as a whole. By focusing on team topology, we can build more scalable, adaptable, and resilient software systems.

One Key thing is to figure out the boundaries and contracts between different teams, applications and areas within the Monolith. By contract, I mean both how information is transferred, e.g. API or how our human contract (RACI) is made between teams.

Key takeaway: Consider Team setup and the human side when breaking up your Monolith.