As we covered in our recent webcast on automated deployments, manual deployments are pretty obviously inferior to automated deployments. And yet, as an industry we still have a lot of manual deployments. This counter-intuitive fact demands explanation. Conway's Law provides one.

Conway's Law: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." In other words if a software system is developed by an organization that has three development teams, the system will most likely have three sub-components or a three tiered architecture. The quality of the interfaces between those components or tiers can be predicted by the quality of communication between the teams.

Applying Conway's Law to deployments

How does this apply to deployments? Imagine our software passes through the hands of three distinct teams. Developers who write it. QA who performs detailed testing and Operations people who load it onto production servers. They each have different problems and concerns: Developers want perform basic verifications quickly. Operations wants control over what happens. Testers want to test fairly new builds and know what versions to log their defects against.

Who owns the deployment process? Unless someone all three groups report to cares about the process  (often that's only the CIO) each team will deploy in their own way. Without the need for speed that developers have, the operations team will have a very controlled, albeit manual deployment. Developers will automate their deployments, but often in a slipshod manner inappropriate for more controlled environments. QA might come up with an elegant solution balancing speed and control, but usually lacks the political power to influence the others. In the end, the Operations team has a manual deployment done differently than the deployments in Development and Test. That leads to inefficiencies and breakages.

What the future holds

Is there any good news? Yes! Two trends are moving us towards increased cooperation between the teams. The first is that we are seeing this get the attention of CIOs. They are putting together teams responsible for coordinating everyone who deploys. The second positive trend is Agile Development. Agile encourages closer interaction between Developers and Testers. As their work becomes more integrated, the need for a shared deployment process controlled by a build pipeline increases. Development has experience with Continuous Integration and helps push those principals of automation downstream through the application lifecycle.

In both cases, the shape of organizations is trending away from disparate Development, QA and Operations and towards integrated teams and/or better communication. As this happens, a fundamental barrier to automated deployments will fall.

Can't wait for this to happen to your team? Convincing the CIO that last month's production outage was the result of deploying differently in Development than in Operations would be one approach. Another would be getting in touch with your peers in other groups and starting a conversation around how they deploy and how your teams can start deploying the same way.