Introduction

The term architectural relevance refers to a system aspect, either functional or nonfunctional, that is central to determining the fundamental structure of that system. One of the core best practices for software development is to focus on the highest areas of system risk early in the development project. Typically, an architecturally relevant use case requires one or more of these high-risk areas. For example, if the system is intended to perform video on demand (VOD) delivery, an architecturally relevant aspect would be the translation of the video signal to the correct target device. This step would necessarily include the ability to retrieve video content, transform the signal as necessary for display, and select the correct translation device to assign a specific delivery channel. By choosing to develop this functional area first, rather than a lower-risk area, you can address a large set of technical risks early in the project. The difficulty is in finding all the system aspects, assigning them to the architecturally relevant category, and ranking them appropriately.

Ranking system aspects can often lead to identifying nearly all of the functionality as architecturally significant; every part of the system is seen as required and important. Following iterative development practices, however, forces the selection of only 10 to 20 percent of the features for scheduled delivery at the end of each iteration. How then shall the development team choose among all of the desired system functionality? The growing consensus among software architects is that the best way to achieve this ranking is by associating system use cases with specific architectural mechanisms required to realize the detailed functionality.

Back to top

Defining architectural mechanisms

An architectural mechanism can be defined as a recurring service utilized by many, if not most, parts of the software system. Architectural mechanisms represent the core operational services that the system architecture is expected to provide to the business processing logic. Table 1 summarizes the primary mechanisms found in many software systems. As you can see, an architectural mechanism is identified as a general category of system behavior rather than a specific business function. For example, in a billing application, billing or ordering would not be mechanisms, but transaction management (and perhaps workflow) would be used to implement those core business functions.

However, simply listing a mechanism as architecturally relevant is not helpful to the architect trying to determine which functionality uses these mechanisms. To assign mechanisms to use cases or other requirements, it is helpful to identify the core characteristics of each mechanism. If a particular feature uses these characteristics, it is likely that the associated mechanism is needed. Continuing the billing example, some of the characteristics of a use case called "Manage Customer Billing" might involve operation history (auditing), recovery and tracing (error handling), ACID properties (transaction management), and intersystem synchronization (communications). Table 2 shows the common characteristics for each architectural mechanism identified in Table 1.

Back to top

Ranking use cases

Architectural mechanisms are important because they tend to affect the system as a whole by cutting across component boundaries. A familiar example is data persistence. Virtually all applications are required to store some form of data, even if it is little more than user preferences. Data can be stored many ways, each with different degrees of difficulty, such as in a database or through file system access. Moreover, many mechanisms may be implemented with frameworks, where the core elements of the mechanism are provided by either a commercial or open source product. In these cases, the architect and project manager will need to consider the consequences of tight coupling to a nonlocal source, with all of the consequences inherent in that decision.

Mechanisms often interact with and enhance or limit one another. For example, the auditing/logging mechanism is constrained by the persistence, security, and transaction mechanisms. This constraint is due to the nature of auditing, where the audit trail requires storage to a nonvolatile source (such as a database or log file), limitations to access, and the assurance of integrity of the recorded operation.

Note, however, that architectural mechanisms are not the same as architectural drivers. A driver represents an overall system goal, such as performance or scalability, whereas mechanisms are techniques to achieve these goals. Likewise, an architectural constraint may affect several mechanisms and limit the possible solutions. An example would be the difference between identifying a communication mechanism and a system requirement for using a particular communication protocol. Therefore, when identifying potential mechanisms for association with a selected element of system functionality, be careful to separate the driving forces from the implementation techniques.

Architectural mechanisms are always involved in any substantial software development project, but it is not always clear which use cases use which mechanisms. Use Table 2 as a guide to look for the characteristics of each mechanism during a use-case review or walkthrough. For example, consider the video delivery system. Here are some of the proposed use cases:

• Manage customer order
• Prepare billing statement
• Translate video signal
• Download video content
• Transmit video signal

Assuming that the use-case writer has created a summary for each use case (or better yet, detailed most of them), it is possible to discover likely mechanisms. Often a simple description is enough to suggest mechanisms of interest, but occasionally it is necessary to identify the basic and alternate use-case flows before you can make a final determination. Table 3 shows the summary analysis for the "transmit video signal" use case of the video delivery system. Clearly, this feature set has a large number of associated mechanisms and is a likely candidate for early development.

Identifying and associating architectural mechanisms with specific use cases makes it possible to determine the functionality most likely to exercise large parts of the system architecture. The more mechanisms associated with a use case, the larger the impact on the final design. To establish an initial ranking, simply count the number of mechanisms expected for each use case. You can then order each use case from highest to lowest, with the higher ranked use cases slated for early iteration development.

Applying a weight scale

It is important to note, however, that not all implementations are equal. Mechanisms for security may be quite complex for a distributed architecture and much simpler for basic intranet access. The database manufacturer may provide the mechanism for access to a database, or you may need to interface to a legacy system by writing a custom driver component. To account for these differences, you should consider each identified mechanism for likely complexity of implementation. This requires you to make a judgment call based on the business and technical context of the final system. Consider using the weighting scheme outlined in Table 4: basic (1), intermediate (2), and advanced (3). This scale allows you to apply a weighting factor to each mechanism based on the difficulty for implementation.

Based on Table 3, the most architecturally relevant use case is #2 with 8 points, followed by #1 with 6 points, and finally, #3 with 4 points. Even though use case #1 has the same number of mechanisms, #2 has more complex implementation, so you should assign this use case to an early development iteration.

In legacy systems, use this technique to identify which of the requested functional changes will cause the highest impact (and therefore greatest risk) to the existing system. Here the challenge is to identify whether the functional request is affecting the architecturally relevant use cases, and if so, which of the mechanisms are likely to be modified. You can perform a similar analysis to rate and rank each requested change.

Once you've identified the key use cases, you can use this information to organize the development effort, particularly in the architecture definition phase. During this phase, the goals are to reduce risk and establish a candidate software architecture. Again, the more mechanisms in use, the higher the associated technical risk, so by focusing the early iterations on the most architecturally relevant use-case scenarios, you can accomplish both these goals. As an additional benefit to this approach, most, if not all, key technical mechanisms are discovered early in the project, allowing sufficient time for the architect and project manager to fully consider the consequences of design choices.

Back to top

Summary

Using architectural mechanisms to evaluate and rank system functionality is a powerful way to organize a project, but it is only one part of determining the order of functional delivery. The priority of a particular functional aspect may trump the architectural significance, especially if early delivery of that feature is needed to ensure continued project funding -- the retirement of an entirely different sort of risk. When changes are made to legacy systems, an architect is often asked to perform an "impact analysis" to determine if the changes are reasonable given the scope and likelihood for breakage of existing functionality. Using this approach, you can rapidly focus attention on the changes that affect architecturally relevant use cases, and consequently, the core architectural mechanisms that are realized in the system code.

For teams accustomed to a waterfall delivery schedule and having challenges adopting to an iterative, architecturally driven approach, the architectural mechanism ranking technique provides a path to discover the truly critical system functionality. Directing early effort toward these high-risk, high-reward use cases will benefit the overall project success and the long-term maintainability of the software system.

Resources

Learn

• Check out Appendix A: Analysis Mechanisms of "Capturing Architectural Requirements," by Peter Eeles (developerWorks, November 2005).
  
  
• Read "Architecture Mechanisms," by Len Bass, Mark Klein, and Rick Kazman (The Architect, news@sei, March 2001).
  
  
• Check out "Supporting Usability through Software Architecture," by Len Bass and Bonnie E. John (ERCIM News, July 2001).
  
  
• Read chapter 1 of "Software Architecture: Central Concerns, Key Decisions," by Ruth Malan and Dana Bredemeyer.
  
  
• Take a look at "Using Dependency Models to Manage Complex Software Architecture," by Neeraj Sangal, Ev Jordan, Vineet Sinha, and Daniel Jackson.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Discuss

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Benjamin A. Lieberman serves as principal architect for BioLogic Software Consulting, providing expertise consulting and training on a wide variety of software development topics, including requirements analysis, software analysis and design, configuration management, and development process improvement. Dr. Lieberman specializes in object-oriented architectures and distributed computing. You can reach him at blieberman@BioLogicSoftwareConsulting.com.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Defining architectural mechanisms
• Ranking use cases
• Summary
• Resources
• About the author
• Comments