„Evaluating Software Architectures: Methods and Case Studiem” book review

Mood: In hurry

Introduction
The book describes three methodologies of reviewing system architectures:
ATAM – Architecture Tradeoff Analysis Method
SAAM – Software Architecture Analysis Method
ARID – Active Reviews for Intermediate Designs
It concentrates mainly on the first method and afterwards it describes the following two much more briefly (especially ARID) basing on previous material.

Content of book
The biggest advantage of the book is a very practical approach to the very abstract topic. It is a direct guide for a novice person showing step-by-step how to:

• prepare for evaluation
• make evaluation
• collect feedback from architecture review process

It includes the detail break down of the methods into phases and stages including the suggestions about audience, meeting agenda, topics to cover and threads including the ways of managing them. The authors of the book show a lot of real samples from particular stages of the process and provide number of very useful tips.

Mentioned methodologies do not cover the 360-degree review of the software architecture in particular project, but they concentrate on defining the main bottlenecks of the projects and following deliverables:

• Creating the usage attributes tree [drawing 3.4, page 72] with assigning priorities to them - ATAM
• Defining the most critical, common usage scenarios - ATAM, SAAM, ARID
  Creating the real risks list - ATAM
• Defining quality attributes [drawings 5.1-5.3, page 132; table 6.3, page 190] and quality targets - ATAM
• Synchronizing the knowledge about project and project vision among key persons in project - ATAM, SAAM, ARID
• Reviewing available project documentation and architecture - ATAM, SAAM, ARID

Chapter 9 and Table 9.1 [page 274] contains the detail comparison of all three methodologies.

ATAM
ATAM methodology is the precisely structured (into phases and stages) extension of SAAM method and it is the best fit for:

• Review of existing project before creating its new version or reuse in other project
• Formal review by external authority of started or existing software project (for example before taking some strategic decisions)
• Taking over the on-going or existing project from one team to the other
• ATAM focuses on big and medium software projects. Tables 2.1 and 2.2 [page 61] show the approximate cost of evaluation process (medium – 36 man days, small – 15 man days).

SAAM
SAAM methodology [Drawing 7.1, page 234] is more flexible approach to topics covered by ATAM. It is also applicable to big and medium projects, which are during realization or before creating the new version. The main difference between SAAM and ATAM are:
SAAM is focused mainly on functionality and extensibility of the project (ATAM covers wider set of attributes - also security, scalability and reliability)
Slightly smaller cost of the evaluation (minimum 2 days comparing to 3 days for ATAM)
More iterative way of creating the deliverables – agenda of meetings is the same each day and cover topics from all the stages, unlike ATAM, where each stage has different agenda

ARID
ARID is the only methodology mentioned, which is applicable during (and not after) the analysis phase. Like SAAM it is based on iterative approach, where agenda (for phase 2) is the same through the whole time of the evaluation process. Unfortunately, this methodology described in a very brief way, without a sample.

The cost of using this methodology is similar to SAAM (minimum 2 mandays).

ADR
The common point of described methodologies is the active approach to the review process (Active Design Reviews, ADR) and bringing back the real effects from the process. The main reason of doing it is to guide the evaluation process so it does not provide just junky type of reports “everything-goes-fine;don’t-worry”. The genesis for this approach is the article “Active Design Reviews: Principles and Practises” written by David Parnas and David Weiss described in details on page 261. It says among others about proper way of putting the questions (non-rhetorical, but focused on descriptive answer), what brings back much better answers and results from review process.

Other methodologies
The book mentions also the number of the other evaluations methodologies (in Chapter 9) like:

• Quality Attribute Workshop (page 286)
• Software Performance Engineering (SPE)
• Survivable Network Analysis (SNA)
  Etc.

They are not described in details and book is just a good reference point for further readings about them.

Source of Document Templates
Book provides also number of good template for number of documents like usage scenarios, usage scenario analysis [table 6.4, page 196], architecture approach [drawing 3.6, page 81], quality attributes, architecture drawings etc.

Opinion
It seems like authors of the book WANTED to create the full review of all “architecture review” approaches and they started it, with the full and a very nice ATAM overview, but afterwards it seems like they did not have enough steam to do the same for the other methodologies doing shorter and shorter descriptions in following chapters. At the end of the road, instead of a nice encyclopedia type of the book, it is in fact the book about ATAM and similar methodologies. It concentrates just on a middle and big projects, which already has started and does not give a lot of support for analysis phase (except short description ARID), where the most of this type of work SHOULD be done. Unfortunately, it seems like the reason of such approach is quite simple – the authors are selling their service and support in ATAM area.

There is number of references to other methodologies, but there is a visible lack of connection to software designing approaches like Agile methodologies, RUP, MSF or project management methodologies like Prince2 or PMBoK. Such two chapters would show much better where these processes could be applied during software development process.

Despite of the criticism, the book is definitely worth of reading as it is VERY practical and it shows a unique point of view for project managers, software architects, stakeholders and other key players in software development process. It provides a VERY good starting point for preparing the evaluation process, giving a number of nice tips; among others it says how to convince the stakeholders that the whole evaluation process is necessary and how to build the review architects team.

Final score: 4 (good)/6

Annotation
References to pages may be slightly different in English version of the book as the article bases on polish translation of the book made by Helion.