InfoQ

News

Felix Bachmann on Evaluating Software Architecture

Posted by Srini Penchikala on May 26, 2009

Community
Architecture
Topics
Enterprise Architecture
Tags
ATAM ,
Architecture Evaluation

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.

 

No comments

Watch Thread Reply

Educational Content

Brian Marick on 4 Challenges and 5 Guiding Values of Agile Software Development

Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).

Are You a Software Architect?

The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?

Agile – A Way of Life and Pragmatic Use of Authority

The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.

Getting Started with Grails, Second Edition

"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?

Using ITIL V3 as a Foundation for SOA Governance

Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.

Adrian Colyer on AspectJ, tc Server and dm Server

SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.

Adam Wiggins on Heroku

Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.

SOA as an Architectural Pattern: Best Practices in Software Architecture

For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.