columns
the architect
Software Architecture: The Next Generation
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 Working Group 2.10 on Software Architecture 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:
- to lay out certain dimensions of the problem space that we assume now but that may vanish in the next 10 years
- to define a broad description of the practice of software architecture and the role of the architect in the most demanding part of that new problem space
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:
- codification and socialization—processes by which an architect communicates architectural ideas to stakeholders. Codification refers to specification of the architecture, while socialization refers to the less formal processes by which the architecture is internalized. Socialization can happen through conversation, training, and so forth. Codification and socialization are complementary processes; they should enforce each other.
- 0—Codification and socialization do not occur.
- 10— Codification and socialization are in balance with each other; socialization becomes a process for codification; socialization and codification enforce each other and work in a global environment.
- handling quality attributes
- 0—There is no consensus on quality attributes.
- 10—Quality attributes are linked to business and engineering needs and are quantitatively specified.
- architectural automation
- 0—There is no support for architectural automation; description consists of human language on paper.
- 10—Language for architecture is the base language for automation.
- architectural specificity
- 0—Reasoning is limited to specific elements (hardware, network, software, etc.) and the relationships known by the architect.
- 10—Architects employ reasoning about guidelines, constraints, quality attributes—self-adaptive systems.
- architectural responsibility—degree to which an architect is responsible
- 0—There is no explicit recognition of responsibility. The worst case is having responsibility and no authority.
- 10—A clear definition of responsibility and authority exists for the architect’s role. Responsibility is sufficient to deliver the function and quality attributes of the system to its stakeholders over time.
- accidental versus intentional architects
- 0—Architects have no explicit training, no career path, no formal explicit recognition, no experience threshold (relating problems to domain, development, implementation, failed, organization, etc.).
- 10—Architects are chosen intentionally for their ability.
- domain versatility and adaptability
- 0—The architect has a one-track mind.
- 10—The architect is pragmatic and inquiring—able to organize information.
- architecting process—maturity of architectural choices
- 0—Diverse solutions and techniques exist, but the choice is arbitrary.
- 10—There is a clear linkage between architecture goals and the choice of process and techniques.
- technology dependency—Technology is a tool.
- 0—Architecture is constrained by the existing technology.
- 10—Architecture is fearless, specifying the abstract solution without necessarily any bindings to existing technology. Architecture is not constrained by existing technology. A fearless architecture is one that might influence future technology.
- creating versus choosing an architecture
- 0—No previous solutions are reused.
- 10—The solution already exists (not accounting for the details)—looking at previous solutions and reusing them.
- complexity
- 0—Complexity is low.
- 10—Architecture is produced for complicated and complex systems with emergent behavior.
- interdisciplinary architecture
- 0—A single discipline is fully understood (e.g., information architecture, enterprise architecture).
- 10—Multiple disciplines are fully integrated. Stakeholders’ perspectives are met.
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. To comment on the discussion for the working session described in this article, visit http://wwwp.dnsalias.org/w/index.php Plans are underway for WICSA 2008, to be held in Vancouver, Canada, February 18-21, 2008. |
Reference
[Shaw 2006]
Shaw, M. & Clements, P. “The Golden Age of Software Architecture.” IEEE Software 23, 2 (March/April 2006): 31-39.
About the Authors
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.