Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS The SPAMMED Architecture Framework Identify Stakeholders List Principles, Goals, and Constraints Discover Quality Attributes Model & Map to Technology Evaluate & Deploy Conclusion

Evaluate

Architectural decisions are made early, and once made, they're hard to change. This means that it is extremely important for you to ensure that architectural decisions are right. To me, the premise of "test early/test often" is also applicable to architecture. Thus, once you have made some decisions (while modeling and mapping), you want to evaluate your decisions and validate your assumptions. An artifact that can help you in evaluating architectures is the quality attributes scenario. In fact, this is the way it was originally used in evaluation methodologies, such as ATAM.

It is preferable to evaluate the architecture in code; after all, this is how it will eventually be used. There are several possibilities for evaluating architecture in code—simulations, proof-of-concept (just enough code to validate a single decision), prototyping (making several architectural components work together), and building a skeleton (similar to prototyping, except the end result is the basis for further development). When you test the architecture in code, you can also use additional techniques such as Test-Driven Design (TDD) to further refine the design.

If you are still looking at the system in a higher level of abstraction (compared to code), it can be harder to dive to code, so you can draw on formal evaluation methods. The Software Engineering Institute (www.sei .cmu.edu) offers several evaluation techniques (ATAM, ARID, and the like). Microsoft introduced one (LAAAM) as part of MSF 4 for CMMI improvement , CERT has Survivable Network Analysis, and there are others. Evaluation on paper can take between a couple of hours to several days, depending on the method used. Formal evaluation requires the participation of various stakeholders to be successful. Both evaluation approaches (evaluation in code and on paper) complement each other to help you make the right decisions.

Deploy

Once you are satisfied with the current state of the architecture, deploying it is the next activity. Deployment means that development teams utilize it for developing system functionality (this can be early in the process if you are part of an Agile team). If you are a responsible architect, this doesn't mean it is time to disengage—far from it.

There are two motivations for you to continue working with the teams:

• Governance. It is your responsibility to ensure that the architecture is followed. Developers have all the reasons in the world not to follow the architecture—ranging from prosaic (you communicated the architecture poorly and no one really understood you) to deadlines imposed by management that lead to cut corners for on-time delivery. You need to make sure (assuming you believe in the architecture you drafted) that the architecture will not be circumvented. Architects are usually not the direct manager of developers, so you'd have to lead rather than command (which is better anyway). You can choose techniques such as pair programming, mentoring, meetings, and presentations.
• Verification. It is your responsibility to ensure that the architecture fits the actual needs of the software. I don't know about you, but when I code, I have bugs. The same is true for architecture modeling—mistakes will happen, and because architectural decisions affect the entire system, an error can result in adverse results. Working with the team on the design of various modules (participating in design and code reviews and/or coding), you can (and should) pay attention to the implications of the architectural decisions and make sure that the decisions are both valid and easy to use. Should the architect spot problems, she should repeat one or more of the previous activities (modeling, evaluation, and so on).

Previous Page | 1 The SPAMMED Architecture Framework | 2 Identify Stakeholders | 3 List Principles, Goals, and Constraints | 4 Discover Quality Attributes | 5 Model & Map to Technology | 6 Evaluate & Deploy | 7 Conclusion Next Page

RELATED ARTICLES No Related Articles		TOP 5 ARTICLES No Top Articles.