«This research has been partially sponsored by the Dutch Joint Academic and Commer- cial Quality Research & Development (Jacquard) program on Software ...»
Strategy – This practice supports a personalization strategy since it helps in deﬁning the structures by which individuals can communicate with each other. This practice does not focus on codiﬁcation of the knowledge entities that are discussed and exchanged.
6.3.7 Have a repository for architecture artifacts Practice Name – Have a repository for architecture artifacts (Damian and Zowghi, 2002).
Intent – This practice intends to build a repository to store architectural decisions including the rationale of these decisions.
Motivation – Having a shared repository with architectural knowledge helps in obtaining common understanding of the architecture and architectural decisions across development sites and in obtaining awareness of the local working context, as indicated by (Damian and Zowghi, 2002).
90 6.4. Validation
Prerequisites – In order to alleviate the distance in accessing relevant information from a shared repository, it is imperative that all development sites utilize a shared infrastructure. Furthermore, it is important to structure the information in the repository, following e.g., templates as deﬁned by (Tyree and Akerman, 2005).
Beneﬁts – When a shared repository is in place, all development sites can easily query and access architectural knowledge.
Drawbacks – This practice poses a challenge for the codiﬁcation strategy: design decisions should be captured (codiﬁed) in a way which makes them searchable and reusable in similar situations. Consequently, a starting point for the codiﬁcation strategy would be to identify appropriate use cases of this architectural knowledge (Clerc et al., 2007c).
Strategy – This practice supports a codiﬁcation strategy.
6.4 Validation We have selected a number of global software development projects from one domain at a large IT service provider (Organization D) to identify to what extent the practices for architectural knowledge management in a GSD setting are applied in practice. We included ﬁve projects from different sizes (ranging from 10 until 75 developers) and a different number of development sites (2 until 4 sites, within two countries at most). We performed an initial validation by studying the characteristics of the projects. Following that, we conducted semi-structured interviews with project managers and used the list of practices to collect feedback on the perceived usefulness of the practices. More
extensive validation is described in Chapter 7. We provide initial results below:
• Large introduction programmes for new-hires from remote development sites help in obtaining understanding in the context of the organization and speciﬁc techniques applied. An off shore desk supports the new-hires in a variety of logistical details to allow for smooth accommodation to the organization’s standards.
• The organization uses common infrastructural platform which makes use of different project-speciﬁc and generic environments in which members of projects can interact using collaboration-intensive tools.
• At several levels within the organization, email lists exist on which frequent discussions and questions on a speciﬁc topic related to architecture are discussed.
These topics are not further structured, but allow for fellow practitioners to share experiences and respond to questions.
• Several projects report that they have traveling plans to allow employees from a remote site to come to the local site.
6.5 Conclusions Our study aims to identify practices that can overcome global software development challenges in the realm of architectural knowledge management by studing the requirements engineering discipline. Our study so far shows that the practices that have been reported in the requirements management literature can be easily translated to be applicable in the ﬁeld of architectural knowledge management – we do not see any reason why certain practices would not be applicable. Consequently, we feel that both disciplines can share experiences to learn in understanding each other’s challenges and practices. Furthermore, we conclude that the majority of practices focus on a personalization strategy for architectural knowledge management since the practices support fostering interaction among knowledge workers (Babar et al., 2007). The literature reports on several tools that can help in capturing architectural knowledge and support a codiﬁcation strategy (Capilla et al., 2007; Babar and Gorton, 2007; Farenhorst et al., 2007a). Based on the results presented in this chapter, we support the arguments from (Desouza et al., 2006; Hansen et al., 1999) that a hybrid approach could combine the best of both worlds.
Initial validation of the architectural knowledge management practices for GSD shows that most of the practices seem applicable in an industrial setting. Our future work is aimed at a further structured validation of the list of architectural knowledge management practices for GSD by collecting detailed feedback on the perceived usefulness of the practices and the actual application of these practices (see Chapters 7 and
9. Furthermore, we plan to augment the list, which is currently primarily based on the literature, with additional practices by focusing on the different types of distance as e.g., identiﬁed in (Holmstr¨ m et al., 2006) to build a balanced set of practices for architeco tural knowledge management in GSD. The results of this future work is described in subsequent chapters of this thesis.
92 7 The Usefulness of Architectural Knowledge Management Practices in Global Software Development In further strengthening the set of architectural knowledge management practices for global software development, we have identiﬁed the perceived usefulness of the practices at a large organization involved in global software development. In this chapter, we report on this study. By including all the Dutch architects from the organization, we obtain a good overview of the perceived usefulness of the architectural knowledge management practices and identify and analyze a peak in the perceived usefulness of the practices at projects that involve three development sites.
7.1 Introduction Within the ﬁeld of software engineering, increasing attention is paid to global software development. In GSD, software development takes place at geographically distributed development sites. Although GSD can result in beneﬁts such as reduced development time and increased availability of skilled resources (Carmel, 1999), GSD poses additional challenges as well. Overviews of these challenges have been widely reported ˚ (Battin et al., 2001; Agerfalk et al., 2005; Holmstr¨ m et al., 2006). We also analyzed o these challenges in our earlier research, reported in Chapters 3 and 4; the challenges include lack of informal contact, language differences, and coordination complexity ˚ (Agerfalk et al., 2005).
A speciﬁc discipline within the ﬁeld of software engineering is software architecture. Whithin the software architecture community, an increasing interest in architectural knowledge management is recognized (Jansen and Bosch, 2005; Kruchten et al., 2006; van der Ven et al., 2006b; Babar et al., 2007). Architectural knowledge management involves capturing and communicating the design decisions that lead to a software system, including underlying rationale and context (Avgeriou et al., 2007).
Using architectural knowledge effectively may help in overcoming the challenges and issues encountered in GSD. However, we are currently lacking detailed insight into
937. The Usefulness of AKM Practices in GSD
architectural knowledge management practices that can effectively be applied in a GSD setting. More speciﬁcally, we are interested in identifying the relation between the perceived usefulness of architectural knowledge management practices and the number of sites in a software development project; this will satisfy speciﬁc needs of Organization D as well as offer further guidance on applying the architectural knowledge management practices.
To gain insight into the relation between perceived usefulness of architectural knowledge management practices and the number of sites, we build upon previous work in which we identiﬁed relevant architectural knowledge management practices based on literature and experience reports from the requirements engineering discipline (see Chapter 6). In this research, we validate these architectural knowledge management practices by conducting empirical research at a large IT service provider in the Netherlands, Organization D.
Our research shows that when the number of sites involved in a software development project increases the perceived usefulness of architectural knowledge management practices does not necessarily increase. The perceived usefulness of architectural knowledge management practices has its maximum in software development projects with three sites. Further investigation revealed that not all projects with three sites are initially set up as such; usually, they start with two sites and evolve to their current situation with three sites. The high perceived usefulness for some architectural knowledge management practices at three sites denotes a need to have these practices implemented proactively.
Furthermore, the usefulness of architectural knowledge management practices in general is conﬁrmed. Yet, some well-known global practices, such as having a clear project structure with communication responsibilities assigned or having a single repository for architecture artifacts, are not perceived as being as useful as one may expect.
Finally, our research shows that practices that support a personalization strategy towards knowledge management are perceived as more useful than practices that support a codiﬁcation strategy towards knowledge management.
This chapter is structured as follows. In §7.2 we provide an overview of related work in the ﬁeld of software architecture, architectural knowledge management, and global software development. Next, §7.3 lists the research question posed for this research. In §7.4 we describe the approach used for the research. The analysis and the results are described in §7.5 and discussed and validated in §7.6. Finally, §7.7 lists our conclusions.
7.2 Related Work The requirements engineering discipline is one of the ﬁrst software engineering disciplines in which research has been conducted to identify practices that alleviate the challenges that are involved with global software development. The work of Damian lists requirements engineering challenges and their (proposed and experienced) solutions (Damian, 2006, 2007; Damian and Zowghi, 2003). Bhat et al. (2006) provide insight into the challenges with requirements engineering in off-shore outsourced situations and lists ways to overcome these challenges.
94 7.3. Research Question
A resemblance between a set of requirements for a software system and a set of design decisions taken for that software system has been noted (van Vliet, 2008). In addition, Avgeriou et al. (2007) report on the identiﬁcation of architectural decisions that pertain to the problem space instead of the solution space. Since the problem space is populated with requirements, the challenges experienced in the requirements engineering discipline in GSD may have their counterpart in the discipline of architectural knowledge management in GSD, as shown by (de Boer and van Vliet, 2009) and Chapter 6.
In our research, we combine this topic with other challenges in knowledge sharing in a GSD situation as observed by (Balaji and Ahuja, 2005; Desouza et al., 2006).
In previous work, we gave an overview of the architectural knowledge management practices that can be applied in a GSD setting (Clerc, 2008). We deﬁned a light-weight pattern language for describing the practices which helps us in performing subsequent analyses. Our current research is aimed at validating these architectural knowledge management practices in practice.
Farenhorst et al. (2007b,c) list important prerequisites for architectural knowledge sharing and how these prerequisites can be supported by effective tool support. Especially within the collaboration-intensive GSD, these prerequisites are gain in importance. Babar et al. (2007) further focus on different strategies for sharing and managing architectural knowledge, following knowledge management literature: personalization and codiﬁcation. A personalization strategy promotes interaction between knowledge workers; knowledge is kept by its creator. A codiﬁcation strategy supports codifying knowledge and storing it in a repository, structured or unstructured. Babar et al. conclude, following (Desouza and Evaristo, 2004), that a hybrid approach between personalization and codiﬁcation is needed most.
In a workshop on sharing and reusing architectural knowledge (Avgeriou et al., 2007), insight was obtained into the dos and don’ts with respect to architectural knowledge. The workshop participants included both academia and industry. The workshop results show that the majority of the dos pertain to personalization in contrast to codiﬁcation, but that both knowledge management strategies need to be supported by the service provider’s culture. In addition, the workshop reported other important dos, such as a assigning a traveling architect, establishing peers, and allowing for periodic afterthe-fact reﬂection.
7.3 Research Question For gaining further insight into the architectural knowledge management practices for GSD, we are interested in determining the relation between the number of development sites involved in a global software development project and the perceived usefulness of architectural knowledge management practices. This will further help us to build a set of architectural knowledge management practices with additional guidance on their application. In addition it addresses speciﬁc needs of the case study organization as put
forward to us. To this end, we formulate our research question as follows:
How does the number of sites involved in a software development project inﬂuence the perceived usefulness of architectural knowledge management practices for that project?