«This research has been partially sponsored by the Dutch Joint Academic and Commer- cial Quality Research & Development (Jacquard) program on Software ...»
At this point, our initial hypothesis that the problem for securing the architectural compliance was in the structure of the archnotes seemed to be wrong; all problems identiﬁed pertain to the topics of archnotes, the deviations from archnotes, and the lack of veriﬁcation of compliance with archnotes which prevents securing architectural rules within Organization A. These problems concern the process by which the architectural rules are captured, disseminated, and secured within the organization.
3.4.4 Provide recommendations We used the interviews to collect suggestions on how to improve architectural compliance. In analyzing the compliance topics in the questionnaire, we focused on those answers that indicated that room for improvement was possible according to the participant. Next, we asked the participant how, from the participant’s perspective, this improvement would be most expedient. The collected responses were grouped to form suggestions. The ﬁve suggestions mentioned most often by the interview participants
are listed below:
• Provide an email notiﬁcation of changed or new archnotes to subscribers.
• Let the architecture team prioritize the archnotes according to relevance.
• Let projects write down deviations from archnotes.
• Let the architecture team verify compliance with archnotes.
• Let subsystem architects periodically discuss archnotes in their team meetings.
These suggestions were presented to Organization A’s management to obtain support for improvement of securing architectural rules in the organization – see §3.5.
3.4.5 Classify architectural rules At this point, valuable suggestions are collected from the previous steps of the assessment. Nevertheless, an analysis of the structure of the architectural rules can be performed in order to reveal additional suggestions. This analysis starts with those architectural rules that were regarded as most important for the participants’ daily work.
Expliciting the structure of these rules and applying this structure to other architectural rules is expected to improve the readability of the architectural rules. This in turn would improve dissemination of the architectural rules within the GSD organization.
In expliciting the structure of the architectural rules, the concept of architectural views is used. Architectural views (Clements et al., 2003) prove valuable in structuring architectural knowledge, such as architectural rules.
During this step, the existing architectural rules are analyzed to determine whether they are structured using architectural views. If this is not the case, existing view models such as the ones described in (Kruchten, 1995; Soni et al., 1995; Clements et al., 2003) can be recommended.
Based on a study of the most important archnotes, we observed that they contain a variety of rules pertaining to the architecture. Furthermore, the architectural rules serve as an aid for multiple stakeholders. For example, an engineer would like to learn how the subsystem’s code tree is organized to locate software assets. On the other hand, the conﬁguration manager would like to learn how the code tree is packaged into a subsystem release to verify that a subsystem release is made correctly. Currently, the archnotes do not distinguish between stakeholders and their concerns. This hampers a stakeholder in ﬁnding the right information in the archnotes. Therefore, we recommended a classiﬁcation of the architectural rules. A classiﬁcation would improve ﬁnding the right architectural rules and, consequently, improve complying with these
rules. We proposed a classiﬁcation in two ways:
• A speciﬁc architectural view. At the moment, the archnotes are not structured according to views. The architecture team could use the most important archnotes as perceived by the audience of the archnotes as a starting point. Next, the architecture team could reclassify the architectural knowledge in the archnotes and indicate what knowledge is of particular interest for what role from a compliance perspective. We already learned that the dynamic aspects of the software architecture are underexposed by the architectural rules. Speciﬁc attention could be directed towards closing this gap by reverting to the process view described in (Kruchten, 1995).
• A classiﬁcation according to importance of compliance with these rules. The architecture team could indicate the relevance for compliance with architectural rules. Possible suggestions to discriminate in relevance include cost of noncompliance (“what will non-compliance with this rule cost me?”) or interoperability (“what subsystems need to be changed when this architectural rule is issued?”).
Organization A regarded these suggestions as helpful to improve securing the archnotes. However, most of the suggestions of the participants done so far pertained to the
54 3.5. Results of the Case Study
process by which archnotes are created and disseminated. We concluded that the organization deems these process-related suggestions as more feasible to achieve improved compliance with the archnotes.
Introducing views in archnotes improves the structure since target stakeholders and concerns are explicitly addressed – this may improve the use of the archnotes. Moreover, formalizing the architectural rules in the archnotes enables compliance checking, which would be an incentive to use the archnotes as well. We also observed in this case study that formalized mechanisms such as change requests are succesful in use. In conclusion, we hypothesize that a change in formalization of the archnotes could improve the process.
3.5 Results of the Case Study The case study led to several results. First, Organization A gained insight into the potential audience of architectural rules and the average usage of the rules. Second, questionnaire analysis and interviews revealed that the main problem with securing architectural rules within Organization A was not so much in the rules themselves, or in the structure used to capture them. Rather, the real problems pertained to the process by which the rules are captured, disseminated, and compliance to the rules is secured within the organization.
In order to overcome these problems, we collected ﬁve speciﬁc improvement suggestions from the interviews. Next, these suggestions were presented to the management of the software development organization. After a period of reﬂection, the management decided to support four out of ﬁve improvement actions. Only the suggestion to send out change notiﬁcations of architectural rules was not supported, because management thought that this would result in an overloading of electronic communication.
The supported actions all aim to improve the process by which architectural rules are used within Organization A and do not so much concern the way in which architectural
rules are structured. Below, we list the four supported improvement actions:
The architecture team prioritizes the archnotes according to relevance – The priority is based on the architecture team’s knowledge of the archnotes themselves and the insight gained from this case study. Difference in relevance is supported by the results of the interviews in that some archnotes do not discuss what the organization would call “architecture”, and that architectural rules on certain topics are missing. Furthermore, this prioritization offers Organization A the possibility to tailor e.g., the dissemination process or compliance veriﬁcation process of a speciﬁc archnote.
Architects periodically discuss the archnotes in (subsystem development) team meetings – Although the fact that archnotes exist is mentioned in subsystem development team meetings, the contents of archnotes are not discussed. This relatively little attention does not result in engineers paying attention to the rules. Addressing and explaining the rules instead is expected to increase the awareness of the rationale behind certain rules which is a prerequisite for compliance – it is expected to reduce the notinvented-here-syndrome. Explaining why a rule is the way it is (Tyree and Akerman,
553. AKM Practices for Compliance in GSD
2005) instead of just issuing the rules results in better understanding and compliance.
In addition, we suggest that the architecture team uses techniques such as ‘traveling architects’ (Corry et al., 2006) and visits other development sites more regularly.
Visiting a development site and discussing archnotes helps to increase the number of employees from that site that read and understand the archnotes.
Projects write down deviations from architectural rules – Several projects deviate from certain architectural rules for the sake of the project. Often, this fact is known, but not addressed by either changing the rule that was broken or issuing a ‘known deviation’ to the architectural rule. Not communicating this deviation results in a lack of clarity about the authority of the rule. To prevent this, projects should provide a written statement that they deviate from an architectural rule, including the rationale for this deviation. Next, these written statements are sent to the architecture team to obtain approval.
Verify compliance with the architectural rules – Compliance with architectural rules currently is not veriﬁed. Not verifying rules that are mandatory leads to a certain amount of indifference with engineers (“it probably is not that important then... ”). This indifference is tackled by letting engineers include the architectural rules as explicit criteria in their regular review meetings. In addition, the quality assurance ofﬁcer veriﬁes that these reviews have been performed correctly. Verifying compliance leads to insight into the extent to which the software that is developed complies with the architectural rules set for it.
3.6 Conclusions Architectural rules are necessary in guiding, coordinating, and communicating software development efforts across multiple development sites. Architectural rules require additional guidelines on how to disseminate and secure the architectural rules within the different development sites to achieve compliance. This chapter describes a method for assessing organizations involved in GSD to determine deﬁciencies in securing architectural compliance. Application of the method on a case study showed that an explicit role of the enforcing organizational unit and periodic communication of architectural rules across all sites is of paramount importance. Suggestions for lowering the not-inventedhere-syndrome of the architectural rules at the development sites have been identiﬁed and are currently implemented.
56 4 Reassessing the Need for Practices for Architectural Compliance In this chapter we extend the research on compliance practices by comparing Organization A and the results obtained during the previous study with a second organization, Organization B, involved in global software development. We describe how each organization uses practices for architectural compliance to overcome challenges innate to GSD. This study shows a difference in the way both organizations use compliance practices; based on a detailed comparison, we conclude that a combination of architectural rules and compliance practices proves valuable in handling GSD challenges.
4.1 Introduction Global software development faces challenges additional to those of collocated development. The primary obvious difference is that software engineering practices are performed at geographically separate locations. This difference introduces challenges that have been reported in the literature (Herbsleb et al., 2001; Holmstr¨ m et al., 2006), o ˚ such as temporal, strategic, and socio-cultural challenges (Agerfalk et al., 2005). Some promising solutions to address these challenges have been identiﬁed (Herbsleb et al., 2005; Mullick et al., 2006), but their real contribution cannot yet be fully distilled from practice because empirical evidence is lacking.
Some of the challenges in GSD originate from the architecture of the software.
The architecture can induce dependencies between software engineering tasks such as managing synchronization and meeting a release schedule, see e.g., (Bass et al., 2007b;
Conway, 1968). As with collocated development (Boasson, 1995), architectural rules can help to overcome some of these challenges in GSD. Architectural rules are principles and statements about the software architecture that must be complied with throughout the organization (see Chapter 3). We saw in Chapter 3 that where architectural rules concern the architecture as a product, additional measures pertaining to the processes may be necessary for successfully implementing that architecture.
Although using architectural rules seems beneﬁcial for a distributed setting, we lack detailed insight into what kind of architectural rules are generally applied in a GSD en
574. Reassessing the Need for Practices for Architectural Compliance
vironment. In addition, we do not know in what way these architectural rules contribute to overcome challenges speciﬁc to GSD.
In this chapter, we provide an overview of the major GSD challenges as mentioned in the literature, and reﬁne them into seven issues. For each issue, we list possible solutions and describe to what extent these solutions can be expressed as architectural rules. Next, we use this overview to study two organizations involved in GSD. We determine what practices are used to overcome the various issues. Our study reveals that architectural rules pertaining to the product (i.e., the structure of the software) and additional measures on the process are relevant. For example, allowed dependencies between subsystems may be deﬁned in architectural rules, but so need the processes to verify compliance with these rules.
This chapter is structured as follows. In §4.2 we provide an overview of related work in the ﬁeld of software architecture, architectural rules, and global software development. Next, §4.3 provides an overview of the challenges that exist in GSD. This section also addresses possible solutions to overcome these challenges as identiﬁed in the literature. In §4.4 we show two organizations overcome these challenges in practice.