Architectural knowledge in a graph DB

So you want an automagical tool to help you decide whether to develop a software component yourself or outsourcing the activity? Or maybe you should integrate a component from the open source domain? We call this “asset origin selection”. This paper is my first publication in the Orion project.

The Orion project aims at understanding how decisions about evolution of component-based systems are made in industry. The initial part of the project involves a whole bunch of exploratory studies: a broad survey, a deep case study, and also a case survey. A first attempt to structure the problem space is published as the GRADE Taxonomy, an academic construct that helps us align the terminology within the project – and hopefully it could support external researchers as well.

The final delivery from the Orion project will be a decision support system supporting practitioners involved in asset origin selection. We call the system COACH, but the development has not started yet… However, we already know that an important part of COACH will be a knowledge repository of previous experiences related to choosing asset origins. There has already been a lot of research on how to store “architectural knowledge”, i.e., both the actual system architecture and the rationales behind the involved decisions. In this paper we review the scientific literature on storing architectural knowledge, and particularly how to represent the knowledge in a repository.

This paper outlines how we plan to implement the knowledge repository in COACH. We argue that the architectural knowledge is highly interconnected, and that a knowledge repository should be able to store large amounts of information. We present a scheme of how we plan to represent knowledge, and we claim that a traditional relational database is not the way forward – as relational databases do not support relationships very well! Instead we opt to use the open source community edition of Neo4J, a graph database that should offer the performance and scalability needed for COACH. But obviously we need to do a lot more of research before we can introduce even a preliminary version of COACH!

Implications for research

•  A review of knowledge representation in software architecture.
• An argumentation that graph databases are appropriate to implement a knowledge repository.

Implications for Industry

• In line with previous research, we stress the importance of storing both architectural decisions as well as the rationales.

Antonio Cicchetti, Markus Borg, Séverine Sentilles, Krzysztof Wnuk, Jan Carlson, and Efi Papatheocharous,  Towards Software Assets Origin Selection Supported by a Knowledge Repository, In Proc. of the 1st International Workshop on decision Making in Software ARCHitecture (MARCH), Venice, Italy, 2016. (preprint)

Abstract

Software architecture is no more a mere system specification as resulting from the design phase, but it includes the process by which its specification was carried out. In this respect, design decisions in component-based software engineering play an important role: they are used to enhance the quality of the system, keep the current market level, keep partnership relationships, reduce costs, and so forth. For non trivial systems, a recurring situation is the selection of an asset origin, that is if going for in-house, outsourcing, open-source, or COTS, when in the need of a certain missing functionality. Usually, the decision making process follows a case-by-case approach, in which historical information is largely neglected. This solution avoids the overhead of keeping detailed documentation about past decisions, but hampers consistency among multiple, possibly related, decisions. The ORION project aims at developing a decision support framework in which historical decision information plays a pivotal role: it is used to analyze current decision scenarios, take well-founded decisions, and store the collected data for future exploitation. In this paper, we outline the potentials of such a knowledge repository, including the information it is intended to be stored in it, and when and how to retrieve it within a decision case.