Architecture as a coordination tool in multi‐site software development

Abstract

A widely held understanding of coordination in software development is that it focuses on coordinating development activities to achieve a common goal. Our study, a case study in an international ICT company, suggests that in multi-site environment, it is not enough to coordinate development activities to achieve a common goal. Rather, more emphasis should be put on coordinating interdependencies between activities. Shifting the interest from activities (and subsystems) toward system-level dependencies requires software architects and developers to have a common understanding of the software architecture. Our findings reflect coordination challenges in multi-site environment with geographically dispersed teams. On the basis of the findings, we claim that architecture could be used to coordinate distributed development. However, this requires that the chief architect is capable of maintaining the integrity of the architecture and of communicating it. Furthermore, we list some requirements for a development methodology that uses architecture to support the coordination.

Global Software Engineering: The Future of Socio-technical Coordination

“…Adopting an architecture tends to guide developers toward compatible decisions, assuming there is effective communication and a common understanding of what the architecture actually is [37,54].…”

“…This can be a disadvantage if coordination becomes necessary among groups, as can happen when interfaces are unstable [38,54,65], or if there are important semantic dependencies.…”

Collaboration Practices and Affordances in Free/Open Source Software Development

“…Accordingly, these informalisms serve as affordances that facilitate, enculturate, and document collaborative work in FOSSD projects. [51].…”

“…It also enables shared architectural dependencies to arise (perhaps unintentionally) in the software components or sub-systems that are used/reused across projects [cf. 9,32,51]. FOSSD Web sites also serve as hubs that centralize attention for what is happening with the decentralized development of the focal FOSS system, its status, participants and contributors, discourse on pending/future needs, etc.…”

“…Such affordance limits major FOSS system changes to arise slowly through meritocratic coordination and consensus building that give rise to new system versions with alternative architectural configurations [cf. 51,58,59]. …”