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 – Deployment – What to do when the architecture seems stable?

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

The last activity of SAF is deployment of the architecture.  This step can make the difference between an ivory-tower architect and one whose designs are actually used in real software projects.

Deployment of the architecture actually  means two things

Verification and feedback loop. – making sure the architecture is actually the right one.
Governance – making sure that the architecture is followed by the designers and developers

Verification and Feedback loop

It is common practice to think of software development as an iterative process. Knowing that Software architecture is early and that it encompass the important decision which are hard to change, it is probably wise to think of the first few iterations as architectural ones. You would try to work with the team and form the major abstractions, hopefully come up with a blueprint for processes etc. However, the fact that you’ve decided only the … 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 – Evaluation in Code

Posted on May 11th, by Arnon Rotem-Gal-Oz in SAF. 1 Comment

In SAF – Architecture Evaluation (Introduction) I said there are two approaches to evaluating a software architecture. This post talks about the first approach – evaluating an architecture in code.


The first evaluation-by-code tool is the  Proof of Concept (POC for short). Building a POC is about building a minimal amount of code implementing  a focused area of the architecture or the architecture’s  technology mapping. The aim of the POC is to help weight alternatives (when you are contemplating which way to go), lower technical risks or lower stakeholders’  anxiety over an architectural choice.

POCs map quite well into XPs spikes

Lets look at a few POC examples (examples from my past projects)

Example 1: Validate the feasibility of an architectural direction

On one project we inherited this ugly application incorporating its own proprietary cgi web-server,  the architectural decision was to keep this as a black-box and develop the project using … 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 »

SAF – Mapping -Don’t forget the Technology

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

The next step in SAF after Modeling is technology Mapping. While mapping  is not a part of the architecture per se, it is, in my opinion,  an important and sometime crucial step.

Before I rumble on explaining why I think this is an important step, let me try to define what exactly do I mean by “technology mapping”

Architecture in essence is technology neutral – it describes the major components (read objects/services/components etc.) and their interactions -  but it doesn’t specify what technologies and what technologies, products or existing assets will be used to implement it – that’s where Technology Mapping steps in.

For example, in a previous post (Architectural Modeling – First Step ) I presented the following block diagram as a possible view for an architecture (Layer diagram):

One possible technology mapping for this (view of an) architecture  is depicted in the following diagram:

Before I continue … Read More »

Modeling – Architectural Styles

Posted on May 11th, by Arnon Rotem-Gal-Oz in SAF. 1 Comment

I claimed in the past (on my “what’s software architecture” post) that Architecture is a type of design – if that is true, an interesting question is do we also have architectural patterns ?

I think the answer is yes – there are architectural patterns they are also called architectural styles – I actually like this term better as it is helps differentiate them from design patterns; for example I agree with  Harry Pierson’s observation that many of the patterns in Martin Fowler’s PoEAA are indeed technical patterns at an engineering or design level and not architectural patterns.

The difference between architecture styles and design patterns is similar to  the distinction between architecture and design – architectural styles effect the solution globally or at least it affects major parts of the solution and not solve local issues. Although it is interesting to note that some architecture styles … Read More »

Architectural Modeling – Choosing your Viewpoints

Posted on May 11th, by Arnon Rotem-Gal-Oz in SAF. 1 Comment

Ok, so we’ve identifies stakeholders, set principles and guidelines, found out what are our architectural requirements and we want to start modeling already – especially considering architectural modeling is great fun (for techno-geeks like myself anyway). However, before we just start to create an endless flurry of blocks, boxes, arrows and whatnot, it is probably worthwhile to take a few minutes to think which Models we want to create and what views do we want to use to communicate them otherwise we may end up doing a very good job thinking about and describing something that doesn’t interest anyone and gives no real value.

IEEE 1471 defines (an architectural) view as a representation of a whole system from the perspective of a set of concerns (where concerns are the key interests of the different stakeholders)

A view is comprised … Read More »

Architectural Modeling – First Step

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

The next step in SAF (after “quality Attributes”) is Modeling.  Webster’s dictionary defines “Model”  as (among other things) : “3 : structural design; 7 : Archetype ; 10b : a type or design of product (as a car);11 : a description or analogy used to help visualize something (as an atom) that cannot be directly observed” – as I mentioned in my what’s software architecture post there’s no single structure that IS the architecture – this means that we’ll have to look at the architecture from different angles (viewpoints) – for example a block diagram such as the diagram below  (accompanied with some documentation that explains it) may tell us something about the layers that will be used to solve a problem it tells us nothing about the business that we are trying to solve.

We need to augment with more views on the system (such as the next diagram) so that we can … Read More »

Architecture & Functional Requirements

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

In previous posts (here and here) it seems I downplayed the importance of functional requirements (vs. quality attributes) on the architecture. Nevertheless the functional requirements do have few  important roles in shaping/looking at  the architecture. One aspect of the functional requirements role was demonstrated in the scenarios that describe the instantiation of quality attributes within the system. Lets look at a couple of other aspects.

As I mentioned in a previous post no single structure is the architecture – this means that in order to present an architecture it is needed to describe it from several different angles or viewpoints (I’ll spend some time taking about these in the next few posts on SAF). One of these has to do with the domain architecture for the solution. This can include identifying business areas trying to identify services (in an SOA), identifying major components for … Read More »