Introducing cloud computing based innovations presents challenges of coordination between the technical architecture of the cloud service(s) and the communication links within the organization. The Mirroring Hypothesis and Conway’s Law predicts that a correlation will exist between the technical architecture of the cloud service and the organizational structure of the firm. My intention within this subset of blog posts is to advance our understanding of Conway’s Law and The Mirroring Hypothesis as it relates to cloud adoption within complex socio-technical firms such as Snapfix. I have attempted to achieve this goal by presenting a reasonably comprehensive view of Conways Law and The Mirroring Hypothesis across firms creating and adopting cloud computing.

In the cloud development industry, the demand for global scale and the move towards mirroring of development teams has resulted in an industry wide shift from functionally focused teams to service focused teams. Firms such as Amazon, Microsoft, Spotify and Netflix have invested in organizational structures and promoted best practices that lead to team structure and size being closely linked to the artefacts (code-bases) they are producing (Cockcroft, 20141; Kniberg & Ivarsson, 20122; Vogels, 20063). To solve the issues of knowledge silos within teams, and teams insulation from the bigger organization, firms have created roles and processes that strategically ‘break the mirror’ so that common practices and direction are maintained across teams. Organizations have also borrowed from the OSS community by adopting a similar approach when separate teams have to coordinate their activities. Rather than requesting changes, a team can dip into another teams code-base and make the changes themselves. This highlights another way that organizations are strategically ‘breaking the mirror’ to facilitate rapid software development. This deviation from mirroring goes some way to solving the risk of innovative stagnation due to the insular nature of teams that are strictly mirrored to the services they are developing. Higher levels of cooperation and communication across teams are fostered through usage of these mirror breaking relational contracts across internal teams.

In the case of open source development of (presumptive) cloud services, there was some support for mirroring, but with a notable exception where the code-base deviated significantly from what a mirrored arrangement would look like. The data on open source projects was limited and conclusions should be based on a larger data set. In a future blog post I may expand on the role OSS has to play in team structures. I’ve discussed the issues separately in my series of blog posts on OSS Ideology and within this series of blog posts.

In aggregate, the data would seem to predict that organizations already immersed in open source methods may enjoy an easier transition to cloud computing and it would be recommended that organizations planning on mirrored cloud adoption should consider introducing or expanding their use of open source software.

When the relationship between the technical architecture and the development teams are stable then mirroring works quite well. However, in cases where rapid change or major expansion is occurring, mirroring can break down. The data contains examples of this within small organizations that had one team and one monolithic code-base. When the team grew to a two team structure, they no longer mirrored the monolithic software under development. In cases such as these, the organization must strategically abandon mirroring (or be forced out of mirroring) for some time until they have grown to sufficient scale and can introduce a best practice micro-service architecture and mirrored team structure. This same phenomenon can be experienced within a large organization when a single micro-service exceeds the bounds of the team and a second team needs to work on the service. In these cases, the micro-service should be re-architected into multiple separate services so that mirroring can be restored.

Based on my research, I would recommend that organizations in the nascent stage of developing new cloud computing services, and with limited resources, should plan for a period of chaotic growth when their cloud artefact (code-base) may significantly deviate from their growing team structures. The literature indicates that investment of time may be required to restore their project to a mirrored state. There are obvious implications for Snapfix and indeed for most high growth cloud based SaaS organizations.

For business units adopting cloud, this study has highlighted the issues faced when transitioning from an internal system approach to an external service approach. A common theme arose in several cases, where the IT dept was slow to adjust and failed to initially mirror the new services being introduced into their organizations. IT departments that adapted earlier and mirrored their processes, experienced a much smoother transition. Other business units also had to mirror their teams and processes to the new services they were using. Higher levels of technical integration resulted when business units adapted to the new services, which in most cases involved dealing with external service providers across firm boundaries. Interviewee VP, Global financial services, made the strategic decision within their firm to establish a separate cloud business unit rather than attempt to morph the exiting enterprise IT function from an on-prem culture to a cloud native culture.

I would predict that large enterprises with extensive on-premises IT functions will experience difficulty in transitioning to a cloud native organization. It would be prudent for Snapfix to target enterprises that have already introduced a cloud business unit so that skills and expertise can be transferred predictably and explicitly from the traditional IT function to the new cloud function.

On balance, I found strong support for Conway’s Law and the related Mirroring Hypothesis within teams developing cloud computing services and within teams consuming those services. The benefits of mirroring are evident within the data. However, cloud computing is in its infancy and the process of socio-technical changing that led to teams evolving to a mirrored state only emerged across the software industry around 2014. On the adoption front, IT departments are still grappling with the challenges of mirroring their teams to the technology. There are concerns from industry leaders that mirroring may ultimately prove to be unsuccessful unless organizations strategically ‘break the mirror’ in several ways so that innovation, cross-pollination of ideas and experiences can be shared across teams that may be blinkered due to a rigid focus on their technical artefacts.

Next: Sources: Snapfix Architectural Evolution

Some other reference materials:

  1. Cockcroft, A. (2014). Migrating to Microservices at Netflix. Retrieved 20 August 2019, from InfoQ website: https://www.infoq.com/presentations/migration-cloud-native/ ↩︎

  2. Kniberg, H., & Ivarsson, A. (2012). Scaling Agile at Spotify with Tribes, Squads, Chapters & Guilds. 14. ↩︎

  3. Vogels, W. (2006). A Conversation with Werner Vogels—ACM Queue. Retrieved 20 August 2019, from https://queue.acm.org/detail.cfm?id=1142065 ↩︎