Continuing the series of posts on software architecture evaluation, with a simpler evaluation method: Lightweight Architecture Evaluation (LAE).
As documented in Software Architecture in Practice, 4th Edition, by Len Bass, Paul Clements, and Rick Kazman, “the Lightweight Architecture Evaluation(LAE) is intended to be used in a project-internal context where the reviewing is carried out by peers on a regular basis”.
While it uses is the same concepts as ATAM – see my previous post – it is meant to be performed regularly making it suitable for the modern world of continuously evolving systems, CI/CD and continuous design. Given the simplicity of the method, it can be performed in a couple of hours, making it very effective in comparison with ATAM.
Here are my notes on Lightweight Evaluation Method.
Why LAE?
– Identifies risks early.
– It can be performed regularly to identify how architecture or architectural drivers have changed since the previous review.
– It required limited resources.
Who’s involved?
– Only project internal peers.
– It is led by project architect.
Phases of LAE
1. Present the method steps if participants are not already familiar with it.
2. Review the business goals. This should be a brief review as participants are expected to understand the system, it’s business goals and their priorities.
3. Review the architecture. Highlight changes since the last review.
4. Review the architectural approaches. The architect highlights the architectural approaches used for specific quality attribute concerns.
5. Review the quality attribute utility tree. The team reviews the existing tree and updates it if needed with new scenarios, new response goals or new priorities of risk assessments.
6. Brainstorm to establish if new scenarios should be analyzed.
7. Analyze the architectural approaches. This step should focus on the most recent changes to the architecture or on a part of the architecture the team has not previously analyzed. If the architecture has changed the high-priority scenarios should be reanalyzed.
8. Capture the results. Review the existing and newly discovered risks, non-risks, sensitivities and tradeoffs.
What makes LAE efficient is that it doesn’t involve and doesn’t require non-technical project stakeholders to think in technical architectural terms, while performing the evaluation regularly in very limited time. What it requires are updated business goals and architecturally significant requirements which must be constantly and clearly communicated to the project team.