NEWS AT SEI
This library item is related to the following area(s) of work:Software Architecture
This article was originally published in News at SEI on: March 1, 2007
Robert L. Nord and Paul C. Clements, with help from members of the International Federation for Information Processing (IFIP) Working Group 2.10 on Software Architecture and the Working IEEE/IFIP Conference on Software Architecture (WICSA) 2007 working session on this topic.
The study of software architecture involves the understanding of the large-scale structures of software systems. As a field of study, software architecture is a specialization of software engineering and overlaps and interacts with the study of software families, domain-specific design, component-based reuse, software design, specific classes of components, and program analysis [Shaw 2006]. Beyond the related areas in software engineering, software architecture also interacts with activities in system architecture, information architecture, and enterprise architecture.
Since the mid 1980s, when the field began, (although its roots can be traced to earlier concepts), software architecture has largely been concerned with engineering and understanding the interaction of well-defined components over well-defined communication paths via well-defined interfaces. However, a much different world is emerging. Systems are built from components designed and produced by organizations independently of each other. The components may or may not have well-defined interfaces. The functionality and quality attributes of the total system may be derived from (rather than engineered into) the federation of components. The components and their interrelationships may change dynamically, arriving and departing either bidden or unbidden, and connecting to the part of the system where they will do the most good. “Time to market” will be replaced by “time to useful functionality” and will be measured in seconds rather than months.
What will be the role of architecture in that new world? And what will the role of the architect be? How can the study of a system’s software structures have meaning if those structures are not known before execution and can change by the minute? It seems clear that the current architectural paradigm—focusing on the components and connections that make up a large-scale software system—will not suffice and will have to be replaced with something different. Nevertheless, it also seems clear that highly dynamic systems must be based on architectural principles that facilitate or guarantee system properties, thus preserving the need for software architectural thinking.
Members of the International Federation for Information Processing (IFIP) Working Group 2.10 on Software Architecture recently held a discussion on this topic and then continued the discussion during a working session at the Sixth Working IEEE/IFIP Conference on Software Architecture (WICSA 2007).
IFIP is a non-governmental, non-profit umbrella organization for national societies working in the field of information processing. It was established in 1960 under the auspices of UNESCO as a result of the first World Computer Congress held in Paris in 1959. IFIP maintains several dozen working groups that strive to advance the state of and foster international cooperation in their respective areas.
The purpose of IFIP Working Group 2.10 is to further the practice of software architecture by integrating software architecture research and practice. The group sponsors the Software Architecture Portal, which provides information about IFIP WG 2.10, the WICSA conference series, the Software Architecture Village Wiki, and other resources on software architecture.
Members of the group are Maarten Boasson, Jan Bosch, Paul C. Clements, Morven W. Gentleman, Rich Hilliard, Christine Hofmeister, Philippe Kruchten, Tomi Männistö, Robert L. Nord, Henk Obbink, Alexander Ran, Mary M. Shaw, Judith A. Stafford, Hans van Vliet, and Eoin Woods.The working session had two goals:
The working session was devoted to trying to lay out the space of the practice of software architecture. The purpose was to define two points: a point where the field is now in that space and a point in the same space where the field might be in x years. The group held a brainstorming session in which participants suggested a dimension of the space and what it means to be at the most primitive and most advanced points along that dimension (which we arbitrarily labeled 0 and 10, respectively).
The working session’s 22 participants created these 12 dimensions of the space of architecture:
Later, the group postulated the state of the practice in each of the dimensions and what it would take to move it to level 10. Time limits allowed the completion of only the first three areas. These details are available at the conference Wiki. Readers of this column are encouraged to contact the authors or to log on to the conference Wiki to either provide feedback on the proposed dimensions or propose additional ones.
Working IEEE/IFIP Conference on Software Architecture (WICSA)
The mission of the WICSA conference series is to be the premier means of communication and advancement of research and practice in software architecture, from both academia and industry, worldwide. Working sessions have an important role at WICSA in fostering this dialog. An online record of the discussion from the previous three conferences is captured in the conference Wiki.
Plans are underway for WICSA 2008, to be held in Vancouver, Canada, February 18-21, 2008.
Robert Nord is a senior member of the technical staff in the Product Line Systems Program at the 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 PhD in computer science from Carnegie Mellon University. Nord lectures on architecture-centric approaches. He is co-author of Applied Software Architecture (1999) and Documenting Software Architectures: Views and Beyond (2002).
Paul Clements is a senior member of the technical staff at Carnegie Mellon University's Software Engineering Institute, where he has worked for 8 years leading or co-leading projects in software product line engineering and software architecture documentation and analysis. Clements is the co-author of three practitioner-oriented books about software architecture: Software Architecture in Practice (1998, second edition due in late 2002), Evaluating Software Architectures: Methods and Case Studies (2001), and Documenting Software Architectures: View and Beyond (2002). He also co-wrote Software Product Lines: Practices and Patterns (2001), and was co-author and editor of Constructing Superior Software (1999). In addition, Clements has also authored dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems. He received a B.S. in mathematical sciences in 1977 and an M.S. in computer science in 1980, both from the University of North Carolina at Chapel Hill. He received a Ph.D. in computer sciences from the University of Texas at Austin in 1994.
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.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.