Utility trees and quality attributes

Posted on April 27th, by Arnon Rotem-Gal-Oz in Blog, SAF. No Comments

I recently answered this question in Stackoverflow :


What is an utility tree and what is it’s purpose in case of Architecture tradeoff analysis method(ATAM)?

 I did answer the question there but here’s a better explanation with lots of examples base on the initial version for chapter 1 of SOA Patterns (which didn’t make it into the final version of the book).

There are two types of requirements for  software projects: functional and non-functional requirements. Functional requirements are the requirements for what the solution must do (which  are usually expressed as use cases or stories). The functional requirements are what the users (or systems) that interact with the system do with the system (fill in an order, update customer details, authorize a loan etc.).

Non-Functional requirements are attributes the system is expected to have or manifest. These usually include requirements in areas such as performance, … Read More »

SAF – Evaluation part II – the “Formal Methods”

Posted on May 11th, by Arnon Rotem-Gal-Oz in SAF. No Comments

Onthe previous post on architecture evaluation  I talked about evaluating a candidate architecture in code. This post is dedicated to evaluation on paper.

I remember one system I was working on, I was keen on making the architecture asynchronous and message oriented (it was all circa 2001 by the way) However, I was new on the team and my role (as the project’s architect) wasn’t well defined so I had to do many compromises and get wide acceptance in order to get anything going forward. We set a team to try to come up with a suitable architecture, since each of the team members had his/her own experience we came out of these meeting with more than 20 (!) different candidate architectures (actually there were fewer architecture variations but they were multiplied by the possible technology mappings). Trying to decide which was … Read More »

SAF – Architecture Evaluation (Introduction)

Posted on May 11th, by Arnon Rotem-Gal-Oz in SAF. No Comments

I said  in “what’s Software architecture” – architecture is both an early artifact and it also represents the significant decisions about the system – or to sum it up  ”Architecture is the decisions that you wish you could get right early in a project.”  (Ralph Johnston*). That is exactly why I made evaluation one of the key steps in SAF. We want to raise the level of certainty that the direction(s) we are taking are indeed the right ones and we will not hit a wall later on. Especially considering most projects these days are iterative, which makes this even more challenging.

But, how do you evaluate an architecture? (on a give set of quality attributes) How can you tell if utilizing, say, SOA, will yield better results than distributed objects ? Is using fault-tolerant hardware better than using a database (on performance vs. robustness trade-off)? and … Read More »