«This research has been partially sponsored by the Dutch Joint Academic and Commer- cial Quality Research & Development (Jacquard) program on Software ...»
A second consequence of the tendency towards decentralization is that the practices focusing on architectural guidelines that should be adhered to (architectural rules) are not used; posing architectural rules typically occurs in a more centralized collaboration structure. Organization E has deliberately chosen not to pose these rules since the quality mindedness and adherence to quality standards are key responsibilities of each employee individually.
1359. The Use of AKM Practices in Agile GSD
9.4 Threats to Validity In this research, we have validated a collection of architectural knowledge management practices for global software development at a single large organization; we included two projects in our study that involve unit teams spread across three sites. Including only one organization puts some limits on the external validity (generizability) of our research resuls. Yet, having included 38 employees with varying tasks and responsibilities at the three sites, we believe to have included a representative subset of a large organization. Furthermore, our results primarily apply to organizations who are involved in agile-based global software development. Organizations that support a more hierarchical and/or formal software development methodology might beneﬁt from practices that are proposed but are not used by the organization where we conducted our survey.
We have used content analysis as the basis of our study. As indicated by (Weber, 1990), several difﬁculties exist in the application of content analysis that may pose validity issues. We discuss these brieﬂy in the remainder of this section. First, with respect to measurement, we decided to count the number of occurrences of the semantic unit. Weber (1990) argues that in counting semantic units and subsequently grouping them to an element of our validation model, it requires less effort to identify successive mentions of a word as compared to the ﬁrst occurrence; however, consistent use in terminology (i.e., Organization E’s terminology) has eased this process. Furthermore, we have also investigated possible reasons for not being able to link any semantic unit to our validation model (see §9.3.2). Second, with respect to indication, we have clearly added no or non in a semantic unit to indicate the negation of a practice or element (see Fig. 9.2). Since we are interested to use the interview transcripts to answer our research questions and not compare interviews or interviewees individually, we have not paid much attention to the use of adjectives or other semantical information (such as understated or overstated words). Third, with respect to representation and interpretation, we have performed the content analysis of the 38 interviews in a phased approach. This approach allowed us to reﬂect on possible ambiguities in terms used within our research group.
9.5 Conclusions We have conducted a survey at a large agile multi-site organization (Organization E) involved in global software development to identify how architectural knowledge actually is shared across development sites. We have analyzed the results of 38 interviews held with employees from three development sites active in two large projects of the organization. Analysis of the results and relating them to our validation model helps to identify the pros and cons of using architectural knowledge and architectural knowledge management practices.
We conclude that architectural knowledge management practices that promote decentralization get much more attention than those promoting centralization at the agile GSD organization. Organization E uses practices that focus on interaction and knowledge sharing bottom-up, e.g., between employees individually instead of putting for
136 9.5. Conclusions
ward (centralized) guidelines and tools. This focus on decentralization leads to an emphasis by Organization E on personalization practices (e.g., bringing knowledge workers together) as compared to codiﬁcation practices.
Finally, we identiﬁed one additional useful practice for architectural knowledge management in GSD: ‘peered sites’. This practice covers activities that support a balance in decision-making power across sites.
137 10 Conclusions
In this thesis, we have studied how organizations involved in global software development perform architectural knowledge management activities. We have studied several organizations and developed and validated a series of architectural knowledge management practices to help overcome challenges involved GSD. In this chapter, we revisit the research questions posed in Chapter 1 and summarize the answers provided by our research. Furthermore, we provide a broader perspective on the results or our research and point out directions for further research based upon this work.
10.1 Contributions In this section, we revisit the research questions answered in this thesis and summarize the answers our research provided.
In this thesis we have studied how architectural knowledge can be managed in organizations that are involved in global software development. As shown in Fig. 1.2 in Chapter 1, we have elaborated this central research question using a multi-disciplinary approach leading to four more detailed research questions. In this section, we ﬁrst answer these detailed research questions in §10.1.1 through §10.1.4. Next, in §10.1.5 we revisit our central research question.
10.1.1 How is architectural knowledge used? (RQ-1) Recent advances in the discipline of software architecture strengthen the notion of architectural knowledge as pivotal to prevent design erosion and reduce maintenance costs.
In Chapter 2, we report on a study that is aimed at identifying how architectural knowledge in fact is used in the ﬁeld. By collecting Dutch practitioners’ views on the use of so-called use cases for architectural knowledge and combining their responses, we identiﬁed ﬁve main clusters that describe the use of architectural knowledge: ‘use as an architectural decision set’, ‘use for taking decisions to address the problems or concerns of stakeholders’, ‘use for tracing decisions from requirements, via design, to the implementation’, ‘use for performing risk or tradeoff analyses’, and ‘use for stakeholder communication’. We used the responses of the practitioners and constructed the mindset of the architect, relative to these ﬁve clusters.
Our study answers RQ-1 in that it shows that the mindset of architects is focused on delivering a solution and capturing the related architectural decisions. Consequently,
we conjecture that a so-called micro view on software architecture largely is in place:
architects are focused on developing an architecture for a speciﬁc solution and (more and more) on capturing the architectural decisions and rationale for that solution. In addition, the architectural knowledge is used for communication with stakeholders on the progress of the solution. What lacks in the mindset of architects is a view that exceeds speciﬁc architectures but puts architectures in context by validating the architectures and the architectural decisions that led to them by means of analyses and assessments.
10.1.2 What are practices for managing architectural knowledge in a global software development environment? (RQ-2) In this thesis, we report on several studies that aim to identify practices for architectural knowledge management in global software development, and hence provide an answer to RQ-2. We have identiﬁed the approaches that typical GSD organizations adhere to in ensuring compliance across development sites. In Chapters 3 and 4, we show that practices related to the development process can sufﬁce (at Organization B) and are needed (following the suggestions made at Organization A) to further secure compliance with architectural rules. These practices pertain to communication of the architectural knowledge across sites, to manage deviations of architectural decisions (i.e., manage non-compliance), and to explicitly perform compliance veriﬁcation activities.
In Chapter 5 we learned, by studying software product assessments performed at Organization C, that the quality of software products developed using GSD is not further increased by capturing architectural knowledge in the software products. Hence, we have not found any reasons that the product counterpart of the aforementioned process practices for architectural knowledge management is important in GSD.
Building upon the insight gained thusfar, we performed an extensive literature study in the discipline of requirements engineering to identify practices that could prove useful in the related ﬁeld of software architecture. In Chapter 6, we report the resulting practices. The seven practices identiﬁed mainly support a personalization strategy towards knowledge management; frequent interaction and communication between practitioners involved in the software architecture that reside at different development sites is advocated. Only one of the practices purely supports a codiﬁcation strategy towards knowledge managment; codifying knowledge in a repository for architecture artifacts.
The practices are described in detail in §6.3, starting on page 86.
We used the practices that were distilled from the literature, augmented the practices with some organization-speciﬁc experiences and practices, and determined the perceived usefulness of the combined set of practices at Organization D. This case study, reported in Chapter 7, provides us with conﬁdence that the practices distilled are regarded as useful. Several practices (e.g., traveling to other project locations) are deemed particularly useful since this study showed that software development projects that evolve towards using three sites experience a critical need to plan for (the implementation of) these architectural knowledge management practices in advance.
10.1.3 How can architectural knowledge management (practices) in global software development be supported (by tools)? (RQThe use of architectural knowledge in global software development can further be strengthened by providing practitioners with appropriate tools. For answering RQ-3 we have performed a study (reported in Chapter 8) on the use of wikis and semantic wikis to implement practices for architectural knowledge management in GSD.
First, we identiﬁed to what extent the architectural knowledge management practices for GSD may be implemented using wikis. We related the practices to generic wiki functionalities and conclude that wikis form a good mechanism to implement a hybrid strategy for managing architectural knowledge in GSD. Furthermore, we concluded that a substantial part of the AKM practices may be implemented using wikis.
Second, we implemented three use cases for architectural knowledge in a semantic wiki. The use cases we implemented support the architect in reasoning with architectural knowledge, independent of location, time zone, or socio-cultural borders. Once the architectural knowledge is captured in the semantic wiki, it may help in achieving the beneﬁts of GSD.
10.1.4 Which practices for managing architectural knowledge are used in a global software development environment? (RQ-4) During our research, we have obtained a good overview of the major building blocks that constitute architectural knowledge. We performed a case study at Organization E to identify how architectural knowledge in fact is used in a typical global software development organization by validating the use of the architectural knowledge management practices for GSD. This helps us to answer RQ-4.
The results of the study show that architectural knowledge management practices that promote decentralization get much more attention than those promoting centralization at Organization E. Consequently, the practices that support a personalization strategy towards knowledge management are more often used than those that support a codiﬁcation strategy. Furthermore, we identiﬁed one additional useful practice for AKM in GSD: “peered sites”. This practice covers activities that support a balance in decision-making power across sites.
By comparing these results with the previous studies reported on in this thesis, we reassess the usefulness of the ‘peered sites’ practice by pointing to several symptoms observed at the other case study organizations: the architectural knowledge management practice ‘cross-site delegation’ was deemed useful at Organization D since it was not explicitly planned for in projects that evolved to using three sites. Also, we observed that the various sites of Organization B regard each other as peers, setting a shared goal for the project activities, which contributes to shared team understanding.
10.1.5 How can architectural knowledge be managed in a global software development environment?
In this thesis we have identiﬁed and validated a series of practices for architectural knowledge management in global software development. The practices primarily focus on measures in the process to ensure smooth cooperation and collaboration between various stakeholders across multiple development sites involved in architecting activities.
A minority of the architectural knowledge management practices actually focuses on the infrastructure that is recommended to be present in GSD organizations: ‘having a shared conﬁguration management system’ and ‘having a single repository for architecture artifacts’. These practices allow for adequate codiﬁcation of architectural knowledge the practices that subsequently be shared using other architectural knowledge management practices.