Dan Tofan from the University of Groningen provides the open source software tool RGT (Repertory Grid Tool) to software architects for capturing and evaluating their architecture decisions. Using the tool architects can better document their decisions and reflect about them.
Architecting a complex software system means that many important decisions need to be made. In their decisions, architects need to address concerns of stakeholders about functional and non-functional requirements, to satisfy business and technical goals. Moreover, architects need to reflect on the quality of their decision making process, such as 'did I consider all viable alternatives for this decision?'
To help architects, software engineering researchers at University of Groningen contribute with tool support for architectural decision making. Details about this open source tool are available at https://github.com/danrg/RGT-tool/wiki.
Here are some Q&A with Dan Tofan, who leads development efforts for the tool.
InfoQ: Dan, can you say a few words about yourself and your research?
I am a software developer, turned into researcher after 6 years in the industry. My research aims at improving decision making of software architects.
InfoQ: What was your main motivation behind RGT and how does it fit into the overall picture of your activities?
I think that decision making skills are essential for architects, not only for designing software, but also for providing sound rationale to other stakeholders. So if you look at decision making as a skill, just like swimming or cooking, then the next logical step is to ask yourself: how can I improve my architectural decision making skills?
Decision making overlaps with capturing architectural knowledge about decisions. has a solid track in capturing knowledge. So, capturing architectural decisions with RGT offers two major advantages: knowledge about architectural decisions is preserved, and the architects can improve their decision making skills.
InfoQ: Can you describe RGT?
The RGT steps are the following. First, we agree on the decision topic. Next, you indicate decision alternatives for the topic. Then, I ask you to pick up two alternatives which you consider similar, but different from a third. Next, you describe how the two are similar and different from the third, resulting in a concern (or construct in RGT jargon). For example, Java and C# are similar because they are ‘backed up by large vendors’, unlike Ruby which has ‘community backup’. After eliciting more concerns, the next steps is to rate each alternative against every concern (usually on a 1 to 5 scale). Next, the resulting matrix (or grid) of alternatives, concerns and ratings is analyzed, for example by performing a hierarchical cluster analysis, to group alternatives and concerns based on their similarity. Finally, the architect can refine the grid, by updating alternatives, concerns or ratings, so that the resulting grid reflects architect’s mental model of the decision.
Overall, the grid and its clusters offer a compressed documentation of the decision, which offers a tighter overview of the decision, compared to an equivalent text description.
InfoQ: What is the typical use case for RGT?
The typical use case is capturing architectural decisions for which 4 to 9 alternatives can be identified. For fewer alternatives RGT might be overkill. For more alternatives RGT might take too much time.
InfoQ: What benefits does RGT offer to practitioners?
RGT offers a systematic manner for capturing decisions. Also, it helps generate new insights about the decision. RGT makes architects reflect more about their decisions. Finally, RGT delivers a concise documentation for a decision.
However, RGT has disadvantages. Mainly, RGT can be time consuming. Therefore, I think RGT works best for important decisions that require careful consideration, which might often be the case with software architects. When discussing with architects about RGT, they often mentioned lack of better tool support as an issue, so we worked to fix that.
InfoQ: What are the main features of this tool?
First, the tool helps architects enter grids about their individual decisions. Second, the tool allows collaborative decision making, starting from existing grids. The idea is to use multiple rounds of filling out a grid, for clarifying divergences among a group of stakeholders and reaching consensus.
Last, but not least, the tool is open source (https://github.com/danrg/RGT-tool) and deployed at http://repertorygridtool.com.
InfoQ: What kind of feedback would you like to get from RGT users?
Often research results take a long time until adopted by the industry, some say even 10-15 years. Feedback from intended users is essential to reduce adoption time. I expect two types of feedback: on RGT and on the tool.
So, I would like to hear about how RGT helped architects in their decision making.
Since the tool is open source, I am interested in suggestions on the tool, bug reports, and code contributions. I want to build a small community around the tool.
InfoQ: As Grady Booch once said "a fool with a tool is still a fool". How do you ensure that architects do really leverage RGT in an effective and efficient way?
I see three points for best leveraging of the tool. First, make sure you use RGT at the right time and place: RGT is a niche technique, so do not use it like a hammer with every decision as a nail. Second, invest some time to learn about RGT. Third, start with some old architectural decisions, and then move gradually to current decisions, as well as group decisions. Finally, share your experience, I would like to help.
InfoQ: What are the next steps you are planning for RGT and your approach?
A next step is allowing the possibility to express utility functions when evaluating alternatives against concerns, which would be a more precise evaluation compared to the current basic rating. Additionally, I want to implement some features for risk management. Another step is to implement composite decisions, in which alternatives are combinations of options from more ‘atomic’ decisions. Composite decisions would enable a more thorough exploration of the design space, to make sure that valid combinations are not overlooked.
