Software Architecture Quality Attributes

Following on to my previous blog-entry about Software Architecture Views and Perspectives, the book "Software Architecture in Practice" also describes a method called Attribute-Driven Design or ADD. This is not yet-another-design-method like BDD or TDD. ADD is concerned software architectural design (so it's at the "architecture-level" rather than what we might normally think of as the "design-level").

ADD is concerned with explicitly identifying the desired quality attributes of an architecture. Many of us know that simply implementing the (functional) requirements correctly is just the beginning of any good design, and possibly not even the most important attribute of the design. In addition to other attributes like security or availability, there are also attributes like modifiability of an architecture. And it is often these attributes that, if attained, are the true indication of whether or not we've done a good job.

Some of the more commonly desired quality attributes are:

• Availability
• Modifiability
• Performance
• Security
• Testability
• Usability
  

Many of us have also often had difficulty trying to explain to management the importance of things like "refactoring" and what that modifiability gives us in return. ADD makes such quality attributes an explicit goal of the architecture design process. One of the first things it asks us to do is the necessary homework (research and interviews) to analyze and identify what are the desired quality attributes for our architecture and its stakeholders. It also defines use-case-like entities called Quality Attribute Scenarios, which is a way of expressing such non-functional requirements as an explicit use-case (which can then have an associated business-value).

ADD also explicitly mentions the use of patterns and tactics as part of its methodology for achieving quality attributes and making design tradeoffs (quality attributes are often the "forces" for a pattern). For each of the common quality attributes above, it identifies a taxonomy of common tactics and patterns used to make good tradeoff decisions for particular aspects of the design.

Although it look s a bit heavyweight, ADD looks promising in its use of patterns and tactics and recursive/iterative nature. But what I like most about it is that fact that it makes explicit the kinds of quality attributes and their non-functional use-cases or "stories" which can then have business value/priority associated with it, and thereby justify the existence of activities that help realize those attributes of the system.

For some more information on ADD, see the following:

• Software Architecture in Practice
• The SEI webpage on Attribute-Driven Design
• The paper Quality Attribute Design Primitives and ADD
• Introduction to the ADD Method
• A Practical Example of Applying ADD (SEI Technical Report)
• Links from Real-world Software Architecture in .NET Developer's Journal
• Presentation from Paul Clements on Designing Software Architectures
  
• The paper Generalizing a Model of Software Architecture Design from Five Industrial Approaches (by a star-studded list of authors in the field)
  

Now I want to ask the question of applying this same idea to software processes and software process architecture: Seems to me that in Agile development, we're really not anti-process, but there are some really important things (quality attributes of a process?) that we feel are often left out to pasture by a lot of the very formal, CMMI-based processes we witness. Perhaps they're ignoring these important process-design quality attributes? (as embodied in the Agile Manifesto?)