Architecture Activities

Architecture activities, like many other activities in the process, happen through all the phases of development. The key architecture activities are to

• Examine and prioritize use cases and look for significant architectural requirements
• Define and document a candidate architecture and prepare and evaluate prototypes
• Define a reuse strategy

Other activities of the architecture team include providing input to the project management team, participating in artifact reviews, and creating development standards documents. But identifying the SARs, developing the architecture, and being the number-one champion for reuse are principal activities.

Examining and Prioritizing Use Cases

One of the activities of the architecture team is to examine the use case model from a technical viewpoint. The use case model, as a view of the desired system's dynamic behavior, is prioritized according to perceived risk. The process is to address early the use cases that have greater risk and thus prevent unwanted "gotchas" later. A risky use case might involve a new technology or require a high degree of performance. For example, in an Internet-based commerce application, the use case writers might describe the collection of customer information as follows.[4]

[4] This style of use case description is somewhat low level, describing the details of the user interface. Other use case styles might simply state that the user enters an address and that the system provides city and state or province information when a postal code is entered.

The system prompts the customer for name and address information. The customer enters his/her first and last names, then tabs to the address section of the screen. The customer enters a street address. The customer may enter a city and state or go directly to the zip code field and enter a five-digit zip code. When the customer enters a zip code, the system automatically fills in the city and state fields, if not already filled in.

When the address is completed, the customer clicks the Next button to move to the next step in the order process.

Aside from the obvious implications that this Internet application is limited to U.S. addresses, this use case fragment describes some particularly risky dynamic behavior. Reviewing the use case means partitioning the behaviors into one of the system's tiersclient, server, or other. This is an Internet commerce application, so we can make the assumption that no special software is loaded on the client and that, for the most part, the activities described in this use case are happening in an HTML form on the client. The use case specifies that the customer can enter a zip code and have the system identify the correct city and state. If this is all happening on the client, it implies that the mapping of zip codes to cities and states must reside there as well. This is a problem because this mapping is continually changing and is huge: about 100,000 records! This amount of information would take minutes just to get to the client over normal Internet connections.

Because the use of client-side scripts is not a possible solution, the determined architect might consider the use of a Java applet or an ActiveX control that could asynchronously communicate with a server to get the city and state for a zip code and then update the HTML form fields. A small server process would manage the zip code information and provide the simple service of mapping zip codes to cities and states. But even this solution presents a certain amount of risk, because a new technology is being incorporated. Additionally, if the requirements state that this application should work on a large range of browsers, some of which might not have ActiveX or Java capabilities, it is not a possible solution. In this situation, the architect should reaffirm the priority of this featureit's most likely that this is not a critical requirementand a small rewrite to the use case is perhaps the least risky solution.

In other situations, the experienced architect might detect risk in the use case yet be constrained to keep and to overcome it in the application. For example, an account management application might allow users to open and to view several accounts simultaneously in different browser windows. Depending on the details of the architecture or proposed architecture, this may cause difficulties in the management of the client state by the server.

Web application development environments, such as Microsoft's Active Server Pages, use cookies to help manage client state. Cookies are key/value pairs that are placed in a browser when it first contacts the Web server. Cookies can persist beyond the single servicing of a browser's page request and offer a convenient mechanism to tackle the client state problem. The cookie usually contains a value that can be used as an index into a dictionary of objects and values: the client state. The architectural risk is that in some instances a new browser window inherits the originating window's cookie. This creates an instance in which two simultaneously open browser windows are sharing the client state on the server.

The disaster scenario might take the form of an account manager's opening a customer's profile, ready to make a slight change to it. The manager remembers that another customer has similar values and proceeds to open another browser window. This second window inherits the first's cookie and hence client state. As far as the server is concerned, the singular browser instance just switched to a new customer profile. The manager views the second customer's information and then switches to the first browser window, makes some changes, and submits them to the server. If the client state contained the primary key to the customer, the server might update the second customer's record with the first customer's data.

These specific scenarios don't represent limitations on the technologies, there are ways around the problems of both. At this stage of the process, it is simply important to recognize that the seemingly innocent use cases as applied to certain architectures may represent a risky aspect of the application. This being the case, they need to be addressed earlier rather than later.

Developing Candidate Architectures

In every successful project that I've worked on, the system's architecture was almost always a refinement of an earlier successful one that the chief architect had used or worked with. This is the unspoken secret of the industry: New projects don't always develop new architectures. Radical changes in software architecture are rare; in my experience, architects advocating new, untested ones are typically inexperienced or have a history of failure.

Even when the Internet popped up on corporate radar screens and Web-centric architectures started to become popular, they were almost always refinements of earlier, smaller-scale architectures. Web application architectures are specializations of the generic client/server architecture. The first-generation Web applications were also very simple. They either performed very little business logic or delegated that logic to an otherwise standard client/server middle tier. As architects became more familiar with the architectural issues specific to Web applications and as vendors started supplying more stable and sophisticated middleware, the scope and the criticality of Web applications expanded. Today nearly every major organization that depends on software technology depends in part on Web-centric systems.

Developing a candidate architecture begins with an understanding of the significant architectural requirements of the system. Ideally, the collection of these requirements alone should be enough to dictate a candidate architecture. But the reality of software development is that the makeup of the organization, its experiences, and skill sets are equally important. If, for example, the team has experience building only Visual Basic (VB) and COM-based two-tiered applications, adopting a Java appletcentric architecture would not be a good fit. Sending team members to a two-week intense Java course will not make them Java experts. In all likelihood, without proper mentoring, any resulting effort will end up with a system designed for Visual Basic and implemented with Java.

I had a very difficult time transitioning to Visual Basic from C++.[5] Without a mentor to guide me, I kept trying to design and to code my modules as I would with C++. I grew increasingly frustrated at VB's inability to provide true object-oriented inheritance. I relished Visual Basic's environment for building user interfaces and vowed never to build a UI (user interface) with Microsoft Foundation Classes (MFC) again.[6] With proper mentorship, I'm sure I would have realized the relative merits of true inheritance and inheritance via implementing interfaces, as well as other important VB concepts, much sooner.

[5] Yes, I transitioned from Visual C++ and MFC to Visual Basic voluntarily. I believe that programming languages are not nearly as significant to the success of a project as the proper understanding of how to leverage the architectures and conventions to which they lend themselves.

[6] That lasted about six months.

The architect needs to consider the development team when defining a candidate architecture. Introducing new architectures and technologies to a team can and does happen successfully. But this success depends on a combination of proper training, mentorship, and the target project. If it is desired to move a team's expertise from building Power Builder client/server systems to J2EE-based Web applications, the best approach is to pick a pilot project first. Create a success that the team can leverage and be proud of. Then, with the experiences learned from the pilot, tackle the larger and more important projects, using the pilot project team members in mentorship roles with the new project.

With the significant architectural requirements identified and prioritized and with an understanding of the skills and personalities of the development team, the team can explore candidate architectures. The architect usually starts with a well-known architecture that has worked well and determines whether it is good fit to meet the SARs. Key areas to examine are scalability and maintainability. The realities of Internet applications give these aspects a high priority. For many organizations, time to market is also critical, and this hinges heavily on the development team's skill set.

During this stage, the candidate architecture is expressed only in scattered sets of documents and in the minds of the architecture team's members. It is a time of discovery and exploration. Candidate architectures are poked and prodded conceptually; experience and research often are the only clues to its potential success. For all the academic importance of this stage, the truth is that it often happens quite quickly. Most of the time, the architect has a pretty clear idea of the candidate architecture, and this stage is mainly due diligence.

This is also the stage in which the beginnings of the software architecture document take shape. Sometimes, it begins with a slide presentation to upper management to obtain funding. All too often, the formal evolution of the architecture stops when funding is achieved. This happens so often that the term architecture by PowerPoint has been coined. I want to make it clear that I am not advocating that a candidate architecture shouldn't be proposed until its full documentation or prototype is completed. Given the fact that most architectures are refinements of earlier ones, proceeding with the development process is in no jeopardy with an incomplete architecture document. What I am saying, however, is that prototyping, investigating, and documenting the architecture need to continue even after funding has been obtained.

Prototyping: Knowing When to Stop

Every architectural prototype is created to answer a specific set of questions. A prototype should never be created until these questions are known. The two basic types of prototypes are experimental and evolutionary. Experimental prototypes are "throw-away" prototypes that are constructed solely to test a specific hypothesis. The questions are stated ahead of time. The prototype is built to answer these questions, and the results guide architectural and design decisions. The scope of the prototype is limited to testing the hypothesis and answering the questions that it was meant to answer.

Evolutionary prototypes, on the other hand, are intended to evolve during the life cycle of the development process. They too answer questions about the system and are intended to influence future design decisions. Because the evolutionary prototype is intended to be more permanent, there tends to be more formal design and rigor in its construction. Although initially not of production quality, the prototype is expected to evolve into something that is ready for production.

I do not favor this type of prototype. When schedules start to slip and management becomes nervous I've seen it happen all too often: the strong pressure to ship incomplete prototypes as the target system. Experimental prototypes, on the other hand, tend to be tightly focused and are not well suited to being transformed into an initial release of a system.

In addition to user interface prototypes, which are driven by the UX team, architectural prototypes are constructed to answer architectural questions. When constructing a prototype, first identify the set of questions it must answer, or propose a hypothesis. For example, architectural prototypes are constructed to

• Test persistence mechanisms
• Measure data throughput
• Prove or validate new middleware technology
• Prove or validate new tools
• Evaluate the level of effort necessary to create a specific artifact
• Test third-party interfaces, or connections to external systems

Only with the scope of the prototype defined is it safe to proceed with its development. If the prototype is experimental, little formal design needs to go into it. If the prototype is evolutionary, it is critical to ensure that proper change management procedures are in place and that good backups of the system are made in the event that the prototype fails and an earlier version of the system needs to be brought back to life.