«This research has been partially sponsored by the Dutch Joint Academic and Commer- cial Quality Research & Development (Jacquard) program on Software ...»
• Only less complex, less mission-critical tasks, and testing activities are performed using the ‘follow-the-sun’ approach.
• Employees who feel threatened by the larger labor pool becoming available are unlikely to share best practices or knowledge.
1.2.5 Agile software development and global software development Agile software development covers a broad range of software development methodologies that are aimed at delivering working software soon, interacting with customers, and responding to change (Beck, 2001). Agile software development methodologies promote short development cycles and a focus more on working software over comprehensive documentation.
Different opinions exist on whether or not agile software development methodologies can ﬂourish in a global software development environment. Although increased geographical distance reduces the ability for coffee talks and other ways of informal
8 1.2. Introducing Global Software Development
communication, nowadays communication infrastructure is present (see §1.2.7) that reduces distance without the need for physical travelling1. Often, a higher need for documentation in GSD as compared to collocated software development is denoted. On the other hand, in order to make GSD a success, conscious adoption of agile practices, which have a lesser focus on documentation, can be helpful – as long as the adoption process itself is open for change (Ramesh et al., 2006; Sutherland et al., 2008).
David Parnas makes several remarks on the disciplines of GSD and agility in the ˚ sidebar in (Agerfalk and Fitzgerald, 2006). Parnas states that the underlying problems in GSD boil down to communication problems – between users and requirements engineers, between architects and developers, and between developers themselves. Global software development only worsened these problems. Solutions to the problems do not lie in producing more and more documentation of some kind. Parnas: “The real grand challenge is not to ﬁnd ways to avoid documenting, but to ﬁnd ways to produce useful documents – documents that take time but save more time. We will ﬁnd that real agility comes from good design that is well documented in precise, lean documenta˚ tion.” (Agerfalk and Fitzgerald, 2006).
1.2.6 Practices or solutions to achieve global software development beneﬁts When elaborating on the concept of distance and the challenges associated with it, solutions to the challenges in global software development may be found in practices that help to overcome the distance. Following Carmel and Agarwal (2001), distance negatively affects communication, which in turn hampers coordination effectiveness. Conway’s Law (Conway, 1968), which states the structure of an organization is mirrored in the structure of the software produced by that organization, calls for a clear modularization of the work to be performed. Various researchers have reported on reduction of coordination by means of a clear modularization of work to allow for localized (design) decisions and hence prevent conﬂicts (Herbsleb and Grinter, 1999b). To go even further, Carmel (1999) states that the architecture of a software system should be the driving force for modularizing and dividing work, instead of the other way around. More
recently, collaboration tool support can be utilized to cover the best of both worlds:
communicating effectively to divide or (re-)distribute work.
Solutions for the challenges in GSD are typically provided in terms of communication and coordination strategies; overviews are provided in (Herbsleb and Grinter, 1999a; Carmel and Agarwal, 2001; Lanubile et al., 2003; Herbsleb et al., 2005). These
authors, amongst others, suggest the following tactics to overcome distance:
Reduce intensive collaboration – By a clear division of work, the need for intensive cross-module collaboration and communication is reduced.
Reduce cultural distance – Cultural distance manifests itself in two forms: difference in organizational culture (the norms and values of the organizational unit) and national 1 On the other hand, not travelling at all is not a solution either. Rather, travelling in the early phases of a project helps to build trust and establishes team commitment (Corry et al., 2006).
culture (ethnicity, language, and political boundaries). Solutions to reduce cultural distance include:
• Introduce a bridgehead by having a ﬁxed percentage of the work be done on-site and thus not off shoring 100% of the work.
• Open internal (wholly owned) foreign software development centers instead of outsourcing or subcontracting the work to different organizations. In this way, one manages to reduce organizational distance and is able to train the employees in corporate methodologies.
• Appoint a liaison who is travelling back and forth between the stakeholder sites.
This liaison can fulﬁll an architect’s role as mentioned by (Corry et al., 2006) or could even be a cultural liaison (e.g., an ex-patriate) as (Carmel and Agarwal,
• Focus on improving the language used by the employees involved in GSD, by e.g., offering language courses.
Reduce temporal distance – Although different asynchronous communication mechanisms exist (e.g., email, online discussion groups), advantages are brought by synchronous communication mechanisms such as audio- or videoconferencing: smaller problems can be solved before they evolve into bigger ones. Although synchronous communication reduces temporal distance, it also prevents the beneﬁts from ‘followthe-sun’ work to be fully harvested. Moreover, the success of synchronous communication can be inﬂuenced by a difference in national culture; practitioners may be less or more eager to engage in synchronous communication because of e.g., language barriers.
Balaji and Ahuja (2005) have performed research that shows that a knowledge integration strategy can help to overcome the challenge of dispersed knowledge as highlighted by (Desouza et al., 2006). Their research shows that adhering to a knowledge integration strategy rather than choosing for one global knowledge management system, has a positive impact on overcoming challenges in GSD.
Casey and Richardson (2009) have developed a generic implementation model that supports organizations in adhering to a practical and systematic approach to address the key activities, infrastructure, and support required to facilitate effective GSD. This is a model in which the aforementioned practices may be placed. Richardson et al. (2010) propose a software process (inspired by the CMMI) to support the change for the project management discipline by proposing several practices for organizations implementing GSD.
1.2.7 Tool support for global software development Recently, different tools have been developed to address the issues involved in global software development and to integrate several of the solutions described earlier. In this section, we summarize some of the major developments. This section is primarily based on literature from the ﬁeld (Lanubile et al., 2010; Cataldo et al., 2009).
10 1.3. Research Context
Collaboration tooling focuses on supporting collaboration throughout the software engineering lifecycle. Version control systems (e.g., Concurrent Versions System, Subversion) allow for over-the-web management of evolution of source code and artifacts.
Issue tracking systems allow for e.g., distribution of (corrective maintenance) tasks to different sites. Other tools allow for collaborative modeling (and not just sharing the results of collocated modeling) using UML or other formal or semiformal languages.
Finally, communication tools such as email, mailing lists, on-line meeting facilities, groupware tools and more recently Web 2.0 solutions such as (micro-) blogs and wikis have proven their value to software developers at multiple sites, see e.g., (Damian et al., 2009).
Certain tools support only a (set of) software engineering life-cycle activities: project management, requirements engineering, architecture and design (Capilla et al., 2007;
Cataldo et al., 2009), and testing. Yet, no current tool supports all activities necessary for GSD. Lanubile et al. (2010) conclude by stating that “users must (... ) prioritize their collaboration needs and the tools to support them” instead of the other way around.
1.3 Research Context The research presented in this thesis has been performed in participation with two Dutch research projects: GRIFFIN and Stephenson.
The GRIFFIN (a GRId For inFormatIoN about architectural knowledge) project was a four year multi-partner research project. The goal of GRIFFIN was to identify tools, methods, and techniques for managing architectural knowledge. The project involved two universities (VU University Amsterdam and the University of Groningen) and several industrial organizations. The organizations involved range from SMEs to multinationals, and from scientiﬁc institutes to IT service providers. In the GRIFFIN research, we had the opportunity to collaborate with two of these partners.
The Stephenson project is a joint project between VU University Amsterdam and an industrial organization. In the project, research in the area of sharing architecture knowledge in a multi-site context was performed within the context of software product line development.
The GRIFFIN project was sponsored by the Dutch Joint Academic and Commercial Quality Research & Development (Jacquard) program on Software Engineering Research via contract 638.001.406. The Stephenson project was sponsored by the Dutch “Regeling Kenniswerkers”, project KWR09164.
1.4 Problem Statement As discussed §1.1.3, the management of knowledge plays an increasingly important role in the discipline of software engineering. One of the most important types of knowledge is knowledge pertaining to the architecture of the system being built. By sharing this architectural knowledge, challenges such as design erosion, high maintenance costs, and lack of information or documentation can be further reduced (Jansen, 2008).
When compared with collocated software development, global software development poses additional challenges. These challenges are related to temporal, geographical, and ˚ socio-cultural distance, as set forth by (Agerfalk et al., 2005; Holmstr¨ m et al., 2006).
o Communication and coordination between various development sites is hampered because of the time difference (limited overlap in time available to synchronize work), socio-cultural distance, and geographical distance. We have elaborated on these challenges in §1.2.2.
The combination of aforementioned two recent developments (the management of architectural knowledge and GSD) may appear to be fruitful; the challenges and issues involved in GSD may be addressed using architectural knowledge management and, conversely, the expected beneﬁts of GSD may be further leveraged using architectural knowledge management techniques. On the other hand, speciﬁc architectural knowledge management techniques may be necessary in sharing architectural knowledge across time zones and geographical borders. Likewise, the form in which architectural knowledge is shared should be chosen deliberately to overcome cultural barriers, such as differences in language. In conclusion, we currently lack the insight into how architectural knowledge can be managed in GSD.
1.5 Research Questions The problem statement as put forward in the previous section provides the motivation for this research: understanding how architectural knowledge management and global software development can co-exist, and how architectural knowledge management can further support the beneﬁts from GSD and address challenges and issues involved with
GSD. Hence, we formulate our central research question as follows:
RQ How can architectural knowledge be managed in a global software development environment?
Based on the deﬁnition of architectural knowledge as provided in §1.1.3, we have further elaborated the use of architectural knowledge within the GRIFFIN project. As a ﬁrst step towards understanding how architectural knowledge is managed, we pose the research question below. This research question is answered in Chapter 2 of this thesis.
RQ-1 How is architectural knowledge used?
For addressing the central research question, we are interested in identifying practices for the management of architectural knowledge in GSD. This directly leads to our second research question.
RQ-2 What are practices for managing architectural knowledge in a global software development environment?
The second research question serves as the main contribution of the work presented in this thesis. In our research, we have applied a breakdown of RQ-2 by identifying several distinct areas of research. In performing this research, we collected the results with which we are able to answer RQ-2. We describe each of these research areas in
turn. As such, the breakdown as provided below provides us with step by step results needed to answer RQ-2.
• First, we identiﬁed what practices a typical software development organization involved in GSD uses. Next, we compared these typical practices with the practices used by another organization to further obtain conﬁdence in the necessity or usefulness of these practices. This ﬁrst study provided us with the insight that primarily architectural knowledge management practices related to the development process were used in the organizations studied. This part of RQ-2 is answered in Chapters 3 and 4 of this thesis.