«This research has been partially sponsored by the Dutch Joint Academic and Commer- cial Quality Research & Development (Jacquard) program on Software ...»
We can identify two reasons for this. First, this use case requires that a practitioner is able to cancel an architectural decision. Consequently, the practitioner should determine the decision that needs to be cancelled. This requires the practitioner to make a review iteration. Second, this use case does not directly contribute to the forward-engineering paradigm we identiﬁed when we analysed the Assessment use cases. Other use cases in this cluster, such as ‘reuse architectural decisions’ and ‘retrieve an architectural decision’ are deemed important by all architectural roles and at all architecture levels. These results show that the practitioners regard architectural decisions as an important asset to be reused in developing a speciﬁc architecture.
34 2.5. Threats to Validity
In addition to the results listed in Table 2.5, we make another observation. A difference exists with respect to the perceived importance of use cases between the clusters Communicator, Low-level, and Specialist on the one side, and High-level on the other side. The cluster High-level regards more clusters of use cases important than the other clusters. A possible reason lies in the fact that practitioners in the High-level cluster have a wider perspective on architecture and stakeholders involved, whereas practitioners in the other clusters have a more narrowed focus on architecture. This corresponds with the variety of roles and activities of a software architect listed in (Hofmeister et al., 2000).
2.5 Threats to Validity We describe the threats that our case study faced according to (Kitchenham and Pﬂeeger, 2001-2002; Kitchenham et al., 2002; Runeson and H¨ st, 2009). Our survey was taro geted at practitioners in the Netherlands. By carefully selecting the participants for the survey, we have attempted to minimize a selection bias. Nevertheless, IT service providers are somewhat overrepresented in our population. However, when we compared the responses of practitioners employed at IT service providers with those of practitioners employed at other organizations we did not ﬁnd signiﬁcant differences.
This strengthens our idea that the construct validity of the survey instrument is adequate.
We controlled the population of practitioners we invited to participate in the survey.
However, we do not have insight into the reasons why the non-respondents did not participate. We conjecture that these practitioners did not have enough time to administer the survey or could not relate the topic of the survey to their daily work. Although our survey satisﬁes the guidelines for the number of questions and maximum administration time as posed in (Kitchenham and Pﬂeeger, 2001-2002), our results may suffer from a maturation effect, which means that the attitude of the participants towards the use cases in the survey changes during ﬁlling in the survey. On the one hand, use cases in the ﬁrst half of the survey receive a more important rating than use cases in the second half.
On the other hand, the second half does contain several use cases rated ‘important’.
Therefore, we have conﬁdence that the maturation effect did not inﬂuence our results substantially.
It was not possible to obtain a structure in the use cases for architectural knowledge based on the practitioners’ answers alone. Apparently, the survey answers varied too much to be used for structuring the use cases. A reason for this could be that our study is based on more recent deﬁnitions of architecture as made of a set of architectural decisions (Jansen and Bosch, 2005; Kruchten et al., 2006; Rozanski and Woods, 2005).
Some participants may regard architecture as a set of components and connectors and are not yet used to viewing architecture as a set of architectural decisions and their rationale. Our approach, which uses a list of use cases for architectural knowledge, may have biased the results since the actual mindset of architects may require additional use cases or other approaches to be fully captured. We provide an architectural knowledgeoriented view towards the mindset. In summary, these factors may have inﬂuenced the
352. The Mindset of Architects
internal validity of this case study.
To be able to reﬂect on the answers given, we identiﬁed a clustering based on the use cases for architectural knowledge alone and related the answers to these clusters.
The resulting reﬂection in §2.6 is not only based on the clusters of use cases, but puts the survey results in a broader perspective.
2.6 Discussion and Conclusions We conducted survey-based research on how the practitioners in software architecture in the Netherlands view and use architectural knowledge. Our results reveal the importance of certain use cases for architectural knowledge for the daily work of the practitioners. The individual results have been discussed in §2.4.5. This section reﬂects on these results and draws overall conclusions on the architect’s mindset and the role of architectural knowledge in that mindset.
Fig. 2.1 provides an overview of the results and depicts the major elements of the reﬂection. We approach architecture from two different perspectives. One perspective is focused on developing a solution, i.e., the architecture. The other perspective is focused on the underlying reason for that solution, i.e., architectural decisions and rationale. The clusters of use cases for architectural knowledge are depicted as package symbols. The +-mark or – -mark indicate the respondents’ view on these clusters. We put the clusters in perspective by depicting the evolution between the different results that we identify in practice. By and large, widespread acceptance of architecture veriﬁcation activities preceded architecture validation activities, such as performing risk or trade-off analyses. Similarly, viewing architecting as a forward decision-making process preceded managing the set of architectural decisions, i.e., architectural knowledge management.
Putting stakeholders central in architecture has been an important characteristic across time and perspectives. The remainder of this section describes our views as expressed in Fig. 2.1.
Forward architecting – Architects regard taking architectural decisions and making these decisions explicit as important. Yet, architects tend to focus on only taking architectural decisions to end up with a correct software architecture for a speciﬁc problem. In taking these decisions, architects are supported by e.g., architectural patterns (Buschmann et al., 1996), which provide proven architectural solution fragments for certain problems, and by rationale tools such as gIBIS (Conklin and Begeman, 1988) and QOC (MacLean et al., 1996). We signal an ongoing tension between making architectural decisions and capturing the underlying rationale and other context of these decisions; the time spent on capturing the context is not spent on making new architectural decisions. Consequently, adequate, lightweight tooling is necessary to lower the threshold for capturing the context. Despite the continual tension, progress has been made (Fischer et al., 1996; Conklin et al., 2001).
Architectural decision set – On a more generic level, architects do not regard the architecture as a set of architectural decisions. Although the concept of architectural decisions in itself has gained importance, the architect’s mindset lacks focus on reﬂections on those decisions as building blocks for software architectures. These reﬂections allow for a step back to actually learn from architecture experiences. Furthermore, architects do not (yet) manage or manipulate that set of architectural decisions (i.e., use cases in the cluster Architectural decision set). A reason for this could be that more recent definitions of software architecture in terms of architectural decisions (Jansen and Bosch, 2005; Kruchten et al., 2006; Rozanski and Woods, 2005) are not yet completely transferred to practice. In addition, adequate tool support is necessary to fully exploit architectural knowledge as a set of architectural design decisions across architectures and domains. This thesis provides more information on the topic of tool support for architectural knowledge management in §1.2.7 and Chapter 8.
Assessment – reqs.→arch.→impl. – Software development largely occurs via projects.
Depending on the development approach chosen, the architecting phase can run in parallel during the lifetime of the project or the architecting phase is a distinct phase which leads to a deliverable – the architecture. Based on the results of this study, we conjecture that the latter is the case: the practitioners show an approach in which the architecture is delivered based on the requirements. After that, the implementation is checked against the architecture. Our experience shows that this veriﬁcation phase often is not performed by architects. Architects, often experienced and relatively expensive practitioners, perhaps run off to another project to run the architecting phase at that project.
Consequently, they may not be offered the time to support the design and implementation phase.
Assessment – risk, trade-off analysis – Our study shows that methods and techniques to validate the architecture, such as the Architecture Tradeoff Analysis Method (Clements et al., 2001) or their predecessors, are not embedded within the mindset of architects. A recent presentation on the topic of this chapter given during the Dutch architecture conference revealed that when practitioners do deem performing a risk analysis important, they do not have clear what the role of architectural knowledge is in a risk analysis. Architectural knowledge may support to evaluate the impact of architectural decisions on the resulting architecture; it allows to (re-)consider alternative decisions
372. The Mindset of Architects
as well. Apparently, this rather new view on architecture is not yet generally accepted.
Education on viewing architecture as architectural decisions (Smolander, 2002) as part of architectural knowledge could help overcome this.
Stakeholder-centric – Another beneﬁt of architecture is that it enables communication among stakeholders (Bass et al., 2003). Architecture thus can be regarded as a language to transfer the architect’s opinions and views to those stakeholders. Most use cases in the cluster Stakeholder-centric rate high, which means that the view of ‘architecture as language’ (Smolander, 2002) is generally accepted. Communication of architecture to stakeholders is clearly established in the mindset of architects.
Our study shows that the mindset of architects is focused on delivering a solution and capturing the related architectural decisions. Consequently, we conjecture that a socalled 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. What lacks in the mindset of architects is a view that exceeds speciﬁc architectures but puts architectures in context by validating them, and the architectural decisions that led to them. When architects have a set of architectural decisions at their disposal, this offers the opportunity to interrelate architectural decisions taken in the past to identify learning opportunities for future architecting activities. We conjecture that this macro view may be achieved by applying initiatives that proved valuable in other disciplines, such as ontology engineering (Gruber, 1993; Noy and McGuinness, 2001) onto the domain of (software) architecture.
In summary, the mindset of architects in the Netherlands reveals an approach which is focused on ‘to create and communicate’ rather than ‘to review and maintain’. This reﬂects a general pattern as e.g., highlighted in (Tang et al., 2006). Furthermore, architectural knowledge and the view of architecture as a set of architectural decisions has not yet transferred to industry. Kruchten (2008) discusses a similar balance between an external focus (aimed at outward and inward stakeholders) and an internal focus (aimed at taking the right design decisions, validating them, and documenting them); based on our case study, we conclude that the external focus largely is in place, but the internal focus needs more emphasis. We see two possible approaches to embed the importance of architectural knowledge and design decisions in industry. First, more knowledge transfer is needed on the concepts and intended beneﬁts of this view. Second, it is necessary to collect more empirical data on these beneﬁts in terms of throughput and cost to fully sustain the importance of architectural knowledge and architectural decisions.
2.7 Future Work This chapter describes the mindset of architects in the Netherlands. We provided several reasons for this mindset but acknowledge that additional research is needed on the foundation for this mindset. This additional research could focus on the activities needed to effectively establish the concept of architectural knowledge in the architect’s mindset.
The possible increase in understanding of architectural knowledge by architects may be monitored by using our survey instrument periodically. Moreover, it is possible to
38 2.7. Future Work
compare the mindset of architects in the Netherlands with the mindset of architects at other countries or continents by reusing this survey.
We envision the use cases for architectural knowledge to deﬁne operations on a grid for architectural knowledge. We view this grid to support satisfying the need for architectural knowledge from different perspectives. A model that lies at the basis for this knowledge grid and supports capturing architectural knowledge is provided in (de Boer et al., 2006). A further exploration of this grid is given in (Lago et al., 2010).