Requirements for Software Architecture Knowledge

Communicating Architectural Knowledge: Requirements for Software Architecture Knowledge Management Tools Widura Schwittek and Stefan Eicker paluno – The Ruhr Institute for Software Technology University of Duisburg-Essen Universitätsstr. 9, 45141 Essen, Germany {widura.schwittek,stefan.eicker}@paluno.de

Abstract. Architecting is a communication intensive task in which architectural knowledge is shared between the architect and the stakeholders. The software architect’s communicative action is often conducted face-to-face, e.g. in presentations and workshops. A software architecture documentation as a carrier of explicit architectural knowledge can also be seen as an architect’s communicative action. This perspective opens the door for treating a software architecture documentation as an expression of an asynchronous knowledge communication process enabling the application of principles from communication theory. In this paper this perspective is taken and specific requirements are derived for software architecture knowledge management tools with respect to the contextoriented communication model. Keywords: software architecture, architectural knowledge, knowledge communication.

1 Introduction Architecting is a communication intensive task in which the architecture serves as a vehicle for communication among stakeholders [1]. Developers must understand their work assignments it requires of them, testers must understand the task structure it imposes on them, management must understand scheduling implications it suggests, and so forth [2]. The shift to viewing a software architecture as a set of architectural design decisions [3, 4] brought the notion of architectural knowledge to the software architecture research community, in which it is defined as “architectural design decisions + design” [5]. This shift underlines that communicating a software architecture is a knowledge intensive process, which occurs often during the development of a software architecture and therefore should be considered adequately. Communicating knowledge takes a lot of effort because not only facts are communicated, but also their emphasis, underlying assumptions and problem perspectives etc. Unlike the sole transfer of information, this kind of communication is called “knowledge communication” [6], which aims at creating a common ground between two communication partners. Communicating architectural knowledge is even more tedious because a software architecture is intangible and at first resides only in the M. Ali Babar and I. Gorton (Eds.): ECSA 2010, LNCS 6285, pp. 457–463, 2010. © Springer-Verlag Berlin Heidelberg 2010

458

W. Schwittek and S. Eicker

architect’s head. It needs advanced communication skills to achieve a common understanding of the architecture between all stakeholders. Stakeholders from different functional domains with different backgrounds and mindsets speak different languages, which make successful communication even more difficult. Much research work has been spent on tool support for the architecting process and especially on the subject of sharing architectural knowledge [7, 8, 9, 10]. But to the knowledge of the author there has been no work on the success factors of computermediated communication processes underlying many architectural knowledge sharing processes. The research work behind this paper tries to fill this gap recognizing the importance of successful communication for creating a common ground between the architect and the stakeholders, and which otherwise would have a negative impact on software architecting and maintenance processes. The focus of this work lies on software architecture documentations viewed as the expression of a central architectural knowledge communication process. The results are high-level requirements for software architecture knowledge management tools to better support successful communication of architectural knowledge during all software lifecycle phases and to relieve the architect in his role as a “communicator”. This paper is structured as follows: In chapter two, the context-oriented communication model is explained and the rationale behind its selection. An understanding of how computer-mediated communication works is created and the significance of the different communication contexts is highlighted. In chapter three, derived high-level requirements from these insights are presented. In chapter four, a conclusion is made and an outlook is given to further research following this paper.

2 Computer-Mediated Knowledge Communication The field of knowledge communication originating from communication theory tries to find answers to the question how knowledge should be communicated, in order to create a common understanding between two communication partners. In this process the sender has to create a plan, how to construct an expression regarding his target audience choosing the right form and language. While knowledge becomes information in the moment it is expressed, the recipient has to reconstruct the knowledge by integrating the information into his existing knowledge. This constructivist understanding of knowledge is central within the context-oriented communication model [11]. Originally created to explain misunderstandings in computer-mediated communication situations, it was later used to derive requirements for CSCW (Computer Supported Collaborative Work) systems [12]. This model is based on the work of Ungeheuer [13] and the neurobiological insights of Maturana and Varela [14]. While Ungeheuer dealt with the significance of the context in communication processes, Maturana and Varela came to the conclusion, that living systems always perceive their environment through filters and always constructing their own reality. As its name already says, the importance of the context for creating a common understanding through communication is taken into account and should be explained in detail in the following. Figure 1 depicts the elements and their interplay of the context-oriented communication model. To create a common understanding between two communication

Communicating Architectural Knowledge

459

Fig. 1. Context-oriented communication model translated from [12]

partners not only the proper expression of an idea is important, but also what additional context information should be given, in order to allow the recipient to interpret the expression correctly. The context-oriented communication model differentiates two kinds of contexts. The inner context represents the personal existing knowledge, which is not directly accessible by other individuals. The expression of an idea is biased by the inner context of the sender, meaning by his personal background, his attitude, prejudices, values, educational history etc. In order to support the recipient’s understanding of the expression, the sender has to check his personal impression of the recipient against congruencies between the inner context of him and the recipient’s inner context. Any expected differences between those two inner contexts must be compensated by expressing or referencing those parts and making them explicit. The outer context consists of everything that is not part of the current communication expression, such as the facial expression, gesture and behavior, but also information and knowledge, which has been shared before. It is divided into things, which are or have been potentially perceivable by the communication partners and into things, which actually are perceived by both communication partners (shared perception). In computer-mediated communication processes the outer context is reduced depending on which medium is used. E.g. using a chat system the outer context is reduced to characters leaving no room to validate the interpretation of the expression against elements from the outer context. While this synchronous type of communication allows immediate check-backs and feedbacks to secure communication, this is not possible in asynchronous communication situations. Communicating architectural knowledge through a software architecture documentation represents such an asynchronous communication situation. This short introduction into computer-mediated communication should sensitize the reader to consider both inner and outer context, if knowledge communication should be supported adequately.

460

W. Schwittek and S. Eicker

3 High-Level Requirements 3.1 Avoid Loss of Inner Context Knowledge is always bound to a person. If knowledge is separated from a person, more knowledge – part of the inner context – needs to be explicated to raise chances of a good reconstruction of that knowledge by another person. Research work around capturing architectural design decisions to prevent knowledge vaporization [3, 15] show, that the inner context of a communication process is in part already taken into account within the architecture research community: It is not only about capturing the design decisions itself, but also about capturing its rationale, considered alternatives, organizational constraints at a certain point in time and other situative information, that span the context around the actual decision. Referring to the discussion about context-oriented communication in chapter two, it is already known how to communicate decisions the right way. But architectural knowledge does not only comprise decisions and there are probably more measures to be made, in order to overcome the other problems resulting from asynchronicity and computer-mediation. These other aspects are discussed in the following with respect to the context-oriented communication model. 3.2 Avoid Loss of Outer Context As described in chapter two, the conception of an expression is biased by the impression the sender has got of the recipient. He therefore has to estimate the foreknowledge of the recipient. The same applies for interpreting the expression on the recipient’s side. During this process the recipient is biased by the impression he has about the sender. Thus having a good impression of your communication partner helps to communicate effectively and reduce misunderstandings. Its creation should therefore be supported on both sides, especially when it comes to computer-mediated communication in which the outer context is reduced depending on the type of media used. Looking at the research field of CSCW a lot of research work has been spent on this topic labeled “awareness research”. In this field awareness is described as “an understanding of the activities of others, which provides a context for your own activity” [16]. Awareness modules in modern CSCW systems offer information about the presence, availability, working activities (e.g. last opened document) etc. of other users. Another source for information, which might enrich the creation of a partner’s impression is social software. Social software makes the weak and strong ties of social relationships visible, offering profile information about skills and working experience. Hence, social software supports building up a proper impression of a person and making communication more effective on both sides. Furthermore social software encourages spontaneous and informal synchronous communication, but this is not subject of this paper. Software architecture research already gave birth to a knowledge sharing community software [17]. But while recognizing the importance of communication, interaction and the outer context for knowledge sharing processes, it focuses on networking and making use of the network. It fulfills not all requirements described in this paper and therefore does not explicitly support knowledge communication processes the way we presented it in this paper.

Communicating Architectural Knowledge

461

3.3 Support Asynchronous Communication Asynchronous communication comes with two problems: On the sender’s side it is not possible to check, if the conceptualization of an expression was good enough. On the recipient’s side it is not possible to validate the interpretation of an expression. The best way to communicate knowledge is face-to-face, being able to establish a common understanding through high interaction. Asynchronous communication has to compensate this. Asynchronous communication requires even more to focus on the target audience, because there is no possibility to adapt the expression instantaneously. Through the concept of architectural views [18] this requirement is already being applied in software architecture documentations. The concept allows creating viewpoints and instantiating views for different groups of stakeholders to satisfy their demand for information. Views only display specific aspects of an architecture which leads to reduced complexity and a language and notation the target audience understands. The context-oriented communication model speaks of “hide the known and irrelevant” referring to the fact, that having more information at hand does not automatically mean being more informed [13]. Due to the fact that questions on the recipient’s side cannot be asked instantaneously, context-oriented communication suggests multiple expressions of the same idea helping to reduce room for interpretation. Mass media like newspapers and magazines fulfill this requirement by not only providing textual representations but also additional images. In software architecture documentations UML diagrams support textual representations and vice versa. Other visual representations beside the well-known UML diagrams exist and should be considered when offering multiple expressions. E.g. in [19] a proposal is made for different visualizations of architectural design decisions. 3.4 The Dynamic Architecture Documentation On the basis of the insights offered by the context-oriented communication model we propose the concept of a dynamic architecture documentation. By this we mean to simulate synchronicity and the ability to interact instantaneously between two communication partners. This is achieved by certain mechanisms on the sender’s and recipient’s side. First, the recipient should be able to bring expressions into a form he chooses and understands best. While an architectural view offers a starting point for a stakeholder of the target group, a dynamic architecture documentation makes it possible to fine tune his “personal” view. This is realized through filters allowing hiding and showing different aspects of an architecture and through transformers to switch to different visual representation forms or to merge them. Second, the sender should be supported in segmenting and semantically enriching an architecture documentation, enabling the functionality on the recipient’s side. One way of realization is through the concept of tags. In [9] a word plug-in is presented that allows tagging parts of the document. One use case of this approach is to list all design decisions. All parts of the document, which have been tagged as a design decisions are collected and shown in an aggregated form.

462

W. Schwittek and S. Eicker

A general requirement for the concept of a dynamic architecture documentation is the provisioning of a repository storing all explicit architectural knowledge, which can be queried the way described above. One tool originating from architecture research is already close to the realization of the concept of a dynamic architecture documentation: The Knowledge Architect [20] is database-driven and offers a repository, which is queried by a Knowledge Translator component which transforms generic architectural knowledge into a more domain specific form the stakeholder understands. The stakeholder however is not able to configure the Knowledge Translator to fine tune his view, but has to stick to the predefined views the component offers.

4 Conclusions and Future Work In this paper a communication theory perspective is taken, in order to consider a software architecture documentation as an expression of an asynchronous communication process, through which architectural knowledge is shared. With this perspective high-level requirements have been derived for architecture knowledge management tools. The context-oriented communication model has been used to explain how knowledge is communicated and the importance of the inner and outer context has been highlighted. It provided the necessary conceptual framework to look at concepts from other research fields like CSCW, social media and visualization and to make them usable in software architecture research. The result consists of high-level requirements, measures and hints to concepts and tools, already fulfilling parts of these high-level requirements. The research work presented in this paper is not finished and open research questions remain. These will be addressed in the next step of our research work. One of these questions is, to look more into detail, how existing software architecture knowledge management tools cope with knowledge communication, and how the high-level requirements proposed in this paper can be refined and put into practice. Another open question is, whether these high-level requirements really have an impact on the success of knowledge communication processes and whether they really lead to a better common understanding between the architect and other stakeholders. Therefore an empirical evaluation is planned for which a software prototype will be used. It is based on the Generic Views Concept [21] and fulfills all requirements of a dynamic architecture documentation. The prototype concentrates on delivering user defined and concern related on-demand-views, while still missing other features like avoiding the loss of the outer context, which has been demanded in this paper. Thus, further development of the prototype is planned, while it is not yet clear if it will result in a standalone application or in an enhancement of existing architecture knowledge management tools.

References 1. Dingsøyr, T., van Vliet, H.: Introduction to Software Architecture and Knowledge Management. In: Ali Babar, M., Dingsøyr, T., Lago, P., van Vliet, H. (eds.) Software Architecture Knowledge Management. Theory and Practice, pp. 1–17. Springer, Heidelberg (2009) 2. Bass, L., Clements, P., Kazman, R.: Software architecture in practice. Addison-Wesley, Boston (2003)

Communicating Architectural Knowledge

463

3. Bosch, J.: Software Architecture: The next step. In: Oquendo, F., Warboys, B.C., Morrison, R. (eds.) EWSA 2004. LNCS, vol. 3047, pp. 194–199. Springer, Heidelberg (2004) 4. Jansen, A., Bosch, J.: Software architecture as a set of architectural design decisions. In: Proceedings of the 5th IEEE/IFIP Working Conference on Software Architecture (WICSA), pp. 109–119. IEEE Computer Society, Los Alamitos (2005) 5. Kruchten, P., Lago, P., van Vliet, H.: Building up and Reasoning about Architectural Knowledge. In: Hofmeister, C., Crnković, I., Reussner, R. (eds.) QoSA 2006. LNCS, vol. 4214, pp. 43–58. Springer, Heidelberg (2006) 6. Reinhardt, R., Eppler, M.J.: Wissenskommunikation in Organisationen. Methoden, Instrumente, Theorien. Springer, Heidelberg (2004) 7. Ali-Babar, M., Gorton, I., Jeffery, R.: A tool for managing software architecture knowledge. In: 2nd Workshop on Sharing and Reusing architectural Knowledge – Architecture, Rationale, and Design Intent (SHARK/ADI). ACM, Minneapolis (2007) 8. Farenhorst, R., Lago, P., van Vliet, H.: EAGLE: Effective tool support for sharing architectural knowledge. Int. J. Cooper. Inform. Syst. 16(3/4), 413–437 (2007) 9. Jansen, A., Avgeriou, P., van der Ven, J.S.: Enriching software architecture documentation. J. Syst. Software 82(8), 1232–1248 (2009) 10. Tang, A., Avgeriou, P., Jansen, A., Capilla, R., Ali-Babar, M.: A comparative study of architecture knowledge management tools. J. Syst. Software 83(3), 352–370 (2010) 11. Herrmann, T., Misch, A.: Anforderungen an lehrunterstützende Kooperationssysteme aus kommunikationstheoretischer Sicht. In: Schwill, A. (ed.) Informatik und Schule, pp. 58–71. Informatik aktuell. Springer, Heidelberg (1999) 12. Kienle, A.: Integration von Wissensmanagement und kollaborativem Lernen durch technisch unterstützte Kommunikationsprozesse. Dissertation. Lohmar, Eul (2003) 13. Ungeheuer, G.: Vor-Urteile über Sprechen, Mitteilen, Verstehen. In: Ungeheuer, G. (ed.) Kommunikationstheoretische Schriften, vol. 1, pp. 229–338, Rader, Aachen, (1982) 14. Maturana, H.R., Varela, F.J.: Tree of Knowledge: Biological Roots of Human Understanding. Shambhala Publications, Boston (1987) 15. Tyree, J., Akerman, A.: Architecture Decisions: Demystifying Architecture. IEEE Software 22(2), 19–27 (2005) 16. Dourish, P., Bellotti, V.: Awareness and Coordination in Shared Workspaces. In: Turner, J., Kraut, R. (eds.) CSCW 1992 - Sharing perspectives. Proceedings of the Conference on Computer-Supported Cooperative Work, pp. 107–114. ACM, New York (1992) 17. Lago, P.: Establishing and Managing Knowledge Sharing Networks. In: Ali Babar, M., Dingsøyr, T., Lago, P., van Vliet, H. (eds.) Software Architecture Knowledge Management. Theory and Practice, pp. 113–131. Springer, Heidelberg (2009) 18. Kruchten, P.: The 4+1 View Model of Architecture. IEEE Software 12(6), 42–50 (1995) 19. Lee, L., Kruchten, P.: Visualizing software architectural design decisions. In: Morrison, R., Balasubramaniam, D., Falkner, K. (eds.) ECSA 2008. LNCS, vol. 5292, pp. 359–362. Springer, Heidelberg (2008) 20. Liang, P., Jansen, A., Avgeriou, P.: Collaborative Software Architecting through Knowledge Sharing. In: Finkelstein, A., van der Hoek, A., Grundy, J., Mistrìk, I., Whitehead, J. (eds.) Collaborative Software Engineering, pp. 343–367. Springer, Heidelberg (2010) 21. Eicker, S., Jung, R., Schwittek, W., Spies, T.: SOA Generic Views - In the Eye of the Beholder. In: Congress on Services - Part I, SERVICES 2008, pp. 479–486. IEEE Computer Society, Piscataway (2008)