Creating a Software Architecture: An Example

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:

1. The architecture should be thin.

2. The architecture should be approachable.

3. The architecture should be readable.

4. The architecture should be understandable.

5. The architecture should be credible.

6. The architecture doesn't have to be perfect.

7. Don't do big upfront design. If given a choice between making the model perfect or implementing it, implement it.

8. Do the simplest thing that could possibly work without precluding future requirements.

9. The architecture is a shared asset.

10. Involve all stakeholders but maintain control.

11. The architecture team should be small.

12. Remember the difference between a pig and a chicken.

The Pig and the Chicken

One day on a farm near Canaxia, a pig and a chicken decided to open a restaurant.

The pig turned to the chicken and asked him, "So what should we call this restaurant?"

The chicken replied, "How about Ham 'n' Eggs?"

The pig thought for a moment and said, "I don't think that's a very good idea. You would be involved, but I would be committed."

The Scrum (Schwaber et al. 2001) development methodology uses this story as the central theme for distinguishing between those people who are pigs (assigned work) and those who are chickens (interested, but not working).

When creating software architecture, chickens can wreck the process in two ways. If chickens are on the architecture team, you should just give up and open a restaurant. Assuming that the architecture team consists of all pigs, make sure that the architecture addresses the concerns of the pigs in the organization. Don't let the chickens sneak in an egg or two and make you design for something that isn't really important.

The following sections describe the steps that the architects at Canaxia performed to create their architecture (Bass, Clements, and Kazman 1997).

The Business Case

Canaxia 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 Requirements

Canaxia 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 Architecture

The 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 Cases

Select 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 Qualities

Software 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 Architecture

Canaxia 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 Environment

Canaxia then set up a development environment that included:

• Servers and space on servers such as file servers, application servers, and database servers

• Modeling and drawing tools

• Whiteboards

• Digital camera for taking pictures of whiteboards

• Project Web site and file subfolder

• Software with which they needed to integrate

• Integrated development environment (IDE)

• Unit testing framework (XUnit)

• Version control software

• Automated build process

Implement the Design

Canaxia 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 Design

The 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):

1. The architecture is forced to match the current organization. Sometimes a good architecture is changed because someone says, "We just don't do that here." Architecture can be polluted because the practices and technical infrastructure of the organization don't mesh with the architecture for the project. Many times, compromises in the architecture are necessary to ensure enterprise consistency, but the conceptual integrity of the architecture should be maintained as much as possible.

2. There are too many top-level architectural components (too much complexity). If the number of components reaches a level (usually more than 25), the architecture becomes too complex for it to have conceptual integrity. The roles and responsibilities of each component must be clear. When the system consists of too many components, the responsibilities of the component tend to blend into each other.

3. One requirement drives the rest of the design. Some projects are built with a single overriding goal in mind that is sometimes the pet requirement of the project sponsor, project manager, or project architect. When the system is built around a single overriding requirement, other requirements may not be addressed.

4. The architecture depends on the alternatives presented by the operating platform. Sometimes the platform chosen is the wrong one for the project. For example, a project that requires a high level of usability might not be possible if the platform chosen for the user display is a 3270 terminal.

5. Proprietary components are used instead of equally good standard ones. Architects and developers are often lured by the latest cool technology or interesting designs that may have alternative standard technology available. For example, projects should take advantage of the capabilities of application server technology. When developers begin creating load balancing schemes or persistence frameworks, it is usually an indication that there is a problem. It would be better to use the standard capabilities of an application server and spend time developing software to solve the business problem rather than creating new technical features.

6. The component division definition comes from the hardware division. The components should be designed without regard for the physical topology of the system, except to recognize that a network is involved in transmitting data between components. The components should map to a discrete business or technical function of the application that is being built. These components should take advantage of the scalability features of modern computing systems.

7. The design is exception driven; the emphasis is on the extensibility of the system rather than on the core requirements for the system. By "exception driven," we do not mean exception handling but rather that the system should not be designed exclusively with the requirements that someday might be necessary in mind. It should be designed to solve the more immediate requirements.

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 Architecture

The 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 Architecture

Throughout 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):

1. Architecture Trade-off Analysis Method (ATAM)

2. Software Architecture Analysis Method (SAAM)

3. Active Reviews for Intermediate Designs (ARID)

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 Conformance

The 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.