Throughout my career, I have encountered various approaches to how corporations organize the development of AWS solutions. One of the most critical factors in successful development is team organization, as it has a direct impact on the application’s architecture. Years ago, Melvin Conway formulated a hypothesis, now known as Conway’s Law, which highlights the strong connection between an organization’s structure and the architecture of the systems it creates.
Conway law
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
Melvin Conway
Conway’s Law was evident in every organization I have worked with, consistently manifesting itself across various projects. The implications of Conway’s Law are significant and multifaceted, influencing both the design and scalability of software systems, e.g.:
- If the structure of the team is not aligned with the requirements of the project, Conway’s Law can work against us. For example, if we have a large, centralized team, we may end up with a monolithic architecture, even if a microservices-based architecture would be more desirable.
- Conway’s Law emphasizes the importance of communication. If teams in an organization communicate poorly, this can lead to system integration problems, interface design errors, or the formation of “walls” between system modules. This can work against us if not managed proper.
A common scenario where Conway’s Law played a crucial role was when a new project requirement spanned multiple teams. When a requirement needs to be partially implemented by each team, Conway’s Law can introduce several challenges and consequences:
1) Fragmentation of Functionality
Since each team will be responsible for implementing a different part of the same requirement, there is a risk of fragmentation. Different parts of the requirement might be implemented inconsistently, leading to difficulties in integration and increased system complexity. This could result in differences in design and implementation approaches, making it harder to achieve consistency.
2) Communication and Coordination Issues
Each team will need to communicate with other teams to ensure that their part of the implementation aligns with the others. If the organizational structure does not support effective communication between teams, coordination issues may arise, leading to delays, errors, and inconsistencies in the implementation.
3) Duplication of Work
In some cases, teams may independently work on similar problems, leading to duplication of efforts. Instead of collaborating on a shared solution, teams might create their own distinct implementations, which is inefficient and can add to the system’s complexity.
4) Architecture Reflecting Team Structure
Conway’s Law suggests that the system’s structure will reflect the division of work among teams. In this scenario, it could lead to an architecture where the requirement is divided into separate modules or components, each handled by a different team. If teams have different design approaches, this can result in a non-uniform architecture, with varying coding standards, technologies, or testing methods.
How to Address This?
We have 2 possibilities to address those issues, the first one is to, which only hides the problem is to:
1) Establish shared standards, architectural guidelines, and coding practices across all teams can help minimize inconsistencies.
2) Consider forming cross-functional teams or project working groups that are responsible for the entire implementation of the requirement. This can reduce the risk of fragmentation and integration issues.
3) Ensure that teams regularly communicate and synchronize their work to avoid inconsistencies and duplication. Sync meetings, code reviews, and joint workshops can be helpful.
4) Introducing a central point for requirement management can ensure consistency in implementation. This entity could monitor progress and coordinate activities across teams.
Another possible solution to “fight” against Conway law is to use Reverse Conway Maneuver
Reverse Conway Maneuver
Organizations should evolve their team and organizational structure to achieve the desired architecture. The goal is for your architecture to support the ability of teams to get their work done — from design through to deployment — without requiring high-bandwith communication between teams
The Reverse Conway Maneuver involves intentionally changing an organization’s structure to enforce or support a desired system architecture. Instead of merely accepting that organizational structure influences system design (as Conway’s Law originally suggests), an organization can consciously reorganize its teams and communication structures to better reflect the desired software architecture.
What Enables the Reverse Conway Maneuver?
Supporting Innovation and Experimentation: Smaller, autonomous teams responsible for specific parts of the system have more freedom to experiment with new technologies and approaches. This allows the organization to adapt more quickly to market and technological changes.
Aligning Architecture with Business Needs: If a company wants to implement a specific architecture, such as microservices, it can organize its teams around individual services. This allows teams to become more autonomous, promoting the development of a modular and scalable architecture.
Facilitating Communication and Collaboration: By changing the structure of teams, an organization can improve the flow of information and collaboration among team members, which is crucial for the success of complex projects. Improved communication can help minimize integration issues and inconsistencies within the system.
Increasing Team Efficiency: Organizing teams around specific system components can increase their responsibility and engagement, leading to better understanding and faster implementation of requirements. It can also help reduce technical debt, as teams have greater control over their parts of the system.
Managing Complexity: By reorganizing teams in a way that mirrors the system structure, an organization can better manage system complexity. This might involve breaking down large, monolithic teams into smaller, more agile units, which supports the decomposition of the system into smaller, more manageable modules.
Plan to apply Reverse Conway Maneuver
1. Identify the Desired Architecture
- Analyze the Current Architecture: Begin by thoroughly analyzing the existing system architecture and identifying areas that need change. At this stage, avoid jumping straight into selecting an architectural design. Instead, start by thoroughly analyzing your current domain. Focus on identifying common functionalities that may be relevant across various business scenarios. One effective tool for this is Event Storming. This technique helps you map out business processes and uncover key events and interactions, providing a clearer understanding of the domain and its requirements before finalizing your architectural decisions.
- Define Architectural Goals: Establish clear goals for the architecture, such as scalability, flexibility, ease of maintenance, or rapid deployment of new features.
2. Map Teams to Components
- Reorganize Teams: Teams are reorganized around key components or modules of the system. Each team becomes responsible for the development, maintenance, and evolution of their assigned component. For instance, if the architecture is to be divided into microservices, each microservice may be assigned to a separate, autonomous team.
- Set Boundaries of Responsibility: Clearly define the boundaries of responsibility between teams to avoid overlapping work and ensure that each team has full control over its part of the system.
3. Manage Interfaces and Communication
- Design Interfaces: It’s crucial to design clear, well-defined interfaces between components managed by different teams. This ensures that interactions between components are consistent and manageable.
- Promote Team Collaboration: While teams are autonomous, effective communication and collaboration between them are essential to avoid integration issues. Regular synchronization meetings, joint code reviews, and project management tools can support this collaboration.
4. Monitor and Iterate
- Continuous Monitoring: After implementing the new team structure, the organization monitors the effectiveness of this approach. It assesses whether the new organization is supporting architectural goals and if any new challenges arise.
- Adjust as Needed: Based on collected data, the team structure may be further adjusted to better support the desired architecture. This may involve changes in team composition, size, or project management methods.
Real life example
Suppose you introduce a new requirement in a microservices application for a complex reporting function that requires data from several microservices (e.g., user, order and payment services).
- Identify which microservices are involved and what data needs to be exchanged.
- Create a working team consisting of team members responsible for each microservice to work together to integrate the reporting function.
- Hold regular meetings with teams to discuss progress and resolve issues.
- Conduct integration tests to ensure that reporting works properly in collaboration with data from different microservices, then gather feedback and make necessary adjustments.