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 so on and so forth. Even if we say that flexibility and the ability to cope and embrace change is the most important trait (read quality attribute)for our architecture we still need a way to evaluate which approach will give us the most flexibility
The way I see it there are basically two approaches for evaluating software architecture
- In code – as in proof of concepts, architectural prototypes and architectural skeletons
- On paper/discussion based -so called “formal” methods: ATAM, ARID, LAAAM to name a few
I will try to use the next few posts on SAF to elaborate on these issues – where, the next post on SAF – Evaluation will explain and demonstrate the “in code” methods. The post following that, will talk about the paper based methods, and the third post on the subject, will try to contrast the two approaches and talk about their respective pros and cons
*As quoted by Martin fowler in “Who needs an Architect” – which, by the way, provides for a very interesting reading on architecture and the architect’s role.