SAIP (Chapter 11): ATAM
Chapter 11 focuses on the Software Architecture review process, specifically one called Architecture Tradeoff Analysis Method (ATAM). ATAM is a step-by-step process that is designed to evaluate a proposed software architecture to determine how best it addresses the quality attributes specified in its requirements.
The results of an ATAM review is invaluable to the success of a project's architecture, but in my opinion, it seems like a very expensive process, although, the author mentions that such a review ends up paying for itself in terms of cost savings by way of avoiding pitfalls that are determined during this process. I agree with this process being a big plus in a very big and mission critical project, but for most mid-sized and small projects (as mentioned by the author), ATAM is overkill.
I think ATAM can be adopted by smaller team projects by getting rid of some of the steps and fine tuning it for smaller groups. Maybe inviting a development team working on a separate project to fill the roles of the evaluators and then having a member of the decision-making stakeholders (the client) be present for a not so lengthy process could be good enough. Better still, I would prefer an approach similar to the role the customer plays in XP, where input is obtained more often and early enough to save the architect the pain of redoing the whole architecture (worst case). I guess if it gets to that point, then maybe the architect need not be the architect for the project, and we probably have a bigger issue at hand.
The results of an ATAM review is invaluable to the success of a project's architecture, but in my opinion, it seems like a very expensive process, although, the author mentions that such a review ends up paying for itself in terms of cost savings by way of avoiding pitfalls that are determined during this process. I agree with this process being a big plus in a very big and mission critical project, but for most mid-sized and small projects (as mentioned by the author), ATAM is overkill.
I think ATAM can be adopted by smaller team projects by getting rid of some of the steps and fine tuning it for smaller groups. Maybe inviting a development team working on a separate project to fill the roles of the evaluators and then having a member of the decision-making stakeholders (the client) be present for a not so lengthy process could be good enough. Better still, I would prefer an approach similar to the role the customer plays in XP, where input is obtained more often and early enough to save the architect the pain of redoing the whole architecture (worst case). I guess if it gets to that point, then maybe the architect need not be the architect for the project, and we probably have a bigger issue at hand.

0 Comments:
Post a Comment
<< Home