There are at least two activities normally associated with the discipline of Software Architecture: creating a new architecture and evaluating an existing one. There are a number of methodologies for both activities, but in this post I will talk about one technique: architecture via quality attributes.
It’s probably not surprising to most readers that typical Quality Attributes are characteristics like Performance, Availability, or Maintainability. It might not be extreme to say that Quality Attributes are all those traits of a software system, other than Functionality, by which we can decide if the system meets its goals. Functionality is always present as an attribute of a system that has been built correctly, because it is simply the measure of whether the system does the work it was intended to do. However, there are many other Quality Attributes, and not all of them are important, or equally important, for each system.
Examples of Quality Attributes are those things we sometimes called “abilities”: Performance, Reliability, Maintainability, Availability, Testability, and so on. You can probably think of many of your own “abilities”, and there are many lists of them in articles, books, and online. (See for example this link or this one.) There’s even an ISO/IEC standard for such attributes, which you can see here.
I reference these various lists, and there are many more in “the wild”, not because it’s an Architect’s job to ensure that all the abilities are accounted for in a design, but to show how many possible traits a software architecture may possess. Thus, an effective software architecture is one that balances the abilities that are important to the system under design. Sometimes these are referred to as the architecturally significant (or driving) attributes.
Just using a list of Quality Attributes and putting check marks next to the ones an architect believes are accounted for by her design is not going to ensure that the relevant Quality Attributes are truly present. A first step to designing a successful software architecture is deciding which of the long list of possible Quality Attributes are relevant to the project, and of these, which are the most important. This step cannot be done in isolation, but must involve project stakeholders.
The SEI at Carnegie Mellon University has pioneered the technique of the Quality Attribute Workshop as a way of soliciting relevant Quality Attributes, and identifying which are the most important. The goal of this exercise is to derive what the SEI refers to as the driving quality attributes for a system.
This iterative process has many benefits, including increasing communication to stakeholders, clarifying the most important non-functional attributes, and helping focus the architect’s vision on meeting those attributes.
What about the situation when an architecture is already developed? It’s not too late to evaluate the architecture, and an effective way to start out that evaluation is by identifying the Quality Attributes the system was meant to embody. The process for doing that is remarkably similar to the process of enlisting Quality Attributes in building an architecture. In a nutshell, the steps are:
If, as I’ve hoped, this article has stimulated an interest in learning more about Quality Attributes in relation to software architecture, I recommend the following resources.