«This research has been partially sponsored by the Dutch Joint Academic and Commer- cial Quality Research & Development (Jacquard) program on Software ...»
We selected architectural knowledge management practices for GSD from the literature sources by identifying best practices or experiences that were reported. Initial theories that were not validated at all were not selected as a basis for our work.
A. Have a repository for architecture artifacts and architectural decisions (Clerc, 2008) – This practice intends to build a repository to store architectural decisions including the rationale of these decisions. 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. Furthermore, expanding or linking existing knowledge bases from different sites can prove beneﬁcial; existing knowledge bases can be connected, creating a custom shell with preloaded knowledge (de Boer et al., 2007; Neches et al., 1991).
B. Have a clear organization structure with communication responsibilities across sites (Clerc, 2008) – This practice intends to maintain open communication lines between well-deﬁned stakeholder roles. This practice may be implemented by creating roles with clear responsibilities and by assigning these roles to the distributed stakeholders. Furthermore, it is important to indicate which roles need to communicate with each other in e.g., structured meetings.
C. Share relevant architectural knowledge to all sites (Clerc, 2008; de Boer et al., 2007) – When software development occurs geographically distributed, the need arises to share information between different stakeholders on different sites. Software development professionals require awareness of the architectural knowledge needed to perform their work effectively. Knowing who knows what (e.g., using skills management (Rus and Lindvall, 2002) or ‘yellow pages’ (Clerc et al., 2007a)) can prove to be beneﬁcial.
112 8.4. Implementing AKM Practices for GSD with Wiki Functionalities
D. Urgent request (or: quickly collect information on an architectural topic of interest) (Clerc, 2008) – During the architecting phase, it can be necessary to, at a given moment in time, collect information on a speciﬁc architectural topic in order to proceed with developing the architecture (e.g., the availability of a certain infrastructure component which could be reused across projects). Obtaining a quick response helps in not deterring design activities.
E. Propose and rank alternatives when taking decisions (de Boer et al., 2007) – Constructing an architectural design essentially focuses on taking well-founded architectural decisions based on a ranking of one or more alternatives considered. This decisionmaking process in fact is the core of architectural knowledge management.
F. Ensure traceability of architectural knowledge (de Boer et al., 2007) – One of the important possible uses of architectural knowledge is the ability to trace back architectural decisions made and identify what architectural concerns lied at the basis of the architectural decision and what alternatives were considered for that decision. Lowered traceability of architectural knowledge has led to probable causes for problems with architectural knowledge management such as an invisible decision-making process to different sites and other knowledge sharing problems.
G. Frequent interaction across sites (Clerc, 2008) – In GSD, the geographical distance and possible time difference burden effective sharing of architectural knowledge. This may result in language and terminology problems. More frequent interaction across sites helps to address these problems. In addition, more frequent interaction help in building trust across sites (Clerc et al., 2009).
8.4.2 Mapping architectural knowledge management practices for global software development onto wiki functionalities Now that we have provided an overview of generic wiki functionalities in §8.3 and a list of architectural knowledge management practices for global software development in §8.4.1, we now show how we can map the practices onto the functionalities. This mapping was constructed using the insights gained in performing the critical analysis of the literature for wiki functionalities and architectural knowledge management practices for GSD.
Table 8.1 shows how wiki functionalities can be used to implement architectural knowledge management practices in GSD.
In this ﬁgure, an arrow between an architectural knowledge management practice and a wiki functionality indicates that the architectural knowledge management practice can be implemented with the designated wiki functionality. We describe each of relations between architectural knowledge management practices for GSD and associated wiki functionalities in turn, from the perspective of the architectural knowledge management practices.
A ‘repository for architecture artifacts and architectural decisions’ can be implemented on a wiki because (codiﬁed) architectural knowledge can be stored in the wiki using the functionality to create a multi-media base. Using this multi-media base, it is possible to store text, graphics, audio, and video fragments, all of which may contain architectural knowledge. Hence, wikis can serve as a repository for architectural
knowledge, cf. (Farenhorst et al., 2007a; Farenhorst and van Vliet, 2008). Furthermore, to be able to search the repository effectively, search functionalities of wikis can be employed. We acknowledge that even more structure in a wiki (e.g., using a semantic wiki) can be even more helpful in excavating architectural knowledge from the knowledge base using reasoning rules and automated querying. For a prototype and a further discussion, see §8.5.2 and §8.7.
A ‘clear organizational structure with communication responsibilities across sites’ can be partially implemented by using the wiki functionality to create proﬁle pages for users and/or groups detailing on their responsibilities. Moreover, authentication of users to parts of the wiki content can be used to implement communication structures akin to the organizational structure that was set up. Architects, for example, can distribute the rights to edit architectural knowledge on the wiki to designated groups of people (e.g.,
114 8.4. Implementing AKM Practices for GSD with Wiki Functionalities
senior developers) and thus protect the architectural knowledge from manipulation by others. Yet, additional effort is necessary to install and empower the organizational structure and the stakeholders in their responsibilities. A (project) manager should cater for this.
The architectural knowledge management practice to ‘share architectural knowledge to all sites’ can obviously be implemented by sharing information to all participants. When content is provided on the wiki, the pull mechanism is employed where stakeholders visit the wiki to consume the knowledge. Alternatively, rss feeds can be employed to push relevant architectural knowledge to certain stakeholders, or to notify subscribed stakeholders if new architectural knowledge emerges. With such a push mechanism implemented effectively, users don’t need to search the wiki themselves (Farenhorst et al., 2007b; Lago et al., 2010).
To ‘quickly collect information on an architectural topic of interest the information ﬁrst of all needs to be made available. This can be effected by allowing stakeholders to collaboratively capture architectural knowledge on the wiki. Adequate search functionality, in addition, may help stakeholders to search for architectural knowledge (see the aforementioned description on the repository for architectural knowledge). This practice, however, can only be fully implemented when stakeholders respond quickly to a request for information that currently is not captured in the wiki content; wikis cannot help in this. Hence, this architectural knowledge management practice for GSD can be only partially implemented using wiki functionality.
Using the inherent wiki functionality of collaborative authoring, it is possible to ‘propose and rank alternatives when taking architectural decisions’. However, wiki functionality does not allow to rank alternatives automatically; this requires expert knowledge of the architect – knowledge that in turn may be captured on the wiki to enrich the base with architectural knowledge.
The practice ‘traceability of architectural knowledge’ involves understanding of the alternatives that were considered when taking an architectural decision. This practice can be implemented using the history or (back-)tracking functionality of wikis. Earlier versions of wiki content in which the architectural decision is captured allow for a replay of the decision-making process over time, including identifying how the need for the decision originated and what stakeholders were involved in taking the decision. Moreover, the search functionality of wikis can help in excavating the architectural knowledge.
Apart from that, traceability of architectural knowledge can be implemented using a structure such as a wiki template or semantic wiki (see §8.5 and §8.7).
The architectural knowledge management practice for GSD ‘frequent interaction across sites’ is not covered by any of the generic wiki functionalities. Wikis nor any other technological functionality can urge a GSD organization to interact more frequently. Of course, useful technological means (e.g., videoconferencing or chatting) can be employed when the organization has chosen how to implement frequent interaction. We regard it as the responsibility of the project manager to cater for adequate frequent interaction across the sites involved in the GSD project.
1158. Supporting AKM in GSD
8.5 Implementing a Semantic Wiki The research described thusfar in this chapter provides us with conﬁdence that wikis are a good means to support the architectural knowledge management practices for GSD. To further substantiate the results obtained in this study, we have developed a prototype implementation of an architectural knowledge sharing environment using a semantic wiki.
Semantic wikis extends wiki ﬂexibility by allowing for reasoning with structured data:
semantic annotations to that data correspond to an ontology that deﬁnes certain properties (Schaffert et al., 2008; Liang et al., 2009). de Boer and van Vliet (2011) reports on experiences in introducing semantic wikis for architectural knowledge management in e-government and distirbuted development.
For the prototype, we developed a software engineering ontology and implemented three use cases for architectural knowledge using this ontology. The use cases are described in §8.5.1. Next, §8.5.2 describes the implementation of the use cases in our prototype, SE-Wiki2.
8.5.1 Use cases implemented in a semantic wiki This section elaborates on a three use cases for architectural knowledge. The use cases are concrete elaborations of the use cases described in Chapter 2. The use cases can be deployed in global software development organizations in that it builds upon knowledge that is readily available in the semantic wiki, regardless the development site at which it is created. Furthermore, the use cases are centered around the architect, a potential rotating or distributed role.
The use case of software reuse supports the architect to if existing software can be reused to implement a new functional requirement. The use case changing requirement supports the architect in updating an architecture design according to a changing requirement. The use case design impact evaluation supports the architect in evaluating and identiﬁng the impact of changing requirements on architecture design. The use cases are described following a technique introduced in (Lago et al., 2010). The use case scenario is described using a problem and solution description and a detailed description of the scenario.
Scenario 1 – software reuse An architect wants to check if existing software can be reused to implement a new functional requirement, and the new functionality is similar to the existing functionality.
Problem – The architect needs to understand the viability of reusing software to satisfy existing and new functional and quality requirements.
Solution – The architect ﬁrst ﬁnds all the architecture components that realize the existing functional requirements which are similar to the new functional requirement. Then, the architect can trace the existing architecture components to determine what quality requirements may be affected and if the existing software supports the new requirement.
2 This section is based upon joint work with Antony Tang and Peng Liang (Tang et al., 2011).
116 8.5. Implementing a Semantic Wiki
1. The architect thinks that the existing software can support a new functional requirement which is similar to existing functional requirements.
2. The architect selects the existing functional requirements and identiﬁes all software components that are used to realize them.
3. For each software component found, the architect identiﬁes the related architectural structure and the quality requirements.
4. The architect assesses if the existing quality requirements are compatible with the quality requirements associated with the new functional requirement.
5. If so, the architect decides to reuse the components to implement the new functional requirement.
Scenario 2 – changing requirement An architect wants to update the architecture design because of a changing functional requirement.
Problem – The architect needs to understand the original requirements and the original architecture design in order to cater for the change.
Solution – The architect ﬁrst ﬁnds all existing requirements that are related to the changing requirement. Then the architect identiﬁes the decisions underlying the original design. The architect can assess how the changing requirement would affect related existing requirements and the original design.
1. The architect identiﬁes all the related artifacts (e.g., related requirements, architectural design decisions, and design outcomes) that concern the changing requirement.
2. The architect evaluates the appropriateness of the changing requirement with related existing requirements.