Our fictitious automobile manufacturer Canaxia was losing sales to other manufacturers because it relied completely on its dealer network to sell its cars. Other auto manufacturers created Web sites that allow customers to customize and order their car online. The other auto manufacturers ship the cars from their manufacturing facilities directly to the customers through local dealerships. This resulted in greater customer service and reduced the hassle of buying a car from a dealership and struggling with the sales process. Canaxia was about two years behind their competition. The management of the company has decided to fund a project for twelve months to create a Web site and related infrastructure that exceed the capability of their competition. Canaxia has a mainframe system for orders, inventory, and financials. Its inventory and order system was written in the 1980s. The system functions, but it is very expensive to change. The financial system was purchased and customized in the late 1990s. The infrastructure architects have decided that IBM MQSeries will be used to integrate all the enterprise systems. The standard for Web development in the company is Java and J2EE. The architects on the project faced a difficult job. They realized that the software architecture is implemented at the beginning, middle, and end of every project. However, much more emphasis is on it at the beginning of every project. Before the architects started, they created a checklist of principles they would strive to follow while they created the architecture:
The following sections describe the steps that the architects at Canaxia performed to create their architecture (Bass, Clements, and Kazman 1997). The Business CaseCanaxia was lucky; it involved the architecture team when it created the business case for the system. Many organizations do not involve an architect at project conception. The architecture team was involved from the start of the project. The business customers needed to understand the relative costs of the various solutions they were contemplating. The architecture team understood the current technical environment and the tools, processes, and personnel required to implement the various options presented by the business community. The business customers realized that a great solution that is late is sometimes worse than a mediocre solution that is delivered quickly. Only the architecture team can evaluate the various options and provide input into the time required to create each one. At Canaxia, the architect was involved up front with auto dealers, management at the company, system end-users, and the development team. The business case took into consideration the timeframe and the technical complexity involved in creating a Web site for the automobile business. Understanding the RequirementsCanaxia realized that an architect couldn't build architecture for a system that he or she didn't understand. The requirements of the stakeholders provide the architect with a context from which to create a design. A use case is a common way of capturing a requirement. The use case describes some action that the system must perform. A use case describes in detail every input/output interaction that the system performs with a user or another system. These are known as functional requirements. In addition, the use cases specify how the interaction will occur. These are modifying clauses known as "nonfunctional requirements." For example, the use case, "User enters amount, presses enter, and system displays the invoice" is a functional requirement. A nonfunctional requirement modifies this phrase, such as "User enters amount, presses enter, and system displays the invoice within 5 seconds." The "within 5 seconds" is a nonfunctional or quality requirement of the system. The architect must document how the system will accept the amount described in the use case by using a user interface, validating the request, storing the data in a database, and generating an invoice for the user. There is no architecture for the use case, but the architecture must satisfy all the use cases, including the nonfunctional or quality requirements. The architecture should address each pattern of interaction, such as "User enters data, data are saved to database, a result or an error is displayed." At Canaxia, the requirements were well documented, but even more importantly, user representatives were involved in every stage of the project and provided daily input into the architecture and development of the system. Creating or Selecting the ArchitectureThe requirements gathering process delivers a set of functional requirements with qualities identified with each requirement. At Canaxia, these requirements were a set of use cases or user stories. Each use case had a set of qualities that needed to be supported by the use case. The architecture that Canaxia selected needed to support all these requirements and qualities. Some of the requirements were easily met using techniques, technologies, and practices with which the developers and architects were familiar. The difficult part of selecting the architecture was satisfying those qualities using techniques and technologies that were risky and unknown. To address and reduce the technical risks in the project, the architects created an architecture baseline. This was the main milestone in the development of the architecture (Jacobsson, Booch, Rumbaugh 1998). The architecture baseline is the first fully executable portion of the system. A small thread of execution through all system layers was completed to prove that the system could be built. To create an architecture baseline, the architecture team followed the steps described in the following paragraphs. These steps were performed in an iterative manner with the architects working toward an architecture baseline that satisfied the functional and quality requirements for the system: Select Use CasesSelect a small number of use cases from the requirements for the system. These are selected to address the most technically risky areas of the system. This subset of use cases is the architecturally significant use cases. For example, Canaxia chose a new software package for printing documents from the system. It included the use cases for printing documents in the architecture baseline to demonstrate that the interface to the new software package was going to work. Identify Important QualitiesSoftware architecture requires trade-offs. Canaxia could not get the architecture to satisfy every requirement in the best possible way. Therefore, the qualities that the architecture should support were prioritized. For example, Canaxia valued performance over modifiability. When decisions required a trade-off between quality attributes, it was helpful to understand what quality attributes were desired more than others in the system. Design the ArchitectureCanaxia designed an architecture that was able to implement the use cases that were chosen for the system. This involved adopting one or more architectural styles (described later in this chapter) and fleshing out those styles into a more detailed design. Canaxia decided to use the most well-known architectural style, the model-view-controller architectural style. Canaxia knew it was done with this step when the decisions it was making became harder and harder because less tangible information on which to rely was available. Set Up a Development EnvironmentCanaxia then set up a development environment that included:
Implement the DesignCanaxia started implementing the design. This was done by first implementing the tests for the design. Writing the tests fleshed out the contracts in the modules. When Canaxia began implementing the design, it learned what did and didn't work. Implementation will prove what was just theory in the design and will provide a concrete understanding of the architecture being developed. Canaxia stopped implementing when it exhausted the initial designs. When this happened, Canaxia improved the design and implemented more of the architecture in several more iterations until they were happy with it. Know When You Are Happy with the DesignThe architecture team tried to establish how to know whether or not the architecture was a good one. It adopted the following checklist of early warning signs when things might be going astray (Abowd et al. 1996):
The architecture team finished the baseline architecture and felt good about it. It was careful to notice "code smells" during the creation of the baseline. These were aspects of the code that just didn't feel right. When the team saw something sneak in that didn't really belong or required extensive refactoring, it had the courage to rip it out and start over. As shown in Figure 2-1, the architecture is volatile until the architecture baseline is complete. During the period of time that the architecture baseline is worked out, major design decisions will change. During this period, the overall design is proven. When the architectural baseline is complete, the architecture for the system should settle down so that full development can be done based on the stable baseline. If the architecture is volatile throughout the development process, the project will likely fail. Figure 2-1. Software architecture volatility throughout a software development project.Representing and Communicating the ArchitectureThe architects at Canaxia knew for the architecture to be effective, it needed to be effectively communicated to all the stakeholders of the system. After all, architecture really has no other purpose than to provide a concept for the system about to be built. The architecture needed to be clear, concise, and understandable so that the important concepts within the architecture could be implemented and supported by the stakeholders. The architects understood that it was these important concepts that in many ways determined the success or failure of the project at every stage of its lifecycle. To effectively communicate the architecture to the various stakeholders, the team created targeted material for each stakeholder community. For example, the user community was very interested in the usability of the system and how the architecture would support their needs. Therefore, the architects provided a storyboard and a prototype to describe that. This was a very effective means of conveying those aspects of the architecture to this community. The support organization wanted to know how to maintain the system, so a discussion of the software design using UML and data models was an appropriate means of conveying this information to them. Analyzing and Evaluating the ArchitectureThroughout the development of the system, Canaxia was careful to continuously evaluate the architecture to make sure that it met the needs of the project. It knew that the architecture really isn't finished until the project is delivered, and perhaps not even until the system is retired. It used an iterative process of evaluating and evolving the architecture to improve it as necessary throughout the system life cycle. The architecture evaluation process in the initial phases of a project was done through scenario-based techniques. To evaluate software architecture, Canaxia identified the architecturally significant scenarios for the architecture to support. Some methodologies, such as XP, call these scenarios user stories. These scenarios provided a context from which the quality attributes of the architecture could be estimated. As the project developed, the estimates became measurements and test cases for verifying that the desired quality attributes were actually supported by the software that was being created. For example, when the architecture was created, the team estimated the level of performance that the architecture should support based on the number of computations and network hops. Once the architecture baseline was completed, the estimates became measurements of performance for the set of scenarios that were implemented. If the performance requirement was not met or exceeded, the architecture was redesigned to support the requirement. At each stage of the development process, the architecture was evaluated. At later stages in the project, some estimates were very precise because they were based on real working code. However, some of the quality attributes were difficult to measure and were somewhat subjective. For example, it was easy to use a stopwatch to measure the performance of a transaction through the system, however estimating the maintainability of the system was much more difficult. The maintainability estimation was based on many criteria that included the technology that was used, whether or not the system was sufficiently modular, and how much configuration data were used to configure the system at run-time, as well as many other criteria particular to the system that was built. Estimating this even after the system was built was difficult and still somewhat subjective. Canaxia had to rely on the architecture team's skill and experience within the organization and with software designs to deliver the right level of maintainability for the project. Canaxia considered three popular methodologies for evaluating software architectures (Clements, Kazman, and Klein 2002):
Canaxia understood that for critical projects that require a large amount of rigor during the development process, formal methods help to formally evaluate the software architecture of a system. The ATAM and SAAM methods for evaluating software architectures are comprehensive, while the ARID method is meant for intermediate design reviews to ensure that the architecture is on track throughout the project. Canaxia purchased the book Evaluating Software Architecture (Clements, Kazman, and Klein 2002) to learn about each method in depth. In the end, Canaxia created its own ad hoc method to evaluate the software architecture that was partially based on the three methods presented in the book. Ensuring ConformanceThe architecture team realized that even with the best architecture, development teams don't always implement an architecture correctly. Usually, this is the fault of a poor architecture or poor communication of the architecture to developers. In order for the architecture to matter, the architecture in concept must become executing code in a system. At Canaxia, the architecture was implemented correctly in the final system. All the desired system qualities were met and the system was delivered on time and under budget. In addition, the architects and developers realized that the architecture is an ongoing effort in refinement, even after the project is completed. The architects understood they needed to be involved not only during design and construction but also during maintenance of the system. |