«This research has been partially sponsored by the Dutch Joint Academic and Commer- cial Quality Research & Development (Jacquard) program on Software ...»
During recent years, the IEEE 1471 recommended practice has been superseded by ISO standard 42010 (ISO/IEC, 2011). This ISO standard even further incorporates the ideas of describing a software architecture as a set of design decisions by explicitly including the architecture rationale and architecture decisions as architectural description elements – this shows the wider acceptance of these rather new developments within the software architecture community.
1.1.2 Knowledge management The discipline of knowledge management makes a clear distinction between two types of knowledge: tacit knowledge and explicit knowledge. Tacit knowledge pertains to the kind of knowledge one possesses but cannot easily express. Explicit knowledge is knowledge that can be expressed in various forms, such as conversations, electronic communication, or writing (Nonaka and Takeuchi, 1995); the majority of the knowledge remains tacit because no explicit actions are undertaken to codify the knowledge;
if this is the case, the risk of key individuals leaving the organization (and the knowledge that walks out the door with them) increases further.
Following the insights from Nonaka and Takeuchi, several strategies for knowledge management can be distinguished. These strategies include a codiﬁcation strategy towards knowledge management and a personalization strategy towards knowledge management. Hansen et al. (1999) deﬁne the codiﬁcation strategy as aimed at systematically storing knowledge in a repository, structured or unstructured, so that it becomes available to people in the company. A personalization strategy promotes interaction between knowledge workers; knowledge is kept by its creator and not the knowledge itself but rather information about knowledge sources is captured, to ensure that people know who knows what. Desouza and Evaristo (2004) conclude that when knowledge is to be shared in distributed projects, a hybrid approach focusing on both personalization and codiﬁcation is favourable.
We observe that knowledge management practices further strengthen the discipline of software engineering. Rus and Lindvall (2002) provide a good overview of the recent developments in software engineering for sharing documented knowledge independently of time and location. Some of these practices may include e.g., boundary spanning. Boundary spanning is emphasized by the literature as relying on individuals (i.e., the boundary spanners) to facilitate the sharing of expertise by linking two or more groups of people separated by location, hierarchy, or function (Cross and Parker, 2004).
A more recent report on a study on practices for boundary spanning (Levina and Vaast, 2005b) has researched the balance between collaborative boundary spanning practices versus transactive boundary spanning practices (Kogut and Zander, 1992). As put forward by Kogut and Zander, a delicate balance lies between reliance on interpersonal collaborative practices versus practices that support the codiﬁcation of knowledge. This notion has been independently researched and described in (Nonaka and Takeuchi, 1995;
Hansen et al., 1999).
When the individual memory systems and communications of e.g., boundary spanners (labeled transactions) are combined, this results in a transactive memory system.
Hence, a transactive memory system is a set of individual memory systems in combination with the communication that takes place between individuals (Wegner, 1986).
Oshri et al. (2008) studied the role of transactive memory in knowledge transfer between globally distributed teams. Oshri et al. found that transactive memory supports the the notion of who knows what across on-site and off shore teams despite the challenges associated with globally distributed teams.
1.1.3 Architectural knowledge As described earlier, the management of knowledge pertaining to the software architecture becomes increasingly important within the discipline of software architecture (Bosch, 2004; van Vliet, 2008). Management of architectural knowledge helps to prevent design decisions to remain tacit which helps to reduce the high cost of change because of knowlege vaporization (Jansen et al., 2008).
De Boer and Farenhorst (2008) have performed research to deﬁne what architectural knowledge exactly is. Using a systematic literature review, de Boer and Farenhorst show that many authors do not provide a concrete deﬁnition of what architectural knowledge entails. Yet, these authors seem to agree that knowledge spans from problem domain through decision making to solution.
We deﬁne architectural knowledge as the integrated representation of the software architecture of a software-intensive system (or a family of systems), the architectural design decisions, and the external context or environment. As such, architectural knowledge includes both functional and technical architectural knowledge. The management of architectural knowledge covers all activities to create, store, retrieve, and maintain architectural knowledge. Hence, architectural knowledge management may be supported by practices and (automated) support tools.
For further reasoning about architectural knowledge, it is important to prevent possible terminology differences that may exist at various organizations, including those where we performed case studies during our research, see (de Boer and Farenhorst, 2008). To enable further reasoning, we have developed a core model of architectural knowledge. The core model has been devised to cover all concepts necessary to deﬁne architectural knowledge (de Boer et al., 2007); as such, it may help in reasoning about and codifying essential architectural knowledge. With the core model, constructing an Architectural Design can be seen as a decision-making process. Decision-making essentially boils down to proposing and Ranking Alternatives to address a speciﬁc Concern of a Stakeholder, and eventually results in making a decision (see the lower part
in Fig. 1.1). Furthermore, the core model supports in describing architectural knowledge using a Language (e.g., an ADL, or just plain English) to capture the Architectural Design in an Artifact (again, see Fig. 1.1).
* * 1
1 1..* *
Figure 1.1: Core model of architectural knowledge (from (de Boer et al.
1.2 Introducing Global Software Development 1.2.1 Deﬁnition of global software development Global software development (GSD) is software development that uses teams from multiple geographic locations (Sangwan et al., 2006). The locations of these teams are commonly referred to as sites or development sites. When comparing GSD to traditional, collocated software development, the most striking difference is the geographical spread of the development locations. In spite of this, research by Allen shows that the impact of geographical spread may occur more often than initially thought of; engineers do not communicate more frequently when they are 30 meters or more apart as compared to many miles (Allen, 1977). Nevertheless, challenges that occur because of geographical
spread of development sites may be increased by several additional factors that play a signiﬁcant role in GSD. These additional factors relate to cultural diversity and time zone difference. These topics will be elaborated upon later in this chapter.
Overviews and general experience reports on GSD have regularly appeared in IEEE Software (Herbsleb and Moitra, 2001; Damian, 2007; Carmel and Agarwal, 2001). More recently, the ICSE workshop series on GSD have evolved into the International Conference on Global Software Egineering (ICGSE) series. Several workshops on software engineering disciplines furthermore receive a ‘global’ focus, such as requirements engineering (GREW’07), knowledge management (KNOWING’09 and ’10), and architectural knowledge management (SHARK and AGSE workshop series).
1.2.2 Challenges with global software development When spreading development activities across different sites, several challenges are ˚ posed on the assumed beneﬁts of global software development. (Agerfalk et al., 2005) provide a useable framework to consider the opportunities and challenges or threats ˚
involved in GSD. Agerfalk et al. have performed an extensive literature study and identiﬁed the following three processes that are fundamental for GSD:
1. Communication – “The exchange of complete and unambiguous information – that is, the sender and receiver can reach a common understanding”, according to (Carmel and Agarwal, 2001). The distance involved in GSD takes the opportunity for face-to-face exchange away, which makes communication in itself even more important.
2. Coordination – “The act of integrating each task with each organisational unit, so the unit contributes to the overall objective” (Carmel and Agarwal, 2001). Coordination between two parties makes these parties dependent of each other. In GSD, this dependency is burdened because of different time zones and cultural differences.
3. Control – “The process of adhering to goals, policies, standards, or quality levels” (Carmel, 1999). Control focuses on the management reporting mechanisms and hence relates to project management.
˚ Holmstr¨ m et al. (2006) built upon the framework provided by Agerfalk et al. by furo ther elaborating on the pivotal concept of distance in GSD as initially mentioned by (Carmel and Agarwal, 2001): temporal distance refers to the limited amount of overlap in working hours (e.g., due to time zone difference or shifting working hours) and the limited possiblity to synchronize work across various sites. Socio-cultural distance refers to the different cultures that cooperate in GSD – this is also reﬂected in linguistic differences. Socio-cultural distance has been extensively analyzed by (Hofstede, 2001).
Hofstede has conducted several extensive studies and identiﬁed a theory on cultural dimensions, which shows how national and regional cultural groups inﬂuence the behavior of societies and organizations. Hofstede’s research provides insight into other
6 1.2. Introducing Global Software Development
cultures so that one can be more effective when interacting with people in other countries. Geographical distance, ﬁnally, focuses not on the distance itself but on the effort needed for relocation, i.e., travelling. Low geographical distance typically offers more possibilities for collocated, inter-team working.
1.2.3 Knowledge management in global software development Without effective information and knowledge sharing mechanisms, it is difﬁcult to exploit the beneﬁts of global software development (Prikladnicki et al., 2003). However, applying knowledge sharing mechanisms poses several challenges to GSD itself (Desouza et al., 2006). In GSD, expertise and best practices are collected and reside at multiple locations (possibly across organizations, in the case of outsourcing). Consequently, difﬁculties exist in locating and/or accessing relevant knowledge due to the distance innate to GSD. Moreover, coordinating and synthesizing this knowledge poses challenges: organizations don’t use relevant knowledge harvested from past experiences.
Different strategies towards the management of knowledge in GSD have been explored in the literature. As opposed to implementing one central knowledge structure in which all knowledge is kept and managed, Desouza et al. (2006) propose a hybrid knowledge strategy which is focused on reusing global knowledge and connecting knowledge sources for local (i.e., project-speciﬁc) knowledge. The structure for the global knowledge would allow for the use of popular knowledge and provide an index to project-speciﬁc knowledge, hence providing coordination across project work. As such, the models proposed by Desouza et al. (2006) build upon the codiﬁcation strategy and personalization strategy towards knowledge management as initially described by (Hansen et al., 1999).
Reduced development costs due to salary savings (Carmel and Agarwal, 2001) – Typically, salaries are orders of magnitues lower in off shore countries such as India or China, or near-shore locations such as that may be found in Eastern Europe.
Access to a larger (skilled) labor pool (Carmel and Agarwal, 2001) – For demographic reasons, the number of skilled software engineering practitioners is higher in e.g., India or China.
‘Follow-the-sun’ development leveraging time-zone effectiveness (Carmel, 1999) – Although organizations primarily choose for GSD for the assumed cost advantage and access to a larger labor pool, the real beneﬁt of GSD lies in the fact that software development can occur 24x7 by handing over software development tasks (efﬁciently) to sites in appropriate time zones (Carmel and Agarwal, 2001). Visser and van Solingen (2009)
offers additional guidance on how to select the right sites to fully utilize the beneﬁts ´ of GSD using an implemented routing model. Experience reports (O Conch´ ir et al.,u
2009) suggest a shift in working hours to get more overlap in working hours. On the other hand, this shift reduces the possibility for getting the most out of ‘follow-the-sun’ development).
Greater innovation and transfer of best practices (Damian et al., 2003) – As a direct consequence of access to a larger (skilled) labor pool, organizations that employ a lot of practitioners have the possibility to explore various (technological) innovations and share best practices as these are collected in their software development projects.
Closer proximity to markets and customers (Grinter et al., 1999; Herbsleb et al., 2000) – With upcoming (emerging) markets in Middle-East and Asia, the labor pool available in these countries (e.g., Eastern European countries, India, China) has a closer proximity which can result in alleviating the geographical and time zone distance.
• Signiﬁcant overhead in communication, coordination and control needed.