Back to top

Towards a framework for architectural design decision support

Last modified Jul 21


Software architecture is considered as a set of architectural design decisions. The recent trends, both in research and industry, calls for improved tool support for software architects and developers to manage architectural design decisions and its associated concepts. On the one hand, through empirical studies, researchers are trying to understand the decision-making process in software architecture and on the other hand, based on the results of the empirical studies, researchers are engineering systems to aid the decision making process. In our work, we focus on the latter aspect and propose a framework for managing architectural design decisions in large software-intensive projects. As part of our ongoing work, the components within this framework are iteratively realized and evaluated. We believe that the realization of the framework will allow the architectural knowledge management system to integrate with the software design, development, and maintenance phases to support stakeholders not only to document design decisions but also to learn from decisions made in the past projects.

In this work, we aim to build a system that learns from the existing projects what design decisions were made, who made these decisions, when were these decisions made, and how are these decisions related to each other. By extracting and structuring the aforementioned information in a knowledge repository, we envision supporting software architects to make informed design decisions in similar project context.

To this end, we base our meta-model on the ADD meta-model described in the ISO/IEC/IEEE 42010 standard and the architectural decision model proposed by Zimmermann et al.

Figure 1. ADD and its associated concepts

Research Objective

The long-term objective of this work is to develop a system that tracks the current state of a project, extracts information from project artifacts, and recommends software architects how to addresses specific architectural concerns. We have divided this high-level objective into the following tasks:

  • Develop a domain model for the knowledge base to capture project-specific information including project context, requirements, ADDs, tasks, and stakeholders (cf. Meta-model Based Framework for Architectural Knowledge Management).
  • Develop a mechanism to extract and synchronize information from disparate systems that maintain project related information (e.g., Excel, MS Project, Enterprise architect, and JIRA) into a knowledge base (cf. SyncPipes [Available on Github - SyncPipes Server, SyncPipes Client]).
  • Implement an approach to automatically learn about the design decisions made in the past and link them to specific concerns (in particular, to quality concerns). Focus on automatically detecting, extracting, and classifying design decisions from issues maintained in issue management systems such as JIRA and Github issues (cf. Automatic extraction of design decisions from issue management systems: a machine learning based approach and Issues Labeled Architectural Design Decisions (ILADD) [Available on Github - Document Classifier]).
  • Design a user profile model to capture decision makers’ preferences. User preferences, in the context of ADDs, for instance, include (a) frequently used technologies, plugins, and libraries, (b) inclination to address concerns related to specific architectural elements or concerns related to specific quality attributes of the system.
  • Develop an approach to populate the knowledge base with alternative architectural solutions. So that, given an architectural concern, the system can recommend which are the available alternative solutions that needs to be considered (cf. An ontology-based approach for software architecture recommendations – try it out here [Available on Github - Annotator and alternatives recommender])
  • Integrate the services developed in the above steps to build the final system that takes an architectural concern in a specific project context as input and recommends:
    • Similar ADDs that have been made in the past to address a concern [Master thesis]
    • Who has experience in addressing similar concerns
    • What are the alternative solutions available to address the concern
    • What is the estimated effort (time) involved in addressing similar concerns
    • Highlighting biases during design decision making [Master thesis]


  • Software architects (SAs) do not take rationalistic approach (best-fit) during decision making (in general humans are not “maximizers”) but favor naturalistic decision making (preference-based or first satisfiable option selection)
  • SAs make architectural decisions based on their expertise and past experiences. Implicitly they apply a learning model. (Software architecture as an art.)
  • ADDs can be associated with “quantifiable” attributes (such as risk, cost, effort, time, and experience)
  • The current state of the project and ADDs are observable given a pre-defined model



Presentation Slides

Towards a framework for architectural design decision support