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

Model

Modeling is the most obvious activity. It can be done on whiteboards, with case tools, or even with a word processor. The level of detail depends on the requirements (sometimes a customer demands a detailed document as part of the contract), the team level (experienced developers require less detail than inexperienced ones), and the development process (Agile processes require less documentation).

Another point to remember is that design should be conveyed from multiple viewpoints (see IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems, ISBN 0738125180). Each stakeholder has different concerns and different viewpoints that help demonstrate how the architecture addresses these concerns. For example, a deployment or physical view helps communication with operations and/or system engineers by demonstrating what software runs on what hardware, the hardware needed, the network topology, and the like.

Map to Technology

Granted, mapping technologies is not an architectural activity per se. Choosing one technology over another usually will not change the quality attributes of the system. However, the architectural implications become evident when the wrong technology is used. For instance, using Microsoft Access where Oracle RAC 10g should be used will greatly affect performance and availability. Another problem that can occur is misalignment of the technology (to the architecture). The result is hard work for the development team, which can, in turn, result in rejecting the architecture all together. For example, if you decided to build a rich-web client (AJAX, for instance), servlets are probably not the way to go about developing it.

Another aspect of mapping to technology is to make decisions involving buy versus make versus reuse versus customize.

• Make will get you the best alignment with the architecture, but will cost you time and money to develop (and the component may well be one that is not in your organization's core business).
• Reuse is taking some existing asset from another project and using it as-is.
• Customize is similar to reuse (you take an existing asset), but you clone and own it instead of using it as-is.
• Buy is taking a third-party solution to fill a particular block in the architecture. Buying a ready-made solution can be cost effective. However, usually the match is not 100 percent and the architecture sometimes has to be adjusted to fit the product.

All of these decisions are similar to architectural decisions in that they tend to have ripple effects solution-wide. Also, technology decisions affect the detail design. For example, if the project needs some way to move messages around, it is always possible to start at the socket level and develop some proprietary solution. Or maybe you can buy a JMS solution. However, if you are using SQL Server 2005, why not utilize a service broker? Or maybe web services interoperability would be better.

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.