Integrating Architecture Methods: The Case of Extreme Programming
ROBERT L. NORD, JAMES E. TOMAYKO

In a previous column (“Rethinking the Software Life Cycle”), we examined the traditional software development life cycle in the context of the architecture-centric methods that we have developed at the Carnegie Mellon Software Engineering Institute (SEI) over the past 10 years.  These methods include the Architecture Tradeoff Analysis Method (ATAM) [Clements 02], the SEI Quality Attribute Workshop (QAW) [Barbacci 03], the SEI Attribute-Driven Design (ADD) Method [Bass 03], the SEI Cost Benefit Analysis Method (CBAM) [Bass 03], and SEI Active Reviews for Intermediate Design (ARID) [Clements 02]. In a subsequent column (Integrating Architecture Methods: The Case of the Rational Unified Process), we saw how these architecture-centric methods fit into the framework of plan-driven approaches as exemplified by the Rational Unified Process (RUP) [Kazman 04]. This column shows how these architecture-centric methods can be incorporated into agile approaches as exemplified by Extreme Programming (XP).

XP practices are based on four values: (1) communication, (2) simplicity, (3) feedback, and (4) courage:

1. Communication emphasizes person-to-person talking, rather than documents that explain the software. Several XP practices call for an on-site customer, so a lot of time is spent communicating with that customer.
2. Simplicity is an XP value that calls for the solution of the customer’s problem to be unpretentious. Both developers and customers easily understand the software solution.
3. Feedback means that everything done is evaluated with respect to how well it works. How well it works is indicated through the feedback gained from exercising every working part of the solution.
4. Courage means that developers are prepared to make important decisions that support XP practices while building and releasing something of value to the customer in each iteration.  This could mean discarding code or taking the time to refactor the design when it turns out that previous decisions are inadequate.

In XP, the customer and the developers together determine the functionality that will be developed in a series of iterations. The first iteration influences the overall structure of the system. “The first iteration puts the architecture in place. Pick stories for the first iteration that will force you to create ‘the whole system,’ even if it is in skeletal form” [Beck 04]. Modifiability is implied by XP, but it is difficult to characterize. Developers develop the system incrementally, and when the system does not support new functionality, they refactor the design.

SEI architecture-centric methods can provide explicit and detailed guidance on eliciting the architectural requirements (such as modifiability), on designing the architecture, and on analyzing the resulting design.

In situations where requirements are changing rapidly and a lightweight approach is warranted, the concepts of quality attributes and architectural tactics can enhance the process of designing a system that will meet its requirements. Students participating in studio projects in the Master of Software Engineering Program at Carnegie Mellon University have been using the Architecture-Centric Development Method—that uses concepts from the QAW, the ADD method, and the ATAM—in this way.

When developing complex, large-scale applications, XP should be adapted to include more kinds of architectural information. Boehm and Turner demonstrate a solution for adapting XP to develop complex, large-scale applications by introducing elements of plan-driven methods [Boehm 04]. These elements include high-level architectural plans to provide essential big-picture information and use of design patterns and architectural solutions, rather than simple design, to handle foreseeable change.

The architecture developed by the ADD helps localize the effects of design changes caused by changing functional requirements, since the architecture is influenced by the quality attribute requirements and is not affected by changing functional requirements. Including architecture in this way might also delay refactoring. However, investing in the architecture means that it will take longer to get to code, because the first iteration is what some people call a “zero-feature release.” In such a release, the architecture is put in place, but no user-visible features are delivered to the customer. 

The benefit of including the SEI methods is to address quality attributes in an explicit, methodical, engineering-principled way. In summary

• The architecture-centric methods place an emphasis on quality attributes rather than functionality. They also help facilitate communication.
• The architecture-centric methods help fill gaps in the XP design process, by providing specific advice on
• the elicitation and documentation of quality attribute requirements
• which design operation will achieve a desired quality attribute response
• how to analyze the result to understand and predict the consequences of the design decisions in terms of risks, tradeoffs, and ultimately return on investment (ROI)
• The architecture-centric methods all use common concepts: quality attributes, architectural tactics, and a “Views and Beyond” approach to documentation that leads to more efficient and synergistic use [Clements 03].

References

[Barbacci 03]	Barbacci, M. R.; Ellison, R.; Lattanze, A. J.; Stafford, J. A.; Weinstock, C. B.; & Wood, W. G. Quality Attribute Workshops (QAWs), Third Edition (CMU/SEI-2003-TR-016). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2003.
[Bass 03]	Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice, 2nd edition. Boston, MA: Addison-Wesley, 2003.
[Beck 04]	Beck, K. Extreme Programming Explained: Embrace Change, Second Edition. Boston, MA: Addison-Wesley, 2004.
[Boehm 04]	Boehm, B. & Turner, R. Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley, 2004.
[Clements 02]	Clements, P.; Kazman, R.; & Klein, M. Evaluating Software Architectures: Methods and Case Studies. Boston, MA: Addison-Wesley, 2002.
[Clements 03]	Clements, P.; Bachmann, F.; Bass, L.; Garlan, D.; Ivers, J.; Little, R.; Nord, R.; & Stafford, J. Documenting Software Architectures: Views and Beyond. Boston, MA: Addison-Wesley, 2003.
[Kazman 04]	Kazman, R.; Kruchten, P.; Nord, R.L.; Tomayko, J.E. Integrating Software Architecture-Centric Methods into the Rational Unified Process (CMU/SEI-2004-TR-011), 2004.
[Nord 04]	Nord, R. L.; Tomayko, J. E.; Wojcik, R. Integrating Software-Architecture-Centric Methods into Extreme Programming (XP) (CMU/SEI-2004-TN-036), 2004.

About the Authors

Robert L. Nord is a senior member of the technical staff in the Product Line Systems Program at the Software Engineering Institute (SEI) where he works to develop and communicate effective methods and practices for software architecture. Prior to joining the SEI, he was a member of the software architecture program at Siemens, where he balanced research in software architecture with work in designing and evaluating large-scale systems. He earned a Ph.D. in Computer Science from Carnegie Mellon University. Dr. Nord lectures on architecture-centric approaches. He is co-author of Applied Software Architecture and Documenting Software Architectures: Views and Beyond.

James E. Tomayko Dr. James E. Tomayko is a teaching professor at the School of Computer Science at Carnegie Mellon and a part-time senior member of the technical staff of the Software Engineering Institute (SEI). He is the director emeritus of the Master Software Engineering Program in SCS.

Previously he was leader of the Academic Education Project at SEI. Prior to that, he founded the software engineering graduate program at the Wichita State University. He has worked in industry through employee, contract or consulting relationships with NCR, NASA, Boeing Defense and Space Group, CarnegieWorks, Xerox, the Westinghouse Energy Center, Keithley Instruments and Mycro-Tek. He has given seminars and lectures on software fault tolerance, software development management, fly-by-wire, and software process improvement in the United States, Canada, Mexico, Argentina, Spain, Great Britain, South Africa, Germany, China, and Columbia. Tomayko's courses on managing software development and overviews of software engineering are among the most widely distributed courses in the SEI Academic Series.

Tomayko has had a parallel career in the history of technology, specializing in the history of computing in aerospace, and has written five books and several articles on spacecraft computer systems and software, concentrating primarily on NASA's systems. Dr. Tomayko is on the editorial staff of the IEEE Annals of the History of Computing.

The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.