Software Architecture Assessment
Assessment of software architecture is necessary to judge its utility and applicability to the goals a system aims to achieve. Every architecture design should be assessed by a non-partisan resource, but this practice has been adopted only at organizations with a very mature software engineering processes. There are no industry wide accepted methods for evaluating software architecture, but the Architecture Tradeoff Analysis Method (ATAM), developed by the SEI, is a well structured & rational approach for conducting architecture assessments.
Benefits of a structured tradeoff analysis method
The principal benefit of the Architecture Tradeoff Analysis is an ability to see if a proposed overall software structure will live up to the user expectations. The tradeoff analysis helps one understand the strengths and weaknesses of a system. The ATAM method not only helps evaluate the current system architecture, but also helps with the design of architecture for a new system. This methodology helps designers to ask the right questions and solve critical issues early on in the project. Additionally, selecting the right degree of quality for a specific system fully utilizes the money spent by the customer, as the money spent in any one particular area of the system will be justified.
The ATAM process helps developers discover tradeoffs and sensitivity points
The tradeoff points are defined as the dependencies between attributes. The sensitivity points are the areas of the system that will be significantly impacted if system architecture is changed. The tradeoff points are the breeding ground for the sensitivity points, because when architecture changes the connections between different attributes changes as well.
One of the more obvious tradeoffs is the relationship between performance and security quality. Often the security quality is achieved by compromising performance; this is not a surprising statement as it’s general knowledge that making something secure requires a special effort. Even outside of the architectural context, securing a door in a house requires a purchase and installation of a lock – and that’s only the initial costs. The effort required to lock and unlock the door each time it’s open/closed is an additional cost/effort element. In this out of context example performance of the door can be increased by not installing a door lock. With no lock there is little security, as anyone can open the door with no trouble. The tradeoff points in this example are the presence of lock(s) and the speed at which a door may be opened (perhaps for security reasons it can only be opened at 1 foot per hour).
Key sensitive points are like the gauges that must be monitored by an architect each time a change to a software system is considered on an architectural level.
Do you evaluate your software architecture?
At the end of the day a systemic architecture evaluation method is up to the architect to decide. What matters is that an architect has a way to judge whether architecture is the right fit for a business problem at hand. Other evaluation methods exist and serve various purposes: SAAM, ALMA, FAAM, CBAM. Some even use this assessment form.
Post a comment if you evaluate software architecture. How do you do it?