The system architecture contains traces of your organizational structure

Conway’s law

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

— Melvin E. Conway

I know what you are thinking! What does one thing have to do with the other?

Well, it just so happens that teams don’t collaborate spontaneously. There’s “our team” and “the other teams.” We all play well with each other, but we only build things together when the requirements demand. And that impacts our code organization and the components we create.

Segregating component’s responsibilities

Teams are often built around products (when the organization has more than one), lines of business, clients (when the organization provides custom solutions), or… domain areas! When a software system is large enough, splitting it into different domains makes a lot of sense because it isolates the impacts of changes, allows for scalability, and makes the interfaces between domains clear, which helps to understand the codebase.

Splitting teams will break components apart

We talked about how a team is more likely to couple what could be separate domains. What happens if there is a restructuring and these teams are split into “purchase” and “payment”? I think you might have guessed.

To reduce the coordination effort between these two teams and reduce the chances that changes in one area will affect the other, they will invest effort into segregating the codebase. Now, let that sink in for a minute because it makes a lot of sense. On the other hand, who considers this kind of cost when they think of restructuring teams? It will be either that or costs related to defects investigation, communication, and coordination. Either way, there’s going to be a hidden bill.

If you like this post, please share it (you can use the buttons in the end of this post). It will help me a lot and keep me motivated to write more. Also, subscribe to get notified of new posts when they come out.

A team with too many domains to manage tends to build more coupled components

When a single team is responsible for multiple domain areas, it is more likely that some of these areas will have a higher coupling at the codebase. For instance, consider a system that offers purchases with options for payment methods.

A single team responsible for the entire purchase process is more likely to couple the payment methods to the purchase process. If there were two teams, one for managing purchases and another for integrating with multiple partners to provide different payment methods, it would be more likely that a payment API or (micro-)service would emerge for payments.

What’s the takeaway?

• If you have one or few teams managing multiple domains
  Make sure the team(s) are breaking apart the dependencies properly. Especially if you have a growth plan with your next organizational structure already designed. It will also help them document and test the system and onboard new members.
• If you have multiple teams and are planning on restructuring
  Work with them to identify the domains for each team and where there’s refactoring and redesigning will be needed. Consider the investment (effort) in making these changes before or after the transition. Most organizations ignore this hidden cost and let it happen after reorganizing teams. However, doing it before the restructuring ensures that the current SMEs will be able to do it, reducing the costs and risks, and making knowledge transitions easier.

Cheers!