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

List Principles, Goals, and Constraints

Designing architectures is a tough and complicated job, and the solution space is virtually endless. To help you focus and limit the solution space, you can use three tools:

• Principles
• Goals
• Constraints

Stakeholders don't just sit there with their concerns and agendas—they can also introduce constraints related to: business (time constraints); technology (the company standard is to use WebSphere, for instance); or architecture. For example, on one of my recent projects, the customer required that the solution incorporate a parallel processing engine (grid) and that a single engine would be used in all subsystems that required parallel processing.

It's important to remember the constraints when you model solutions. I usually document each constraint, explaining what it is, its rationale, which stakeholder introduced it, and the scope of its effect.

Goals are similar to constraints in that stakeholders originate them. The difference is that while constraints are demands, goals are more on the "nice to have" side and tend to be more amorphous; for instance, you want the architecture to be open and based on standards.

Principles draw on our past experiences. Using principles from other similar projects can increase the chances you will be able to reuse assets from those projects. For example, a principle might be "we think that a federated database can work for this solution because it proved to be the best option in three other similar projects." You can document principles in a more formal manner by describing what they are, the rationale behind them, the benefits they bring, their liabilities and implications, the alternatives, and the scope of their effect. It is usually more worthwhile to manage principles in larger projects. Regardless of project size, and whether you carefully document principles or just spend some time thinking about them, you should be ready to forgo any of them if/when the actual requirements of the system at hand show they do not fit.

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.