Evaluating software architecture is an important part of enterprise architecture (EA). Felix Bachmann of Software Engineering Institute (SEI) recently talked about how to effectively evaluate software architecture and identify risks in enterprise applications. He hosted a seminar at SEI Architecture (SATURN) conference on architecture evaluation principles. He also discussed how SEI's Architecture Tradeoff Analysis Method (ATAM) framework utilizes these principles to help with the architecture evaluation efforts.
Felix talked about three categories to group the principles of architecture evaluation, "The Measure", "Understanding of the Architecture", and "The Know How". The measure part of the software architecture evaluation includes eliciting the organizational needs from the stakeholders and translating them into quality attribute requirements in a precise and measurable way. He talked about four principles in this category.
- Quality attributes determine the architecture.
- Business goals determine quality attribute requirements.
- Business goals represent what's important to its stakeholder communities.
- Quality attributes requirements need to be specified with good measures.
It's also important to understand the approaches the architect used, understand the functional distribution and understand where to find the trouble spots. There are three principles in understanding the architecture.
- To understand an architecture you must understand its quality attribute properties.
- The most important quality attribute requirements determine the parts of the system to focus the analysis on.
- The distribution of functionality in the architecture contributes to the quality attribute properties.
The "Know How" part of software architecture evaluation includes:
- "Guilty until proven innocent" meaning not blindly trusting anything that is provided and asking for convincing evidence. Failure to provide this evidence results in risks.
- Proper analysis disallows assumptions. Only facts count.
- Evaluated organizations must own the evaluation results.
Using an architecture evaluation method that adheres to all the principles can almost guarantee successful results. Felix indicated that an architecture evaluation method that does not use any of the principles will very likely end in a disaster. He suggested that these principles should be applied based on the context because the adherence to some principles is more important than to others. The better a method utilizes the principles, the higher the chances for success.
The ATAM framework utilizes these principles in architecture evaluation. The main part of the ATAM consists of nine steps separated into four groups:
- Presentation, which involves exchanging information through presentations.
- Investigation and analysis, which involves assessing key quality attribute requirements vis-a-vis architectural approaches.
- Testing, which involves checking the results to date against the needs of all relevant stakeholders.
- Reporting, which involves presenting the results of the ATAM.
Following are the steps in the ATAM evaluation process.
- Present the ATAM.
- Present business drivers.
- Present architecture.
- Identify architectural approaches.
- Generate Quality Attribute Utility Tree.
- Analyze architectural approaches.
- Brainstorm and prioritize scenarios.
- Analyze architectural approaches.
- Present results.
Felix concluded the discussion by saying that the software architects should carefully watch the results of the architecture evaluation to continuously improve the evaluation process.