Application of Conway’s Law in Software Development and Architecture

Syed Khader
February 12, 2020

Before going on to Fitness Functions in Evolutionary Architectures, I thought to pen one of the important paper submitted to Harvard Business Review which is popularly known as “Conway’s Law” and the paper called “How do Committees Invent?”

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations – Melvin Conway, 1967.”

In very board terms, Conway puts it as Organizational structures and communication paths influence final product design.

What it means to applying this law in to Software Development and Architecture is that in early design stages high level understanding of the system is important so that it can be broken down to smaller, manageable yet responsible blocks. Reason for breaking down those blocks is for their easier management and maintenance. Such break down creates coordination and communication problems. Organizations addresses such problems by introducing formal communication paths of various types e.g. hierarchy. However such communication paths results in inflexible solution. Here comes “Organizational structures are reflected in systems”

As we see or have seen that in many organizations teams are divided based on their functional skills. Such as team of Front-end developers, UI/UX teams, Back-end developers, DBAs and Mobile developers.. etc. such functional silos have no regard to engineering efficiency.

“A feature dependent on two or three teams takes longer as each team works on their component at different times. For example, consider the common business change of updating the Catalog page. That change entails the UX, UI, business rules, and database schema changes. If each team works in their own silo, they must coordinate schedules, extending the time required to implement the feature. This is a great example of how team structure can impact architecture and the ability to evolve.

As Conway noted in his paper by noting every time a delegation is made and somebody’s scope of inquiry is narrowed, the class of design alternatives which can be effectively pursued is also narrowed. Stated another way, it’s hard for someone to change something if the thing she wants to change is owned by someone else. Software architects should pay attention to how work is divided and delegated to align architectural goals with team structure” — From book: Building Evolutionary Architectures

Organizational and team structures are reflected in their Systems: Rather than writing down in detail, the above can be easily understood from the following diagrams.

1: Technical organization of teams

2: Architecture driven by technical capabilities

3: Organization of teams driven by business capabilities

4: Business-driven architecture

Reference : [Blog]Applying-conways-law-improve-your-software-development

As illustrated in the above figures, it is clear that team structure will impact architecture dimensions. Instead they should reflect domain and problem and its scope and size not based on their functional and technical capabilities.

Conclusion: Organize and structure teams to like your target architecture and Building evolutionary Architectures to achieve a business goal.