We all know that reducing risks in early phases of software development lifecycle is extremely important. We all agree that we must ‘fail fast’, that code must be tested and reviewed, we thrive for TDD and high code coverage.
But what about the architecture? How do we evaluate it? Oh, we don’t test it? But why?! We just trust the architecture is good? Or maybe we don’t have an architecture, we consider that architecture is not important, or we don’t know how and when to evaluate it. I suspect the latter…
I decided to start a series of posts on architecture evaluation, with the intention to learn together, improve the collective knowledge around architecture evaluation methods, and raise awareness around an apparently forgotten topic.
This sketch I made summarises the Architecture Tradeoff Analysis Method (ATAM), maybe the most popular risk mitigation process usually applied in early phases in the software development lifecycle.
I am interested in fellow architects, engineers, managers opinion on the subject. Do you evaluate architecture?
If yes, how and when? Do you use ATAM or other methods?
No? Why?
