Architecture Quality Attributes

Architecture Quality Attributes (a.k.a. QAs) are used to determine if our architecture is fit for a particular purpose. Qualities must be accommodated in a system's architecture over and above basic functionality. It is too often that functionality takes the front seat, indeed sometimes the only seat. The functionality however should be the primary concern of the DEV teams not necessarily the architect. Obviously, the functionality is important, but in the end, the system may do what you want but be: hard to use, difficult to extend, impossible to port to other platforms, too slow, uncertifiable etc. These are the sort of attributes the architect concern themselves, primarily.

There are really 2 types of attributes:

  1. Business Qualities - I have talked about these here
  2. Those that can be observed during operation (execution) of the system e.g. performance - these are known as observable. Although, we say that performance is an observable during operation, the architect doesn't really have the software executing i.e. at least not when the key architectural decisions are being taken. This is why the architect needs to make certain assumption and use available data. For example, DB system may be able to handle only X amount of queries per second. Is this the traffic that is expected, or do we need to start replicating the databases? Similarly, how do you judge the reliability before the system is built?
  3. Those that cannot be observed during operation (execution) of the system e.g. maintainability - these are known as unobservable

Those categories are almost independent. A classic example may be API, which improves maintainability but reduces performance.

Observable Attributes

The observable attributes include:

  1. Performance - is the system fast enough.
    1. Amount communication between components
    2. Distributed algorithms
  2. Security - is the system secure enough
  3. Usability - not what colours to use, but how will the user accomplish their goals (read more: Is usability an architectural concern?
  4. Reliable - is the output from the system sufficiently reliable? How often will it deviate from the specification
  5. Availability - how much of the system can be used? How long does it take to bring it back up again? Will the time significant?

Unobservable Attributes

The unobservable attributes include:

  1. Cost of development
  2. Modifiablity - Ease of modification
  3. Reusability - Ease of reuse
  4. Ease of certification
  5. Portability
  6. Interoperability
  7. Certifiability

It may not be possible to measure these, but it may be possible to evaluate.

Leave Comment

Your email address will not be published.

Please type the characters of this captcha image in the input box

Please type the characters of this captcha image in the input box