University of Groningen Offers Repertory Grid Tool for Capturing Architecture Decisions
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.
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.
Traditionally, I have used (and still use) methods such as ATAM and indeed HoQ to make my decisions. The matrices in use there will give hard, 'convergent' reasoning as to why choices were made. What it doesn't account for is the reason why that particular architect, weighed/scored influences/options/risks the way they did. In conjunction with those methods, a repertory grid may be useful to give the insight into the mindset of the architect at the time. What I intend to do is look at this in a little more detail, playing with the tool to get an idea of how this can be used to either replace or augment methods such as ATAM. In combination, I can definitely see it may allow me to know that I made this decision given preferences for x or y as opposed to more pertinent forces elsewhere.
However, I am sceptical about its complete replacement of what I consider more rigorous methods. There are two things that are important in software engineering that I can see from my 'psychology armchair' and that is that both divergent and convergent elements are involved. The divergent solutions will provide multiple solutions (sometimes creatively) for architecture deliverables/artefacts, the convergent process will filter or evaluate solutions more rigorously into an/the optimum solution. I can see this having a place in the former, but not so sure it is comprehensive enough to deal with the latter. But I am keeping an open mind to that possibility.
Re: Interesting idea
Thank you for your thorough comment!
Indeed, the clusters show patterns in the data, but they hide other values. For example, currently in the tool the user can only see similarity levels between neighboring alternatives, which would be more precise values. Displaying the similarity matrix for a grid (with similarity values among all pairs of alternatives) will be implemented in the coming months.
I am interested to hear about your experience on using RGT with ATAM. I think it can complement ATAM nicely. The tool has functionality for collaborative decision making, so that stakeholders can focus discussions on their divergences. Please let me know your opinion about it.
I agree with your assessment on divergent and convergent elements. I consider RGT well-suited for the divergent solutions (as you call them). RGT can help you filter them (e.g. let's say you have 5 solutions), and then you can use some other approach for analyzing the shortlist (e.g. for which you only have 2 solutions).
Please send me feedback on RGT and the tool for your architectural decisions (my email is email@example.com).
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015