System Architecture and Design Trade-off Document

It is a great idea to write a System Architecture & Design (SAD) Trade-off Document.

The format is tabular and will look like the following:

1. Module/ category
2. Issue description
3. Possible alternatives
4. Decision
5. Decision rationale
6. Traded-off attributes
7. Traded-in attributes
8. Consequence/ constraints introduced

Some examples of traded attributes are listed in the following table:

Category	Attribute
System Performance	Reliability - ability of the system to maintain operating over time (MTTF)
	Performance - responsiveness of the system to stimuli or events as well as throughput of the system
System Control	Maintainability - ease with which a system can be modified to correct faults, improve performance, or adapt to changing environment
	Data timeliness - data latency for information flowing into and out of the system
	Security - measure of system's ability to resist unauthorised access or DOS
	Supportability - ease with which a system can be maintained operationally
	Testability - ease of system testing
	Usability - measure of a user's ability to utilise a system effectively
	Decoupling - measure of how systems are independent of one another
	Data integrity - integrity of the overall structure
	Functionality/ feature - ability of the system to do the work for which it was intended
	Familiarity - based on existing skill-set of the developers
	Cost reduction - reduction in general project cost to meet timeline or due to cost constraint
	Effort reduction - reduction in general project cost to meet timeline or due to cost constraint
System Evolution	Extensibility - ability of the system to extend for enhancements
	Reusability - degree to which an artefact can be used in other systems
	Flexibility - ease with which the system can be modified for use in environment not originally intended for
	Interoperability - ability of the system to exchange information with other systems

The rationale for writing this is as follows. The document serves as a means for:

1. communication to the rest of the team regarding important principles and decisions
2. putting the team on the "same page" regarding the rationale behind decisions impacting system architecture and design
3. communicating with senior management & stakeholders who may be interested in the decisions
4. future hand-over to another team or posterity
5. forcing explicit reasoning to validate decisions
6. re-evaluating a decision when conditions change in the future

A sample follows: