Think Architecture
August 15, 2018
Conway's Law
When was the last time you were engaged in a technical discussion? You may observe developers fighting to clarify boundaries, explaining which pieces should belong to which system. You may also hear developers negotiating their APIs with others, ensuring that their consumers use the appropriate mechanism to talk with the system they built. These developers have something in mind — defining proper boundaries so that external dependencies are minimized and system ownership and control are clear, making it easier for them to align their goals with others.
Most developers naturally define boundaries based on how they organized their teams because they want to have control over their system with clear separation of concerns from other systems. These boundaries give them a better chance of delivering and meeting their goals.
Although teams have good intentions and solid individual designs, we still ended up building a sizeable fragmented system that strongly reflects our team boundaries and organizational structure. Conway’s Law essentially describes this phenomenon:
“Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” — Melvin Conway
inverse conway maeuver
Conway effectively reminds us to first form a clear understanding of the architecture and design of our systems and then organize ourselves to build that desired architecture. This technique has become known as the Inverse Conway Maneuver.
Think Architecture
To initiate Inverse Conway Maneuver, we first draft the functional taxonomy that reflects the overall architecture we want to build for the platform. Next, we work with various groups within the organization to clarify the boundaries of each subsystem, with the goal of establishing proper groupings and removing unnecessary dependencies. This process follows two well-established Architecture Principles: The Principle of Single Responsibility and The Principle of Least Knowledge.
Understand the Architectural Vision
How can you contribute to this effort? Discuss Conway’s Law within your team and identify how it impacts your daily work. If you want to hear more about these stories, consider talking to engineers from other teams. Many of them likely have experienced the effects of Conway’s Law.
I also encourage you to routinely talk with the architects on your team about what your system architecture should look like and how it connects to other parts of the platform. Your architects will need to work with you to paint the right architectural vision.