«This research has been partially sponsored by the Dutch Joint Academic and Commer- cial Quality Research & Development (Jacquard) program on Software ...»
6.2.2 A pattern language for describing architectural knowledge management practices In parallel with the literature study, we devised a light-weight pattern language to structure and describe the potential GSD architectural knowledge management solutions posed by the literature. We used the work of (Bass et al., 2007a; Tyree and Akerman, 2005), based on (Gamma et al., 1994) as a basis to deﬁne a light-weight pattern language. We added relevant insights from the ﬁeld of architectural knowledge management, such as the architectural knowledge management strategy organizations may adhere to (Babar et al., 2007; Hansen et al., 1999).
Table 6.1 lists the results.
The elements of this pattern language and its application on describing architectural knowledge management practices may help organizations in making a well-supported choice between architectural knowledge managements practices for application in GSD projects.
6.3 Architectural Knowledge Management Practices for GSD This section lists the practices for architectural knowledge management to overcome GSD challenges, distilled from the literature on the requirements engineering discipline.
When a practice does not refer to any requirements-speciﬁc terminology or process, we have not applied any modiﬁcations. For a practices that does, we translate the given requirements engineering-speciﬁc element to an appropriate counterpart in the realm of architectural knowledge management (see §6.2.1), following the insights from e.g., (van Vliet, 2008). We provide an overview of the changes we made.
6.3.1 Frequent interaction across sites Practice Name – Frequent interaction across sites (Damian and Zowghi, 2002).
Intent – This practice intends to let practitioners from different development sites interact frequently with each other.
Motivation – In knowledge-intensive tasks such as requirements engineering and architecting, 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 helps in building trust across sites, as shown in Chapter 4.
Furthermore, it helps in gaining awareness of the local working context of architects, developers, and other representatives which eases understanding across sites.
Frequent interaction can be implemented in a variety of ways: organizations may use on-site management visits (Bass et al., 2007a) in which technical interchanges on the architecture are held and project status, schedules, and planning issues are discussed.
Alternatively, organizations may utilize cross-site delegation (Bass et al., 2007a) by sending practitioners from remote development sites to the main development site and vice versa.
Prerequisites – Interactions should be planned for and performed regularly. Preference is given to on-site visits. If this appears not to be cost-effective, collaborative technologies such as video-conferencing (Damian and Zowghi, 2002; Clerc et al., 2007b) or wikis (Farenhorst et al., 2007b) could be employed. Furthermore, it is advised to facilitate and improve the decision-making meetings by using a trained human facilitator (Damian and Zowghi, 2002).
Beneﬁts – Frequent interaction helps in maintaining a shared sense of urgency across development sites (Clerc et al., 2007b), which can speed up development time signiﬁcantly.
Drawbacks – No signiﬁcant drawbacks are reported in the literature. Although setting up and maintaining the infrastructure imposes some costs, this is of no major inﬂuence once the infrastructure is used widely across development sites.
86 6.3. Architectural Knowledge Management Practices for GSD
Strategy – This practice supports a personalization strategy, since frequent interaction helps in identifying ‘who knows what’ among practitioners and interaction does not focus on extracting and capturing architectural knowledge in a repository, but on sharing architectural knowledge among practitioners instead.
6.3.2 Cross-site delegation Practice Name – Cross-site delegation (Bass et al., 2007a).
Intent – This practice intends to obtain better integration between teams from different development sites by delegation of team members from a local site to a remote site and vice versa (Bass et al., 2007a); delegation involves the physical presence of a team member of one development site to another development site to work and collaborate with that site.
Motivation – When establishing a remote site, more effort is needed to align objectives and regard each other as peers. Applying cross-site delegation helps in achieving a shared understanding of the architectural problem that needs to be solved (Clerc et al., 2007b). After the delegation period, the delegate may become a liaison (Clerc et al., 2007b; Bass et al., 2007a).
Prerequisites – When applying this practice, it is important that each development site is able to appoint this role to suitable candidates. Consequently, it requires that similar or equal roles (e.g., architects or designers) are present at all development sites.
Beneﬁts – Applying this practice results in an increased speed by which architectural knowledge is disseminated to all development sites. Furthermore, applying this practice establishes a means for more effective future interaction and management of architectural knowledge across sites, since practitioners know whom to contact; as such, the problems to initiate contact are alleviated (Hofstede, 2001).
Drawbacks – Structural traveling, which is implied by this practice, results in costs related to traveling, housing, and facilities costs. Organizations can use a specialized department to gain efﬁciency beneﬁts. Furthermore, organizations need to carefully select the roles that travel and the frequency by which traveling occurs (possibly relative to the development phase).
Strategy – This practice supports a personalization strategy.
6.3.3 Face-to-face project kick-off meeting Practice Name – Face-to-face project kick-off meetings (Damian and Zowghi, 2002).
Intent – This practice intends to establish initial relationships across sites.
Motivation – It is important to align expectations of practitioners from all development sites involved as early as possible in a software development project to prevent delay because of uncertainties later on.
876. Identifying Practices for AKM in GSD
Prerequisites – A group kick-off meeting with practitioners from various sites could be difﬁcult to plan. Although relevant literature reports on the importance of having faceto-face contact (Damian and Zowghi, 2002; Herbsleb et al., 2005), some other noteworthy results are provided as well, e.g., in a large empirical study (Illes-Seifert et al., 2007): in this study, only 4 out of 55 studied best practices concerns face-to-face communication.
Beneﬁts – A shared understanding of the project’s context and goals can be achieved by sharing architectural knowledge during a kick-off meeting. This helps in speeding up the initial phase of the project and ﬁnding the right people across all sites involved in the software development project.
Drawbacks – For large software development projects, a lot of development sites may be involved in determining the architecture for the system to be built. This could lead to planning problems in getting all relevant stakeholders together.
Strategy – This practice supports a personalization strategy.
6.3.4 Urgent request Practice Name – Urgent request (Bass et al., 2007a).
Intent – This practice intends to quickly collect information on a given architectural topic of interest.
Motivation – During the architecting phase, it can be necessary to, at a given moment in time, collect information on a speciﬁc topic in order to proceed with developing the architecture. An example could be the availability of a certain infrastructure component which could be reused across projects. Obtaining a quick response helps in keeping the architecting activities up to speed.
Prerequisites – This practice requires that a distribution mechanism is implemented.
The mechanism should be implemented to be separate from general knowledge sharing mechanisms, since a large number of unrelevant requests, or requests for different expertise areas, lowers the sense of urgency and the motivation of the volunteers. In addition, this network of volunteers with expertise on a variety of technical subjects should be created and maintained. Management support and urge for selecting volunteers is important to achieve this. This practice furthermore requires willingness to share information, and thus a sense of openness throughout the organization.
Beneﬁts – Quick responses to urgent and/or ad hoc questions greatly improves the speed by which architectural knowledge is shared across development sites and, consequently, an architecture for a system can be developed. Currently, low-threshold mechanisms to implement this practice exist, e.g., rss feeds (Farenhorst et al., 2007b).
Drawbacks – It is necessary to establish a basic level of trust between the key individuals from different development sites to allow this practice to be successful – one needs to know ‘who is who’ before one will respond to an urgent request.
Strategy – This practice supports a personalization strategy since it reveals potential sources of architectural knowledge, which then can be accessed through email interaction.
6.3.5 Collocated high-level architecture phase Practice Name – Collocated high-level architecture phase (Bass et al., 2007a).
Intent – This practice intends to create a sound high-level architecture in an efﬁcient way.
Motivation – The architecting phase consists of knowledge-intenstive tasks and is important for outlining the solution structure for the future development phase. In addition, identifying a high-level architecture generally is done in limited amount of time – certainly compared to detailed design and development activities.
This practice may be implemented by arranging for a single location on which architects from the various development sites site meet. In addition, knowledge management tooling should be catered for to capture the design rationale and major architectural decisions during the phase.
Prerequisites – The set of most important quality requirements should be fairly stable.
Requirements engineers and domain experts should be available and participate in this phase.
Beneﬁts – When organizations apply a collocated high-level architecture phase, all relevant issues can be expected to be tackled as early as possible.
Drawbacks – As already described in §6.3.3, bringing together practitioners from different development sites may lead to planning problems.
Strategy – This practice does not support a speciﬁc architectural knowledge management strategy.
The practice collocated initial architecture phase has been adapted from the requirements engineering domain, where it was termed collocated analysis phase (Bass et al., 2007a). The practice describes how functional speciﬁcations are produced as a result of this collocated analysis phase with a high-level architecture as input. Based on the similarities between requirements and architecture (van Vliet, 2008; Hall et al., 2002), we conjecture that a similar practice is applicable for architectural knowledge management in a GSD setting. We are aware that this practice removes the global aspect in GSD by introducing collocatedness. However, this practice does pose additional issues, such as effective sharing of the architectural knowledge of this single location to all development sites, which may be problematic (Clerc et al., 2007a).
6.3.6 Have a clear organization structure with communication responsibilities Practice Name – A clear organization structure with communication responsibilities (Damian, 2007).
Intent – This practice intends to maintain open communication lines between welldeﬁned stakeholder roles (Desouza et al., 2006) within the organization. Organizations may be seen as any logical entity of an organization, including departments, teams, and projects.
Motivation – Delay can occur when practitioners spend time on ﬁnding and reaching the correct person in a given role. Often, it is not the case that information is not available; rather, the information is not shared with the right persons. In earlier research described in Chapter 4, we observed this as well: an organization which applied topdown deﬁnition and communication of architecture principles and an organization with more focus on collaborative architecting practices both followed architectural rules; in the former organization, however, architectural decisions did not sink in properly.
This practice may be implemented by creating roles with clear responsibilities and by assigning these roles to the distributed stakeholders. Furthermore, it should be indicated which roles need to communicate with each other in structured meetings.
Other implementation-speciﬁc suggestions as proposed by (Illes-Seifert et al., 2007) are: communicating more often, communicating immediately as a question arises (see §6.3.4), communicating according to formal rules (see Chapter 4, using a tool such as a wiki, or using common terminology.
The notion of “organization” may be interpreted differently according to the software architecture and development activities at hand. An organization could include a project organization or a department organization serving multiple projects.
Prerequisites – It is important to involve the right people in the meetings that are conducted (Damian and Zowghi, 2003).
Beneﬁts – Cross-functional teams associated with developing a speciﬁc part of the architecture represent social networks whose members beneﬁt from clear identiﬁcation of roles and responsibilities in the architectural knowledge management discipline (Damian et al., 2007). It is important to identify these possible social networks in addition to managing the communication responsibilities.
Drawbacks – No signiﬁcant drawbacks are reported in the literature.