Remco C. de Boer

Knowledge Management in Software Architecture: State of the Art

Architectural knowledge has played a role in discussions on design, reuse, and evolution for over a decade. Over the past few years, the term has significantly increased in popularity and attempts are being made to properly define what constitutes ‘architectural knowledge’. In this chapter, we discuss the state-of-the-art in architectural knowledge management. We describe four main views on architectural knowledge based on the results of a systematic literature review. Based on software architecture and knowledge management theory we define four main categories of architectural knowledge, and discuss four distinct philosophies on managing architectural knowledge, which have their origin in the aforementioned views. Whereas traditionally tools, methods, and methodologies for architecture knowledge management were confined to a single philosophy, a trend can be observed that state-of-the-art approaches take a more holistic stance and integrate different philosophies in a single architecture knowledge management approach.

Ontology-driven visualization of architectural design decisions

There is a gradual increase of interest to use ontologies to capture architectural knowledge, in particular architectural design decisions. While ontologies seem a viable approach to codification, the application of such codified knowledge to everyday practice may be non-trivial. In particular, browsing and searching an architectural knowledge repository for effective reuse can be cumbersome. In this paper, we present how ontology-driven visualization of architectural design decisions can be used to assist software product audits, in which independent auditors perform an assessment of a products quality. Our visualization combines the simplicity of tabular information representation with the power of on-the-fly ontological inference of decision attributes typically used by auditors. In this way, we are able to support the auditors in effectively reusing their know-how, and to actively assist the core aspects of their decision making process, namely trade-off analysis, impact analysis, and if-then scenarios. We demonstrate our visualization with examples from a real-world application.

Architectural knowledge discovery with latent semantic analysis: Constructing a reading guide for software product audits

Architectural knowledge is reflected in various artifacts of a software product. In a software product audit this architectural knowledge needs to be uncovered and its effects assessed in order to evaluate the quality of the software product. A particular problem is to find and comprehend the architectural knowledge that resides in the software product documentation. In this article, we discuss how the use of a technique called Latent Semantic Analysis can guide auditors through the documentation to the architectural knowledge they need. We validate the use of Latent Semantic Analysis for discovering architectural knowledge by comparing the resulting vector-space model with the mental model of documentation that auditors possess.

Experiences with Semantic Wikis for Architectural Knowledge Management

In this paper, we reflect on our experiences with using semantic wikis for architectural knowledge management in two different contexts: e-government and distributed software development. Whereas our applications of semantic wikis in e-government focus on organizing and structuring architectural knowledge for reuse, the applications in distributed software development focus on searching and querying architectural knowledge. Yet, the emerging research challenges -- alignment of knowledge models, knowledge versioning, change acknowledgements -- are very similar.

Writing and Reading Software Documentation: How the development process may affect understanding

The effectiveness of documentationwithin a development process is determined by the way in which the intentions of the authors correspond to the expectations of the potential readers. Ideally, the members of a development team share a certain understanding of (the role of) the different types of documentation. However, since ones expectations of a document are personal, and part of a tacitly formed mental model, we can expect different levels of shared understanding between different development team members. We elicited and analyzed the mental models of software documentation from eight members of a single development team. We found indeed different levels of shared understanding between different people. To our surprise, the levels of shared understanding within the team appear closely tied to the development process employed. From Conways law we know that an organizations structure is mirrored in the structure of the software that the organization produces. Our findings suggest that the organizations development process may likewise be mirrored in the extent to which a development team shares a common frame of reference. Hence, the development process followed may have implications for the effectiveness with which development knowledge can be shared through software documentation.

The GRIFFIN Collaborative Virtual Community for Architectural Knowledge Management

Modern software architecting increasingly often takes place in geographically distributed contexts involving teams of professionals and customers with different backgrounds and roles. So far, attention and effort have been mainly dedicated to individuals sharing already formalized knowledge and less to social, informal collaboration. Furthermore, in Web 2.0 contexts, little to no attention has been given to practitioners carrying out complex, collaborative, and knowledge-intensive tasks in organizational contexts.

QuOnt: an ontology for the reuse of quality criteria

Software product audits are knowledge-intensive tasks in which architectural knowledge plays a pivotal role. In the input stage of a software product audit, quality criteria are selected to which the software product should conform. These quality criteria resemble architectural tactics and can be viewed as a definition of the Soll-architecture of the product. Like tactics, the same quality criteria can be applied to different software products. However, there are currently no models that support the codification of quality criteria as reusable assets. In this work, we present an ontology that supports the reuse of quality criteria in the input stage of software product audits.

The GRIFFIN Project: Lessons Learned

GRIFFIN is a joint research project of the VU University Amsterdam and the University of Groningen. The GRIFFIN project develops notations, tools and associated methods to extract, represent and use architectural knowledge that currently is not documented or represented in the system. The research is carried out in a consortium with various industries, both large and small, that provide case studies and give regular feedback. Paraphrasing [327], the goal of the GRIFFIN project can be summarized as “What architects know, and how they know it”. In this chapter, we give an overview of the results of the GRIFFIN project, and lessons learned with respect to software architecture knowledge management.

Empirical evaluation of a process to increase consensus in group architectural decision making

ContextMany software architectural decisions are group decisions rather than decisions made by individuals. Consensus in a group of decision makers increases the acceptance of a decision among decision makers and their confidence in that decision. Furthermore, going through the process of reaching consensus means that decision makers understand better the decision (including the decision topic, decision options, rationales, and potential outcomes). Little guidance exists on how to increase consensus in group architectural decision making. ObjectiveWe evaluate how a newly proposed process (named GADGET) helps architects increase consensus when making group architectural decisions. Specifically, we investigate how well GADGET increases consensus in group architectural decision making, by understanding its practical applicability, and by comparing GADGET against group architectural decision making without using any prescribed approach. MethodWe conducted two empirical studies. First, we conducted an exploratory case study to understand the practical applicability of GADGET in industry. We investigated whether there is a need to increase consensus, the effort and benefits of GADGET, and potential improvements for GADGET. Second, we conducted an experiment with 113 students from three universities to compare GADGET against group architectural decision making without using any prescribed approach. ResultsGADGET helps decision makers increase their consensus, captures knowledge on architectural decisions, clarifies the different points of view of different decision makers on the decision, and increases the focus of the group discussions about a decision. From the experiment, we obtained causal evidence that GADGET increases consensus better than group architectural decision making without using any prescribed approach. ConclusionsThere is a need to increase consensus in group architectural decisions. GADGET helps inexperienced architects increase consensus in group architectural decision making, and provides additional benefits, such as capturing rationale of decisions. Future work is needed to understand and improve other aspects of group architectural decision making.

Dynamic networked organizations for software engineering

Current practice in software engineering suggests a radical change in perspective: where once stood fixed teams of people following a development plan, now stand just-in-time Dynamic Networked Organizations (DyNOs), adopting a common flexible strategy for development, rather than a plan. This shift in perspective has gone relatively unnoticed by current software engineering research. This paper offers a glimpse at what processes and instruments lie beyond “current” software engineering research, where studying emergent DyNOs, their creation and steering becomes critical. To understand the underpinnings of this evolution, we explored a simple yet vivid scenario from real-life industrial practice. Using scenario analysis we elicited a number of social and organizational requirements in working with DyNOs. Also, comparing our evidence with literature, we made some key observations. First, managing DyNOs makes organizational requirements a first-class entity for development success. Second, research in software engineering should be invested in understanding and governing the DyNOs behind the software lifecycle.