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:
CategoryAttribute
System PerformanceReliability - 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 ControlMaintainability - 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 EvolutionExtensibility - 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:

Comments

Popular posts from this blog

Understanding ITIL Service Management the UML way…

Apache Web Server Troubleshooting