«This research has been partially sponsored by the Dutch Joint Academic and Commer- cial Quality Research & Development (Jacquard) program on Software ...»
A speciﬁc, yet extremely important kind of knowledge that needs to be shared is knowledge about the software architecture. In a software architecture, the global structure of the system to be built is decided upon. This structure, among others, should capture the major architectural decisions that led to it (Bass et al., 2003). Capturing these architectural decisions facilitates a better decision-making process in shorter time, saving rework and improving the quality of the architecture (Babar et al., 2007;
Rus and Lindvall, 2002). Hence, it is important to not only capture the resulting architectural design, but also the decisions, including their rationale, that led to that design:
In the GRIFFIN project (GRIFFIN, 2011), we have performed research in the area of architectural knowledge. We deﬁne architectural knowledge as the integrated rep
1259. The Use of AKM Practices in Agile GSD
resentation of the software architecture of a software-intensive system (or a family of systems), the architectural design decisions, and the external context/environment. We have formalized the concept of architectural knowledge in a core model of architectural knowledge (de Boer et al., 2007). Possible reasons for the use of architectural knowledge have been identiﬁed and validated as well, see (van der Ven et al., 2006a) and Chapter 2. In the context of GSD, sound management of architectural knowledge can help to overcome the challenges innate to GSD. Architectural knowledge management can be implemented by performing a series of well-deﬁned practices. In the GRIFFIN project, we have developed and initially validated these practices, see e.g., (Clerc, 2008; Clerc et al., 2007a, 2009).
In the research described in this chapter, we have validated the architectural knowledge management practices for their actual use by conducting a survey at a large agile global software development organization. After having interviewed 38 employees across three development sites and having analyzed the results, we conclude that the architectural knowledge management practices that promote decentralization get much more attention than those promoting centralization. We furthermore identiﬁed one additional useful practice, ‘peered sites’, covering activities that support a balance in decision-making power across sites.
This chapter is structured as follows. First, §9.2 provides the research question, an overview of the organization where we conducted our survey and details the approach used for this research. Next, §9.3 lists the results of the analysis. In §9.4, we discuss the possible limitations that apply to this research. We conclude this chapter in §9.5 with the conclusions.
9.2 Research Question and Approach In this section, we ﬁrst outline our research question (§9.2.1). Next, §9.2.2 provides an overview of the organization where we conducted the survey. In §9.2.3, we describe the approach used for conducting the survey.
9.2.1 Research question Our primary interest lies in validating the set of practices for architectural knowledge management in global software development. In earlier research, we have developed several practices and validated their usefulness in an organization involved in GSD, see Chapters 3, 6, and 7. Table 9.1 provides an overview of the practices, including references to the earlier research. These practices include frequent interaction across sites, prioritizing a set of rules with which the architecture and underlying decisions should comply, writing down deviations from these architectural rules in case of noncompliance (including a rationale for non-compliance), the urgent request mechanism as a light-weight, non-intrusive manner to quickly gain information on a speciﬁc architectural topic of interest, establishing a project structure in which is it clear what the communication responsibilities are, and establishing a single conﬁguration management system in which work products such as documentation, scripts, test cases, and
126 9.2. Research Question and Approach
source code are stored. For an elaborate desccription of each individual practice, we refer to the work referenced by Table 9.1 and included in this thesis. The work presented here aims at a broader evaluation of the use of these practices at another large GSD organization.
Hence, our research question is as follows:
What practices for managing architectural knowledge in global software development are used?
Table 9.1: Practices for architectural knowledge management in global software development
9.2.2 Characterization of the organization We performed the survey at Organization E. Organization E produces high-end printers for the business markets in high-volume printing, wide-format printing and ofﬁce printing. Organization E is based in the Netherlands and has several additional development sites spread across the globe.
The software in these printers manages user interaction, renders images, and controls the print engine. Software for printers is typically developed by several software development teams, plus architects, integrators, and testers. These software teams reside at the various development sites of the organization.
A typical team structure of project teams at Organization E is depicted in Fig. 9.1.
A project manager heads the project and is responsible for its planning, realization, and successful completion. The project manager also agrees upon the high-level speciﬁcations of the project with upper management and marketing personnel. Requirements and speciﬁcations are compiled into product properties by the lead architect in the team.
The speciﬁcations written by the lead architect start from a user-centric view, i.e., sce
narios on how the end-users will interact with the product. For instance, the architect is responsible to decide what happens in case of an interrupt request from the user of the printer (as in how should it function, which software units should be triggered and how should they function), deﬁne the interfaces between these units and the like. Teams also comprise a system integrator who integrates the different software units to build the software system. Additionally, the integrator reports issues encountered during integration and assigns them to the appropriate team or person to be addressed. All three – the project manager, the lead architect, and the integrator – are assigned to a project for its entire duration until the product has been released.
Project teams also include one or more software unit teams that implement the software units. Each unit has a unit leader and a unit architect analogous to the project manager and lead architect at the project level. The unit leader is responsible for planning and organizing. The unit architect transforms the high-level speciﬁcations received from the lead architect into detailed technical speciﬁcations and passes them to the software developers who implement the code and test it. The unit architects are coordinated by the lead architect, who is often the only team member with the overall view of where (or in which units) the different functionalities of the product reside. Most software units are not developed for a single product but their deliverable is tuned and integrated into several products. A software team can develop a software unit for four, or even more, projects at the same time. This challenges system behavior as well as architecture.
As a basis for our research, we selected two large projects. One of these projects primarily involves the Dutch (NL) site and another site, site A. The other project also involves a third site, site B.
Collaboration between the three sites involved in these two projects differs. In the ﬁrst project, which involves the NL site and site A, both sites develop distinct software units and integration of the work done by the sites occurs between the software units. In the second project, involving the Dutch site, site A, and site B, collaboration between NL and site B occurs via co-development of the same software unit, whereas collab
128 9.2. Research Question and Approach
oration between the Dutch site and site A is organized at the level of unit integration, similar to the ﬁrst project.
Organization E successfully applies an agile development methodology to encourage creativity and productivity. The organization is ﬂat and workers are encouraged to be proactive in owning up to work responsibilities. Organization E has deliberately opted for cooperation, as opposed to hierarchy, to foster innovation and entrepeneurship.
Agility does not contradict architecture. The agile development process used speciﬁes that the requirement speciﬁcations and the architecture design speciﬁcations must be approved by the project leaders and the Architecture Council. The lead architect and the unit architects have regular (typically weekly and when needed) meetings to discuss design, and individual teams have their daily meetings.
The agile development methodology that Organization E has been using for the past ﬁve years is based on SCRUM (Schwaber and Beedle, 2001). SCRUM is an agile software development methodology that allows for adaption for use in a GSD setting, see e.g., (Paasivaara et al., 2008; Paasivaara and Lassenius, 2010; Sutherland et al., 2009).
A software development cycle at Organization E typically lasts 8 weeks, with sprints of 2 weeks.
9.2.3 Research approach From the organization, we selected 38 employees working on the two aforementioned projects: 19 were working at the Dutch site, 14 at site A, and 5 at site B. This distribution is proportional to the number of employees at each of the development sites. The roles and experience of the employees ranges from team leaders to designers, architects, and integration responsibles. The majority of these roles has architecting responsibilities.
On average, the employees had 4.45 years of experience in their current role, with a range between 0.5 - 20 years. The employees were working on average 10.33 years at the organization, with a range between 0.5 - 29 years.
We held interviews with the 38 employees individually of about one hour to oneand-a-half hour. The interviews were held according to a predeﬁned questionnaire that was developed in close cooperation with the organization. The topics of the questionnnaire covered communication and collaboration, knowledge sharing, relationship (and trust) issues, and quality and productivity. In all these topics, various subquestions were formulated to collect information for the validation of our model; questions regarding communication, collaboration, and knowledge sharing focused on on how interaction occurs and how knowledge is shared. We video-recorded the interviews to facilitate a thorough analysis afterwards. In a companion article (Manteli et al., 2011), a subset of these interviews is used to study the impact of governance structures on knowledge management.
We performed content analysis on the coded (transcribed) representations of the text to analyze the interview transcripts and validate our research model. Content analysis is a research method that uses a set of procedures to make valid inferences from text (Weber, 1990). This helps in e.g., revealing the focus of individuals, or groups. We examined broken down pieces of text or semantic units (not single words, but ‘word sense’) from each interview transcript with our research question in mind and coded an
1299. The Use of AKM Practices in Agile GSD
swers to the question using an interactive set of concepts; an interactive set of concepts enables us to code what the practitioners actually do, rather than framing it a priori to our validation model. Since we are interested in a possible distinction between architectural knowledge management practices and the sites involved, we code for frequency of the concepts, rather than just their existence (termed ‘conceptual analysis’ by (Weber, 1990)). After we ﬁnished coding the 38 interview transcripts, we linked the individual coded fragments to our validation model by inferencing the meaning of the fragments.
We performed such a mapping for each of the three sites individually to allow us to compare the results across sites. Intermediate results were discussed in our research team to ensure validity (see §9.4). Fragments that could not be mapped onto the validation model are analyzed separately since these fragments could reveal the existence of other practices in use at the organization that can be leveraged.
9.3 Results In this section, we describe the results of our study. The validation of the architectural knowledge management practices for global software development is described in §9.3.1. Next, §9.3.2 provides practices that were found to be performed at, or needed by, the organization, but were not part of our validation model.
We have structured the results per development site. Table 9.2 shows the frequency of references made to AKM practices for GSD.
9.3.1 Validation of architectural knowledge management practices for GSD In this section, we discuss the major ﬁndings of Table 9.2. We combine the ﬁndings of each of the development sites, yet indicate speciﬁc similarities or differences observed.
Fig. 9.2 provides an excerpt of the codiﬁcation and aggregation of concepts to our validation model. In this excerpt, various interaction means (e.g., tools) are shown, and annotated with additional reasons for using these means.