Design anti-pattern: Tightly coupling infrastructure to org structure

One common design anti-pattern in the software engineering industry that I’ve come across repeatedly over the years is the practice of having infrastructure mirror the organizational structure of the company using it - a systems-level application of Conway’s law. Through these experiences, I’ve learned that this practice should be avoided unless there is a specific technical or financial requirement driving this decision.

The Anti-Pattern

This came up recently for me following a rather large company-wide re-org under several new business units. One of the teams wanted to split their tools so that each business unit would have their own separate instance. At first this seemed like a good idea: the benefits would provide better accountability for how each business unit/cost center were managing their costs with that tool, and each would have the agency to re-configure their instance as they see fit without worrying about impacting the other business units. Unfortunately, this approach doesn’t quite pan out that way in reality.

DevOps and IT teams are typically the first ones to see this as they are typically asked to execute on these infrastructure splits. They are in a prime position to raise the red flag on this anti-pattern before going down the rabbit hole and costing significant time and money.

Having seen this play out through various re-orgs in the past years of experience, I knew how this would all play out: someone would be tasked with the herculean effort of creating the new instances and dividing out the content in the existing instance between the two new instances. Since migrations are always a messy affair, it’s reasonable to expect a period of confusion and troubleshooting before they stabilize. Once the dust has settled, information silos creep up along these new instances, and as users in each new business unit realize they need access to the other business unit’s systems anyway, accounts for those users are re-created on each of the instances, multiplying the license costs and removing the benefit of better financial accountability.

Before long, another re-org happens and forcing a team to migrate their content to their new business unit’s instance, and the whole cycle begins again.

Changing the reporting structure of a team in HR is a relatively cheap task when compared to re-architecting an entire infrastructure. Re-orgs are already a painful experience for the individuals involved, and they don’t need to be made more difficult by adding an additional dependency on migrating infrastructure as well. As product teams continue to be agile, so too should the systems they depend on. Tightly coupling infrastructure to org structure does the opposite by forcing org changes to also trigger migrations within the tools.

Another major drawback of this approach is the inefficiency of managing these instances as the maintenance overhead of each tool is multiplied by the total number of instances. Config management and CI/CD best practices go a long way to mitigating this, but can only go so far.

A better design pattern

The problem that was meant to be solved in the first place is one of financial accountability in order to reduce costs and increase efficiency. Unfortunately, doing so by splitting infrastructure across business units can often lead to the opposite result.

The better solution is most often the simpler one: keep a single shared infrastructure and for the business units to agree to a cost-sharing model between them to figure out how each will contribute to the costs of the infrastructure (whether it be by seat counts, or as simple as evenly splitting out the cost, or some other heuristic). Regardless of what that heuristic is, the important part is that all business units have agreed to it and it is documented for all to reference in the future.

The decision whether a tool has a single or multiple instances should be driven by the technological and business requirements, not the organizational structure of the users.

This alternative design pattern provides product teams with continued flexibility without bogging them down into messy migrations whenever org structures change.