| The software architecture of a system promotes, enforces, and predicts the quality attributes that the system will support. Quality attributes are those system properties over and above the functionality of the system that make the system a good one or a bad one from a technical perspective. There are two types of quality attributes: those that are measured at run-time and those that can only be estimated through inspection. Since the software architecture of a system is a partial design of a system before it is built, it is the responsibility of the software architect to identify those quality attributes that are most important and then attempt to design an architecture that reflects those attributes. The quality attributes that most architects should be concerned with are (Bass, Clements, Kazman 1997; Clements, Kazman, Klein 2002): Performance a measurement of the system response time for a functional requirement. Availability the amount of time that the system is up and running. It is measured by the length of time between failures, as well as by how quickly the system is able to restart operations after a failure. For example, if the system was down for one day out of the last twenty, the availability of the system for the twenty days is 19/19+1 or 95 percent availability. This quality attribute is closely related to reliability. The more reliable a system is, the more available the system will be. Reliability the ability of the system to operate over time. Reliability is measured by the mean-time-to-failure of the system. Functionality the ability of the system to perform the task it was created to do. Usability how easy it is for the user to understand and operate the system. Security the ability of the system to resist unauthorized attempts to access the system and denial-of-service attacks while still providing services to authorized users. Modifiability the measurement of how easy it is to change the system to incorporate new requirements. The two aspects of modifiability are cost and time. If a system uses an obscure technology that requires high-priced consultants, even though it may be quick to change, its modifiability can still be low. Portability measures the ease with which the system can be moved to different platforms. The platform may consist of hardware, operating system, application server software, or database server software. Reusability the ability to reuse portions of the system in other applications. Reusability comes in many forms. The run-time platform, source code, libraries, components, operations, and processes are all candidates for reuse in other applications. Integrability the ability of the system to integrate with other systems. The integrability of a system depends on the extent to which the system uses open integration standards and how well the API is designed such that other systems can use the components of the system being built. Testability how easily the system can be tested using human effort, automated testing tools, inspections, and other means of testing system quality. Good testability is related to the modularity of the system. If the system is composed of components with well-defined interfaces, its testability should be good. Variability how well the architecture can handle new requirements. Variability comes in several forms. New requirements may be planned or unplanned. At development time, the system source code might be easy to extend to perform new functions. At run-time, the system might allow pluggable components that modify system behavior on the fly. This quality attribute is closely related to modifiability. Subsetability the ability of the system to support a subset of the features required by the system. For incremental development, it is important that a system can execute some functionality to demonstrate small iterations during product development. It is the property of the system that allows it to build and execute a small set of features and to add features over time until the entire system is built. This is an important property if the time or resources on the project are cut. If the subsetability of the architecture is high, a subset of features may still make it into production. Conceptual integrity the ability of the architecture to communicate a clear, concise vision for the system. Fred Brooks writes, "I am more convinced than ever. Conceptual integrity is central to product quality. Having a system architect is the most important single step toward conceptual integrity. . . . After teaching a software engineering laboratory more than 20 times, I came to insist that student teams as small as four people choose a manager and a separate architect" (Brooks 1995). Kent Beck believes that metaphors are the most important part of the eXtreme Programming methodology (Beck 1999). The metaphor is a powerful means of providing one or more central concepts for a system. The metaphor provides a common vision and a shared vocabulary for all system stakeholders. The metaphor provides a means to enforce conceptual integrity. When the design of the system goes outside the bounds of the metaphor, the metaphor must change or new metaphors must be added; otherwise, the design is going in the wrong direction. If any of these design decisions are made without the concept feeling right, the conceptual integrity of the system will be lost. Sometimes the system metaphor is an architectural pattern, such as MVC or Blackboard (discussed later in this chapter). These architectural patterns provide a common metaphor for system developers or others who understand the patterns. However, they don't help the stakeholders who aren't familiar with the patterns. One good thing about using architectural patterns for the system is that they describe the structures of the software in more detail; on the downside, not all stakeholders will understand the references. Buildability whether or not the architecture can reasonably be built using the budget, staff, and time available for delivery of the project. Buildability is an often-overlooked quality attribute. Sometimes, the best architects are simply too ambitious for a project team to complete given project constraints.
Is Agility a Quality Attribute? Some architects use the term agile to describe their architecture. While flexibility and agility are important, these words have many dimensions. If the architecture is agile, does that mean that it is easily changed? Is it easy to integrate it into the enterprise? Is it portable, reusable, testable? The answer to all these questions is probably "yes." Agility is a composite quality that includes many of the base quality attributes. If the levels of maintainability, portability, testability, and integrability are high, the architecture is most likely an agile one. 
|
It is important for the system and enterprise architecture designers to understand the desired qualities that the systems must exhibit. To do so, the architects should encourage as precise a specification of the desired quality attributes as possible. A checklist provides a way of ensuring the completeness of the specification. Following are some of the questions to ask in order to fully characterize the desired quality attributes for a system (Clements, Kazman, and Klein 2002; McGovern, Tyagi, Stevens, and Mathew 2003): Performance What is the expected response time for each use case? What is the average/max/min expected response time? What resources are being used (CPU, LAN, etc.)? What is the resource consumption? What is the resource arbitration policy? What is the expected number of concurrent sessions? Are there any particularly long computations that occur when a certain state is true? Are server processes single or multithreaded? Is there sufficient network bandwidth to all nodes on the network? Are there multiple threads or processes accessing a shared resource? How is access managed? Will bad performance dramatically affect usability? Is the response time synchronous or asynchronous? What is the expected batch cycle time? How much can performance vary based on the time of day, week, month, or system load? What is the expected growth of system load?
Availability What is the impact of a failure? How are hardware and software failures identified? How quickly must the system be operational after a system failure? Are there redundant systems that can take over in case of a failure? How do you know that all critical functions have been replicated? Are backups done? How long does it take to back up and restore the system? What are the expected hours of operation? What is the expected up-time per month? How available is the current system? Is this acceptable?
Reliability What is the impact of a software or hardware failure? Will bad performance impact reliability? What is the impact of an unreliable system on the business? Can the integrity of the data be compromised?
Functionality Does the system meet all the functional requirements specified by the users? How well can the system respond and adapt to unanticipated requirements?
Usability Is the user interface understandable? Is the interface adaptable to support the needs of people with disabilities? Do the developers find the tools provided for creating the system usable and understandable?
Portability Do the benefits of a proprietary platform outweigh the drawbacks? Can the expense of creating a separation layer be justified? At what level should system portability be provided? At the application, application server, operating system, or hardware level?
Reusability Is this system the start of a new product line? Will other systems be built that more or less match the characteristics of the system under construction? If so, what components will be reused in those systems? What existing components are available for reuse? Are there existing frameworks or other code assets that can be reused? Will other applications reuse the technical infrastructure that is created for this application? Is there existing technical infrastructure that this application can use? What are the associated costs, risks, and benefits of building reusable components?
Integrability Are the technologies used to communicate with other systems based on standards? Are the component interfaces consistent and understandable? Is there a process in place to version component interfaces?
Testability Are there tools, processes, and techniques in place to test language classes, components, and services? Are there hooks in the frameworks to perform unit tests? Can automated testing tools be used to test the system? Can the system run in a debugger?
Subsetability Is the system modular? Are there many dependencies between modules? Does a change in one module require a change in other modules?
Conceptual Integrity Do people understand the architecture? Are there too many basic questions being asked? Is there a central metaphor for the system? If so, how many? Was an architectural style used? How many? Were contradictory decisions made about the architecture? Do new requirements fit into the architecture easily, or do new features require "code smells"? If the software starts to "stink," the conceptual integrity has probably been lost.
Buildability Are enough time, money, and resources available to build an architecture baseline and the project? Is the architecture too complex? Is the architecture sufficiently modular to promote parallel development? Are there too many technical risks?
This is by no means an exhaustive list of questions to ask about architecture or a design. On every project, there are specific questions to ask about the domain of that project and organization. For example, if an organization uses messaging middleware, there is a list of very specific questions about how that middleware system is used and whether or not the architecture uses it effectively and correctly. If the organization has an in-house framework for creating components and services, there is a list of questions about the design of a component or service that uses that framework. The questions that must be asked on each project vary. It is important that the architecture team understand the intricacies of the organization's domain, the architecture that supports it, and, especially, the obstacles that may be encountered so that they can be avoided. Only if a design team is aware of the details of a particular organization can it properly design a system that runs in that organization. Nonfunctional Requirements and Quality Attributes Nonfunctional requirements are almost the same as quality attributes. Nonfunctional requirements are defined as the nonobservable properties of the system. A classical functional requirement can be stated as a noun verb phrase, such as "The system displays the report." A nonfunctional requirement can be thought of as a modifying clause, such as "The system displays the report within 5 seconds." In other words, a functional requirement is stated in mathematical terms. An input is given to a function, and the function returns an output. The nonfunctional requirements state how the functions of the system will be performed. The big problem with nonfunctional requirements is that most requirements gathering teams tend to leave these requirements out, or they do not fully state the nonfunctional requirements of the system. They do this because they focus only on the business case for the system. They concentrate on the business stakeholders and not on the technical stakeholders of the system. Requirements such as modifiability, security, and so on are usually overlooked because they are not perceived as directly impacting the cost-benefit for the system. These requirements are perceived as being only technically related requirements. This is not true. Nonfunctional requirements are critically important to the success of any project. They are technical risks that, if not addressed, can make or break a system. For example, if a report displays correctly but it does so in thirty minutes instead of a more reasonable thirty seconds, the functional requirement is met but the system is not usable because it does not meet the user's performance expectation. If a hacker is able to retrieve credit card information for the businesses customers, for example, the future of the company may be in jeopardy. Nonfunctional requirements are not only within the jurisdiction of the project under development. The quality attributes of a system are supported at the enterprise level. Typically, the reliability, availability, performance, and other quality attributes are supported by the platform on which the project is deployed. | 