Prisoners of the organization chart: how the configuration of teams conditions software development-EN

How often do we hear: “That was decided by the business area; we are only here to implement it“? Or business and product people saying, “But those are implementation details, and the engineers will clarify them.”

These expressions reflect the significant disconnect and little collaboration between areas of the organization-what we call organizational silos. The underlying problem is a lack of agility and focus on what matters: accelerating value delivery to customers.

The technological innovations of recent years for software production and development (the cloud, containers, serverless, etc.) have improved the work and sped up the delivery of value to customers. But in many cases, organizations are not reaping the benefits because organizational structures have become obsolete, and they are obstacles that get in the way of team dynamics.

This article will look at how team structure and communication directly impact the design and architecture of software systems and the quality, maintainability, and agility to evolve the systems.

What is Conway’s Law?

Conway’s Law was formulated by Melvin Conway more than 50 years ago and gained fame when Fred Brooks cited it in his book “The Mythical Man Month.” The law states, “Organizations engaged in systems design […] are bound to produce designs that are copies of the communication structures of these organizations.”

This theory reveals that organizational design and software design are, in practice, two sides of the same coin and are intimately related-even though they are issues that are addressed separately.

Conway’s Law posits that systems closely reflect the internal communication channels of teams and the organization.

In the past, when teams were siloed by area, applications had architectures that reflected little team interaction and integration (user interface, middleware, database, etc.).

These rather monolithic architectures also made testing, deploying, and evolving applications more difficult.

Conway does not point out what kind of architecture we need. But his observation explains the problems of “dissonance” that arise if the architecture we intend to build is not compatible with the structure of the teams and their internal communication channels.

James O. Coplien and Neil Harrison also point this out in their book “Organizational Patterns of Agile Software Development”:

“If the parts of an organization (e.g., teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationships between organizations do not reflect the relationships between product parts, then the project will be in trouble … Therefore: Make sure the organization is compatible with the product architecture.”

Ultimately, the channels of communication and interaction between teams will end up imposing themselves and dictating the system’s architecture. Specifically, they will influence the degree of coupling and cohesion of the pieces of the architecture.

Agile, Lean and DevOps show us that small, autonomous teams aligned with business needs can produce software in short, iterative cycles that adapt quickly to changes.

But this framework must also be supported by a good architecture to streamline the development, testing, deployment, maintenance and evolution of the system. For this, we need the architecture to take into account these two non-functional requirements:

• Low-level coupling between the different modules and components.
• High level of cohesion that each component of the system has a well-defined set of responsibilities (API) and its internal elements are closely related and integrated. Cohesion is the glue of the internal elements.

What can we do to make the architecture more decoupled and speed up deployments? What can we do to make APIs better designed, with more cohesion?

The answer is to apply Conway’s Law in reverse.

Intentionally going the other way

The Inverse Conway Manoeuvre proposes intentionally influencing the team configuration to obtain a certain architecture in the system.

That is, by understanding the characteristics of the software architecture we want to build – decoupled, more modular – we can explicitly adjust and evolve the communication structures of the organization’s teams in such a way that this is also reflected in the technical design of the system.

In other words, if we want our organization to discover and adopt specific designs and architectures that best fit how we want to deliver value to the customer, we can reshape the organization to help make that happen. Of course, according to Conway, there’s no guarantee that the organization will adopt the designs we want, but it’s more likely to occur by shaping the communication pathways.

We shouldn’t approach software architecture as an isolated concept without considering the structure of the teams. The reason microservices architectures have been so successful is because they are a perfect fit with multidisciplinary, autonomous teams capable of taking on independent, end-to-end module development with a decoupled design from the rest of the system. This is more productive than having several groups interacting to develop a monolithic system.

Conclusion

Conway observed that the communication structures of organizations directly influence system design. Conway’s Law points out the strategic implications of organizational design-the structure and interaction of teams-on the architecture of software systems.

Reviewing and reshaping the organization can help improve the delivery of value to customers through solutions that are more modular, easier to deploy and evolve, and built by more motivated teams.

In a future article, we will approach organizational design from another angle: managing dependencies between teams.