The Past, Present, and Future for Software Architecture
Total Page：16
File Type：pdf, Size：1020Kb
focusguest editors’ introduction The Past, Present, and Future of Software Architecture Philippe Kruchten, University of British Columbia Henk Obbink, Philips Research Europe Judith Stafford, Tufts University his special issue celebrates 10 years of software architecture con- ferences and workshops and the 10th anniversary of the first IEEE Software special issue on the topic in November 1995. We T aim to address the latest thinking about creating, capturing, and 22 IEEE SOFTWARE Published by the IEEE Computer Society 0740-7459/06/$20.00 © 2006 IEEE using software architecture throughout a soft- ■ Representation: How do we produce ware system’s life. The articles we’ve chosen durable artifacts to communicate architec- cover innovative methods and techniques ture to humans or machines? The concept emerging from research to support software ■ Economics: What architectural issues drive architecture practice. They also emphasize the business decisions? of software methods, techniques, tools, and software engi- architecture neering principles that support organizations And certainly software architecture is tied as a distinct taking an architecture-centric approach to closely to other disciplines and communities, software development. such as software design (in general), software discipline reuse, systems engineering and system architec- started to What is software architecture? ture, enterprise architecture, reverse engineer- Software architecture involves ing, requirements engineering, and quality. emerge in 1990. ■ the structure and organization by which A brief history of software modern system components and subsys- architecture tems interact to form systems, and Looking back in time will help us position ■ the properties of systems that can best be software architecture’s current status and future designed and analyzed at the system level. directions. We also provide pointers to relevant books, papers, conferences, and Web sites. For example, we largely determine end-to-end performance and product-line compatibility Pre-1995 by evaluating software architectures. Software The first reference to the phrase software architecture captures and preserves designers’ architecture occurred in 1969 at a conference intentions about system structure and behav- on software engineering techniques organized ior, thereby providing a defense against design by NATO (see the sidebar “Software Architec- decay as a system ages. It’s the key to achiev- ture in 1969”). Some of our field’s most pres- ing intellectual control over a sophisticated tigious pioneers, including Tony Hoare, Edsger system’s enormous complexity. Dijkstra, Alan Perlis, Per Brinch Hansen, Paradoxically, despite the maturing of the Friedrich Bauer, and Niklaus Wirth, attended discipline, we’re far from having a consensus on this meeting. a satisfying, short, crisp answer to this simple From then until the late 1980s, the word question—no widely accepted definition exists. “architecture” was used mostly in the sense of Paul Clements lists several definitions on the system architecture (meaning a computer sys- Software Engineering Institute’s architecture tem’s physical structure) or sometimes in the practice site (www.sei.cmu.edu/architecture/ narrower sense of a given family of comput- definitions.html). Getting agreement on a def- ers’ instruction set. Key sources about a soft- inition was the most difficult task in creating ware system’s organization came from Fred the IEEE standard.1 Actually, this lack of con- Brooks in 1975,2 Butler Lampson in 1983,3 sensus hasn’t been a substantial impediment to David Parnas from 1972 to 1986,4–7 and John the discipline’s progress, and it regularly pro- Mills in 1985 (whose article looked more into vides a source of entertainment at gatherings the process and pragmatics of architecting).8 of software architects. The concept of software architecture as a dis- The software architecture field has many tinct discipline started to emerge in 1990 (see fig- subareas. The International Federation of In- ure 1). A 1991 article by Winston W. Royce and formation Processing Working Group 2.10 de- Walker Royce, father and son, was the first to fines these five: position software architecture—in both title and perspective—between technology and process.9 ■ Architectural design: How do we produce Eberhardt Rechtin dedicated a few sections to an architecture? software in his 1991 book Systems Architecting: ■ Analysis: How do we answer questions, on Creating and Building Complex Systems.10 That the basis of an architecture, about certain year, one of us (Philippe Kruchten) wrote an ar- qualities of the final product? ticle marrying iterative development with a focus ■ Realization: How do we produce a system on architecture and defined multiple views for based on an architecture description? use on a large command-and-control system.11 March/April 2006 IEEE SOFTWARE 23 Software Architecture in 1969 Rapide, Darwin, Wright, ACME, and Unicon, which unfortunately haven’t yet taken much root in industry. Ian P. Sharp made these comments at the 1969 NATO Conference on 1994 saw the first book on software archi- Software Engineering Techniques. They still resonate well 37 years later. tecture, by former IBMers Bernard Witt, F. 13 I think that we have something in addition to software engineering: some- Terry Baker, and Everett Merrit. thing that we have talked about in small ways but which should be brought out into the open and have attention focused on it. This is the sub- 1995–1998 ject of software architecture. Architecture is different from engineering. In 1995, software architecture really started As an example of what I mean, take a look at OS/360. Parts of OS/360 are to bloom, and events accelerated with numer- extremely well coded. Parts of OS, if you go into it in detail, have used all ous contributions to the field from industry and the techniques and all the ideas which we have agreed are good program- academia. Notable examples were the Software ming practice. The reason that OS is an amorphous lump of program is Architecture Analysis Method (SAAM), the that it had no architect. Its design was delegated to a series of groups of first of a Software Engineering Institute series of engineers, each of whom had to invent their own architecture. And when methods;14 several approaches involving mul- these lumps were nailed together they did not produce a smooth and beau- tiple views such as Rational’s 4+1 views15 or tiful piece of software. Siemens’ four views;16 and specific design pat- I believe that a lot of what we construe as being theory and practice is in terns for software architecture.17 Siemens,18 fact architecture and engineering; you can have theoretical or practical ar- Nokia,19 Philips,20 Nortel, Lockheed Martin, chitects: you can have theoretical or practical engineers. I don’t believe, for IBM, and other large software development or- instance, that the majority of what Dijkstra does is theory—I believe that in time we will probably refer to the “Dijkstra School of Architecture.” ganizations—mainly in systems, aerospace, and telecommunications—started to pay attention What happens is that specifications of software are regarded as functional to software architecture, teaming up with the specifications. We only talk about what it is we want the program to do. It is my belief that anybody who is responsible for the implementation of a reuse community to investigate software prod- 21 piece of software must specify more than this. He must specify the design, uct line architectures. Another book by the form; and within that framework programmers or engineers must cre- Rechtin and Mark Maier, The Art of Systems ate something. No engineer or programmer, no programming tools, are go- Architecting, nicely filled the gap between sys- ing to help us, or help the software business, to make up for a lousy design. tem and software.22 Control, management, education and all the other goodies that we have talked about are important; but the implementation people must under- 1999–2005 stand what the architect had in mind. 1999 was another key year for software ar- Probably a lot of people have experience of seeing good software, an indi- chitecture, seeing the first IFIP Conference on vidual piece of software which is good. And if you examine why it is good, Software Architecture23 and the founding of you will probably find that the designer, who may or may not have been IFIP Working Group 2.10 and the Worldwide the implementer as well, fully understood what he wanted to do and he Institute of Software Architects. Many nonaca- created the shape. Some of the people who can create shape can’t imple- demics started to pitch in best practices.24–27 ment and the reverse is equally true. The trouble is that in industry, partic- In hopes of increasing the practice of architec- ularly in the large manufacturing empires, little or no regard is being paid to architecture. —Software Engineering Techniques: Report of a Conference ture description, the Open Group introduced Sponsored by the NATO Science Committee, B. Randell and J.N. Buxton, the Architecture Description Markup Lan- eds., Scientific Affairs Division, NATO, 1970, p. 12. guage, an XML-based ADL that provides sup- port for broad sharing of architectural models. Joining forces with the reuse and product-fam- ilies communities, software product lines be- In 1992, Dewayne Perry and Alexander came a sort of subdiscipline, attracting lots of Wolf published their seminal article “Founda- attention of large manufacturing companies. tions for the Study of Software Architec- New methods such as SAAM, BAPO, and ture.”12 This article introduced the famous ATAM emerged or consolidated.14,28,29 We formula “{elements, forms, rationale} = soft- had one general architecture standard, RM- ware architecture,” to which Barry Boehm ODP,30,31 and we added one, IEEE 1471.1 The added “constraints” shortly thereafter. For SEI team produced book after book,29,32–34 many researchers, the “elements” in the for- and more.