InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Felix Bachmann on Evaluating Software Architecture

Posted by Srini Penchikala on May 26, 2009

Sections
Enterprise Architecture
Topics
Architecture ,
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.

 

Srini Penchikala currently works as Security Architect and has 17 yrs of experience in software product management.

No comments

Watch Thread Reply

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.