Shaping Together Architectural Work

We are a team of ten people, working on a system designed to assist dispatchers in efficiently managing and monitoring transports. It’s a data-intensive web application built on Java, Spring Boot, and Angular, featuring numerous list views, real-time data, and integrations with various source systems.

After over three years of development, our system had expanded significantly: six services, numerous interfaces, and ongoing functional enhancements. As a result, certain pockets of expertise emerged, with only a few colleagues having a comprehensive understanding of the overall system and its architectural framework. While the team is technically proficient, communication has been somewhat reserved. This was compounded by several years of remote work, which made informal conversations and spontaneous architecture discussions more challenging. Within the team, feedback on the software’s quality became increasingly critical, though often vague.

We were therefore looking for a method that would allow us to address both quality and architectural concerns collaboratively while actively involving all team members. LASR – the Lightweight Approach for Software Reviews – appeared to be the structured yet accessible format we needed to bring architectural topics into the team’s discussions.

We aimed to bring as many participants as possible together in person, and our Product Owner was also part of the group. We focused solely on the core elements of LASR, without delving into the deeper aspects with LASR+, and allocated a total of 5 hours for the session.

We didn’t need to completely reinvent the mission statement, as there was already a foundation in place. We refined the existing text, adding more detail and making slight enhancements. The first sentence became: “Monitor transports from start to finish at a glance, with intelligently combined schedules for both domestic and international destinations.”

To identify the top 5 quality goals, we made slight adjustments to the Top-5 Challenger. After laying out the random set of five target cards, the remaining candidate cards were distributed among the group. To initiate discussion, each person was asked to decide whether their assigned card(s) should be traded in or set aside. The goal was to ensure that everyone was actively involved from the outset.

The five quality goals we determined for our evaluation criteria were usability, reliability, operability, functional suitability, and maintainability. We also wrote a few key points on post-its to document the reasons behind our selection of these criteria. The spider web diagram illustrates these goals alongside their relevant target values.

To reduce the number of standard risk cards and involve as many people as possible, we assigned each of the 8 categories to a team member and gave them the 4 associated risk cards. The “owner“ of each category then decided how many cards should be included in the review. In some categories, all 4 risk cards made it into the final deck, while in others, only 2 were selected. The deck was shuffled and randomly distributed to all participants.

The rest of the risk-based review followed the standard procedure. Below is a photo from the workshop. A quick tip: we had a table that was slightly too small—the minimum size should be 1x1m, and a little extra space for writing post-its would certainly be helpful.

We set timeboxes of 3-5 minutes for classifying each risk (based on impact and likelihood) and also took notes during the process. The resulting diagram can be seen in the factsheet, where we identified significant gaps in maintainability and functional suitability.

In this step, we compiled the strengths and weaknesses in a table. We assigned the relevant quality attributes to each and identified the software components affected. Afterward, we prioritized the weaknesses.