«This research has been partially sponsored by the Dutch Joint Academic and Commer- cial Quality Research & Development (Jacquard) program on Software ...»
For data that lie in Euclidean space, k-means clustering tries to ﬁnd a partition that minimizes the sums of squared errors about the cluster means, which represent their respective clusters. We observed that the optimal distribution of architecture levels in clusters occured when we used ﬁve clusters. We compared the clusters that appeared with k-means clustering with the distance plot provided by classic multi-dimensional scaling. The comparison revealed that we selected the right number of clusters and that we found the correct distribution of elements over the clusters. Consequently, the clusters contain elements that are different in nature and have their overlap reduced to a minimum. We observed the elements in these clusters of architectural levels and labeled the clusters.
The results are shown in Table 2.2. The table shows that distinct clusters provide for the relation of a software system and the hardware it runs on (Systems architecture), the structure of a software system (Software architecture), the structure of the organization or department using the software system (Enterprise architecture), and the process and information ﬂow in or surrounding a software system (Information and process architecture).
Of the most signiﬁcant architecture levels, only Information architecture and Process architecture are very often worked on by a single respondent simultaneously. Consequently, they fall into the same cluster. The remainder of the most signiﬁcant architecture levels each fall into a distinct cluster.
Practitioners can potentially work on different levels of architecture simultaneously.
In spite of that, according to the clusters shown in Table 2.2, practitioners do not do this. They are specialized in working at one speciﬁc level of architecture only. Possible reasons for this are the different technical and interpersonal skill-sets required at each architecture level. For example, practitioners who mainly work on the level of Systems architecture are concerned with CPU performance, interrupt levels, and other technical topics, whereas practitioners who mainly work on the level of Process architecture are concerned with implications of decisions on working processes, which places less requirements on technical skills. Required interpersonal skills can vary at different architecture levels as well. As the topics that require to be communicated get less technical, the potential audience could grow. Consequently, the set of stakeholders with which to communicate grows from technology-oriented stakeholders to include more business-oriented stakeholders as well.
2.4.3 Architectural roles The participants indicated the architectural roles they typically fulﬁll. The survey contained a list of roles, including ‘architect’, ‘reviewer of architecture’, ‘project manager’, and ‘developer’.
We repeated the same analysis as described in §2.4.2 to identify clusters of roles typically fulﬁlled by a single respondent. The optimal distribution of architectural roles in clusters occurred when we used ﬁve clusters. Again, we labeled the clusters. The results are listed in Table 2.3.
The clusters labeled High-level and Low-level show that, apparently, architectural roles are related based on level of abstraction with respect to a software system and practitioners work at one speciﬁc level of abstraction. Our results also show that practitioners generally do not switch between the different levels. This contradicts with the view on the role of a software architect as an implementor (Hofmeister et al., 2000);
according to our survey, architect do not design or implement that often. Furthermore, the roles ‘architectural educator’ and ‘project manager’ share a communication responsibility towards a variety of stakeholders. Consequently, we label this cluster Commu
2.4.4 Clustering the use cases We listed the use cases for architectural knowledge from (van der Ven et al., 2006a) and asked the practitioners to indicate the importance of each use case for their daily work and whether they actually performed the use case. We used the answers of participants of the use cases to reveal an underlying structure in the use cases. The structure would excavate similarities between use cases based on the answers and would allow us to cluster the use cases accordingly.
First, we used principal components analysis (Anton, 2005) to identify the underlying structure in the use cases for architectural knowledge based on the respondents’ answers. We could not ﬁnd any underlying structure; the variance in the scores of the use cases was explained by one main principal component.
Since the principal components analysis did not lead to a clustering of the use cases, we next tried to cluster the use cases based on the purpose of the individual use cases.
Most use cases for architectural knowledge could be clustered relatively easily, e.g., some use cases clearly dealt with stakeholders only. Consequently, we grouped these use cases into a single cluster. For some use cases, clustering was more difﬁcult. These use cases could be grouped into multiple clusters, e.g., ‘add an architectural decision’ could point at a forward architecting approach, but at the same time assumes that a set of architectural decisions exists to which the new decision is added as well – see Table 2.4. We identiﬁed the most appropriate cluster for these use cases by analyzing the questionnaire results of the participants for these use cases. We compared the answers on a use case with the average of the answers for each candidate cluster. We assigned the use case to the cluster with the highest similarity in answers (see §2.4.5). The interpretation of the survey results also led to the cluster labels. Table 2.4 lists the resulting clusters of use cases for architectural knowledge.
The use case cluster Architectural decision set presupposes that a set of knowledge entities (i.e., architectural decisions) and relations between these knowledge entities exist (see (Kruchten et al., 2006) for a list of possible relations). The use cases in this cluster are aimed at managing that set. Several other use cases have to do with assessing or reviewing an architecture. Within this Assessment cluster, we distinguish between use cases that imply a forward-engineering approach to architecture (i.e., from
requirements, to architecture, to implementation), and use cases that target at performing different kinds of analyses and reviews. The ﬁrst set aims at veriﬁcation of the architecting activities (“are we still on the right track?”) whereas the second set aims at validation. Seven use cases form the cluster Stakeholder-centric. These use cases concern identiﬁcation of stakeholders and communication of the architecture to speciﬁc stakeholders. The cluster Forward architecting, ﬁnally, consists of use cases that create, request, reuse or remove architectural decisions.
Next, we identiﬁed outliers by deﬁning an upper and lower limit of importance: within the possible range of scores from 1 – 52 we regard a use case with a score of ≥ 3.5 as ‘important’ and a use case with a score of ≤ 2.5 as ‘not important’. The results are listed in Table 2.5. Each row in Table 2.5 relates a cluster of use cases for architectural knowledge to both the clusters of architectural roles and the clusters of architecture levels. The importance of each use case cluster for each cluster of architectural roles and each cluster of architecture levels is provided. Important clusters are marked ‘(+)’, not important clusters are marked ‘(–)’. Impartial results are not listed in the table. The ﬁndings are discussed below. An extensive discussion of their implications is given in §2.6.
Architectural decision set – The use cases for architectural knowledge within the cluster Architectural decision set assume that a set of architectural decisions is at the practitioner’s disposal. In terms of the use cases, architecting thus boils down to managing and manipulating that set of architectural decisions. Table 2.5 shows that viewing architectural knowledge as a set of decisions has not been established at the Software architecture and Systems architecture levels. Furthermore, viewing the architecture as a set of decisions is regarded as not important for Communicator and Specialist roles.
High-level and Low-level roles (i.e., ‘architects’ versus ‘designers’ and ‘developers’) deem these use cases neutral. Apparently, the view on architecture as a set of architectural decisions (Jansen and Bosch, 2005; Jansen, 2008) and managing that set has not yet transferred to practice, nor is it of particular value to the practitioners.
Assessment – reqs.→arch.→impl. and Assessment – risk, trade-off analysis – The cluster labeled Assessment – reqs.→arch.→impl. covers traceability of architectural decisions to the actual implementation, the relation between decisions themselves, and from architectural decisions back to the requirements that have been set for the information system. Especially respondents who strongly contribute to the role clusters 21 being not important, 5 being very important.
Table 2.5: Importance of use case clusters per cluster of architectural roles and cluster of architecture levels.
(+) denotes importance, (–) denotes unimportance
High-level, Low-level and Specialist (see Table 2.3) regard these use cases as important. These roles are the ‘construction’ roles with respect to architecture. This conﬁrms our idea that practitioners involved in the construction of architectures have a need for traceability of architecture. The use cases in the cluster Assessment – risk, trade-off analysis are not regarded as important by the High-level cluster of architectural roles.
Furthermore, especially practitioners engaged in Software architecture regard the use cases in this cluster as not important.
A difference that exists between the two subclusters within Assessment could lie in the architect’s mindset. The results of the cluster Assessment – reqs.→arch.→impl.
reveal a mindset with a linear (i.e., non-iterative) approach to designing an architecture that satisﬁes the posed requirements and subsequently have the implementation satisfy the architecture. Use cases that offer traceability in this approach are regarded as important. The use cases in the cluster Assessment – risk, trade-off analysis, on the other hand, all are aimed at having an intermediate period of reﬂection to verify what risks apply, or what quality attributes could be affected by certain architectural decisions.
These use cases are not directly related to either requirements or implementation.
In summary, in contrast to e.g., (Bass et al., 2003; Hofmeister et al., 2000), who state that architecture offers a good means to assess the correctness and suitability of the desired solution, our results reveal architects regard the use cases for architectural knowledge in the Assessment – risk, trade-off analysis cluster as not particularly important. Literature points out that an architecture enables us to assess the design maturity, perform incremental, iterative design reviews, and periodically identify the largest risks pertaining to the architecture. Apparently, these beneﬁts of architecture are not valued
332. The Mindset of Architects
by our respondents, which is surprising.
Moreover, the use cases in the cluster Assessment – risk, trade-off analysis aim at ﬁnding possible problems in a certain architecture. Since practitioners do not regard these use cases as important, we might infer that practitioners do not favour a period of reﬂection in which the current state of the architecture is explicitly tested. Yet, this is one of the main reasons stated in the literature for developing an architecture (Bass et al., 2003). Apparently, these intended beneﬁts of architecture have not yet been ﬁrmly established in the mindset of architects. The lack of value contributed to the intended beneﬁts reveals a mindset of positiveness (“architects always take the right decisions”), which supports the ﬁndings of (Tang et al., 2006). Respondents do not like to use architectural knowledge to identify potential weaknesses of their design.
Stakeholder-centric – A number of use cases for architectural knowledge can be regarded as Stakeholder-centric. These use cases involve identifying stakeholders and communicating the architecture towards these stakeholders. Five out of the seven use cases in this cluster are regarded as important by the respondents. Especially the Highlevel role deems these use cases important. The remaining use cases ‘identify affected stakeholders on change’ and ‘identify key architectural decisions for a speciﬁc stakeholder’ are deemed neutral. Furthermore, stakeholder-centric use cases are regarded as more important at the architecture levels Enterprise architecture and Process and information architecture than at the other levels. This conﬁrms the general idea that the architecture levels Enterprise architecture and Process and information architecture are suitable for communicating architecture to non-IT stakeholders. The other way around, practitioners engaged in Software architecture and Systems architecture do not regard communication of the architecture to stakeholders as important. Apparently, at these more technically oriented levels of architecture, practitioners mainly capture architectural decisions for themselves and not for communication to other stakeholders. This in itself is not bad, but reveals that different communication needs exist for different architecture levels.
Forward architecting – Four use cases for architectural knowledge fall into the cluster Forward architecting. When we regard the use cases in this cluster we see that ‘add an architectural decision’ is deemed important at all architecture levels and by most architectural roles (only the Specialist role does not regard this use case as important). The use case ‘remove consequences of a cancelled decision’ is not deemed very important.