Software Design and Architecture The once and future focus of software engineering
Richard N. Taylor André van der Hoek Institute for Software Research Institute for Software Research University of California, Irvine University of California, Irvine Irvine, California 92697-3455 Irvine, California 92697-3455 [email protected] [email protected]
Abstract opment, have studied and written about software design over the past forty years and more. Fred Brooks in- The design of software has been a focus of software cluded in his 1975 list of “promising attacks on the engineering research since the field’s beginning. This conceptual essence” the growing of great designers paper explores key aspects of this research focus and [21]. Peter Freeman, in 1976 [31], said “Design is rele- shows why design will remain a principal focus. The vant to all software engineering activities and is the intrinsic elements of software design, both process and central integrating activity that ties the others together.” product, are discussed: concept formation, use of ex- Design will remain the focus of software engineer- perience, and means for representation, reasoning, ing. Herb Simon, in his classic, The Sciences of the and directing the design activity. Design is presented Artificial [75], includes a discussion of design in the as being an activity engaged by a wide range of stake- context of “artificial” fields, such as software develop- holders, acting throughout most of a system’s lifecycle, ment, saying: making a set of key choices which constitute the appli- “The artificial world is centered precisely on this cation’s architecture. Directions for design research interface between the inner [the means] and outer are outlined, including: (a) drawing lessons, inspira- [the task] environments; it is concerned with at- tion, and techniques from design fields outside of com- taining goals by adapting the former to the latter. puter science, (b) emphasizing the design of applica- The proper study of those who are concerned with tion “character” (functionality and style) as well as the artificial is the way in which that adaptation of the application’s structure, and (c) expanding the no- means to environments is brought about – and cen- tion of software to encompass the design of additional tral to that is the process of design itself.” kinds of intangible complex artifacts. Put in software engineering parlance, the outer envi- 1. Introduction ronment is the world of requirements, goals, and wants; the inner environment is the set of software languages, Design is the central focus of software engineering. components, and tools we have for building systems. Design is both a verb and a noun. It is a key thing we As software engineering researchers, we are always do and that we produce. “raising the floor” – creating new levels of infrastruc- Such crisp statements will alternatively strike one as ture upon which new developments may be built. In obvious or, perhaps, as parochial – if not incorrect. Yet Simon’s terms, the “inner environment” or the “means” if we consider what software engineering is, namely a is ever changing and expanding. As the floor rises, practice directed at the production of software systems, however, so do our desires and aspirations. Though then design is seen at its heart, as it is in any other pro- achievements in improving design have been obtained ductive enterprise, whether the creation of skyscrapers, over the previous decades, new challenges for design automobiles, toasters, or urban regions. will thus continuously arise. Not surprisingly, then, many software engineering researchers, or those acquainted with software devel- feel” does the application give to its users? What “style” does it exhibit? What is its branding, or distinc- Goals and Dreams tive behavioral character? Using the analogy of auto- motive design can make the distinction clear: design "The Task" research of the first type is directed at the mechanical organization and structure of the vehicle; design re- DESIGN search of the second type is directed at shaping the car’s appearance, performance, sound, and smell. Do- ing a good job of one type of design does not imply "The Means" doing a good job with the other, yet they are intrinsi- cally interrelated. Both are important, and are legiti- Materials, Tools, and Mechanisms mately the subject of (software) design research. Work on design of the first type has certainly
Figure 1. The continuing place of design. yielded a wide range of important results over the past several decades. Numerous development methods have Nonetheless, at a suitably abstract level the chal- been espoused, many based upon the articulation and lenges for software design today are the same as they application of design “principles” such as modularity were forty years ago. They are the intrinsic challenges and planning for change. Means for representing de- of design: How to create artifacts to obtain goals, how signs have been devised; domain-specific approaches to represent new conceptions, and how to analyze have been created and supporting tools supplied. In them. Brooks made this observation twenty years after recent years, particular advances have been made with the original Mythical Man-Month was published. He regard to product families and the careful specification said the distinctive concerns of software engineering of system architectures. now are exactly those he set out earlier, namely “How Work on design of the second type has often been to design and build a set of programs into a system; ignored by software engineering researchers, and in- How to design and build a program or a system into a stead relegated to either other sub-disciplines of com- robust, tested, documented, supported product; How to puter science, especially human-computer interaction maintain intellectual control over complexity in large researchers, or simply left to practicing engineers in doses.” [20] (pg. 288). Ten years after that statement it industry. is still true. Design of both types is increasingly recognized as a Arguably all the major threads of software engineer- critical corporate and national asset. Designing of ing research are directed at improving our ability to products is seen as an activity that cannot be effectively meet the challenges of designing software. Work in off-shored – regardless of the shore on which one is requirements engineering contributes to Simon’s “outer standing. Design can be a differentiator that determines environment”; process research addresses the coordina- an organization’s success. The ability to design effec- tion of all activities focused on creating, implementing, tively is typically the partner of the ability to innovate. and evolving designs; empirical studies improve our The remainder of this paper seeks to explore how ability to assess design artifacts and the processes by and where to advance from the state-of-the art. We which they were created; analysis research improves proceed by first examining some major historical our ability to assess candidate designs; work at the pat- threads of design research, then highlighting a few no- terns and frameworks level improves our ability to real- table current trends. These sections are not merely ize designs in source code; and so on. background; by straightforward implication from what Though a focus on design has been, and will be, the we describe, some key directions for software research central issue in software engineering, the type of design emerge. Drawing from the perspectives of these two on which our energies have been focused has been sections, we then examine the character of design in rather lopsided. Our focus has largely been directed at more detail. The remainder of the paper explicitly lays the design of software qua software. That is, we focus out a set of further research directions, and concludes on the structure of software and its attributes, such as with some challenges and a “long view” of the promis- considering what components and connectors comprise ing future of software design. a system, and what constraints govern their interac- tions. A lesser role in software engineering has been assigned to the design of software as it exhibits charac- teristics to its users. For instance, what “interactive 2. Paradigms and Persuasions dards for the field. Two primary concerns in the formu- lation of new notations are expressiveness and usabil- The past forty plus years of design research can be ity. Expressiveness concerns what aspects of a design taxonomized many ways, such as by describing the can be captured in the notation; usability concerns the history of models, methods, and tools over time. These fluidity with which designers can work with the nota- topics are not independent, however. Rather, the back- tion. Though both factors are equally important, the ground or disciplinary orientation of an individual or primary driving force behind the development of most group tends to bring along a set of beliefs, choices, and new notations has been expressiveness – adding model- approaches. Any such perspective, then, drives specific ing capabilities, often for a particular analysis purpose. choices in a variety of areas. Extensibility is a required property of any modern notation, as it is now common knowledge that no stan- Prescriptive Design Methods dard notation can fulfill all modeling needs. UML pro- files are perhaps best known in this regard, with a host Perhaps most familiar to the software engineering of profiles publicly available that address a broad vari- researcher is the perspective of the “software method- ety of modeling concerns. ologist”. Typified best, perhaps, by work in the 1970’s and 80’s by such authors as Yourdon [81, 82], Jackson The Wisdom of Experience [41, 43], and Parnas [61-65], this strand of work fo- cuses on the first type of design discussed above, the Still focusing on the design of software, but coming design of software as the artifact of interest, and is an at the problem from essentially a bottom-up perspec- approach that states a principle, then prescribes how to tive, is a strand of work focused on capturing the les- design based on that principle. sons of experience in such a way that future designs Much of this work has been top-down in style; prin- can be guided. The work on “design patterns” is typical ciples of design are articulated (“separate abstractions”, of this strand. While the “Gang of Four” patterns [33] “use information hiding”, “refine higher-level abstrac- are directed at the programming language level, the tions into a set of lower-level abstractions”, etc.) and concept can be applied at any level of abstraction, in- then either methods for employing those principles or cluding requirements (where the experience may be notations which highlight or support application of the captured as “frames” [42]), whole-concept system principles are developed. structure (where the experience is captured as domain- One influential strand of work began with Russ Ab- specific software architectures [10, 38, 79]), and gener- bott [8], and was then expanded upon and advocated by ally at the level of system components and connectors authors such as Grady Booch [17]. This design ap- (where the experience is captured as styles and archi- proach is, roughly, “design by simulation”, in which the tectural templates [9, 34]). software application is straightforwardly designed by Methods for analysis and restructuring of software creating software objects that correspond to entities in may reflect insights from this research strand, such as the real world, and whose methods correspond to ac- are found in refactoring analysis and reverse engineer- tions in the real world. The work contributed to object- ing. oriented design, and became in a broader context to be Knowledge representation and design rationale re- supported by methods such as the Rational Unified search may contribute to the effective employment of Process [51], with designs represented in the Unified design based upon the wisdom of experience. Modeling Language (UML) [52]. HCI Design Notations Innovation in product design and distinctiveness in Notations have been a part of software design since product design have long been argued as contributing the beginning. Any time design thought is externalized, to product (and corporate) success [45] – though such such thought must be written down in some structure or innovation is no guarantee of commercial success. The form that supports interpretation at a later time by oth- software engineering literature is relatively silent on the ers, oneself, or a computerized program. It is no sur- matter of such design, possibly because researchers prise, then, that notations continue to serve as a pri- view the subject as too domain-dependent, and hence mary driver of research in the community. exclusively the focus of developers within that domain. Notations range from informal conventions that are Even if one assumes that, it is surprising that software established on-the-fly by a group of designers engaged researchers have not focused on the methods by which in a design exercise to precise formalisms that are stan- innovative domain-specific designs are created. The exception is user interface design. Often rele- Cognitive and Social Strategies gated to (at best) the fringes of software engineering research, human-computer interaction research includes A final strand of design research is exemplified by a focus on techniques for developing user interfaces the work of Donald Schön [72], and found in software which effectively engage and satisfy the user. Some engineering in the work of, for example, Fischer. A key lessons of such work are captured, for instance, in pat- perspective emerging from this work is what Schön terns for web site design, as found in the work of Lan- terms reflection: the designer reflects upon the process day and colleagues [80]. This work is partially bottom- and upon the product. Design in this view emerges as a up, in the manner described above, but also reflects “conversation” between the materials (the external con- cognitive understandings of how people interact with straints on the design, the initial sketches attempting to web sites and undertake electronic commerce transac- develop a solution) and the designer. tions. Design, however, is not a solitary activity. Teams of The importance of considering this field is indi- designers interact, varied stakeholders participate, and cated, in no small measure, by the repeated failure, broader communities of practice [29] exist within over many years, of standard software engineering top- which individual designers perform their work. Design, down design techniques to create pleasing and effective thus, is a social process, one of information exchange, user interfaces. learning, creative and cognitive stimulation, and con- versation – all aspects that must be taken into account. Design Outside of Software 3. Contemporary Currents The field of design, and design research, outside of software engineering and computer science is enor- Contemporary currents in design sometimes add im- mous. While both types of design discussed above are portant perspectives to the schools of thought described within this wider world’s view, a greater emphasis is above, as well as combine, apply, and refine them. found on the second type – user experience. Less work is found on representational issues; since physical ob- Agile Methods jects are being designed the representation means (typi- cally sketching) is natural. More work has been di- While for some “agile methods” are a step back- rected at methodological approaches, with [44] a clas- wards in the history of software design research – be- sic example from the domain of industrial engineering. cause the design exists only in the code –, the agile The software patterns work, however, derives its name, community has emphasized three important design at least, from work in building architecture [11]. practices. First, it is an example of the application of The relevance of lessons from design “out there” to participatory design: by involving the user throughout software design has been noted by many. Participatory the iterative development process, the product is con- design has been advocated by some in the HCI com- tinuously shaped to meet the user’s needs. Secondly, munity [35], and, arguably, software engineering’s “ag- test-driven development makes the design of function- ile design” draws from some of its key elements . Less ality of equal importance to the design of system struc- directly, the capabilities of CAD systems like CATIA ture, which represents a rudimentary integration of the have been an inspiration throughout. two types of design we discussed in the Introduction. A further perspective on design exhibited by the lar- Lastly, implicit in the agile approach is that the ger design world, but which software engineering has process of design continues throughout development. mostly ignored (or scorned) is that of design as art. With little extrapolation, design can be seen to continue While Donald Knuth unabashedly titled his monumen- throughout the life of the product – a characteristic not tal series, “The Art of Computer Programming” (e.g., shared with many products from the realm of physical [46]) and promoted “literate programming” [47], we product design. have not developed a practice of critiquing the aesthet- ics of any kind of software design, of endeavoring to Aspect-Oriented Software Design instill an appreciation for elegant software design, or of providing public forums for the promotion and recogni- The original aspect-oriented programming paper tion of excellence in design1. states “A design process and a programming language work well together when the programming language
1 provides abstraction and composition mechanisms that The ACM Software Systems Award is an excep- cleanly support the kinds of units the design process tion, though it is not widely promoted – certainly not in breaks the system into.” It then makes the argument the software engineering community. that programming languages must conceptually distin- Software Architecture guish components (units of a system’s functional de- composition) from aspects (system properties that can- The many strands of work in software design de- not be cleanly separated and instead crosscut compo- scribed thus far have most fruitfully blended and ma- nents) [54]. This view of AOP strikes an important tured into the field of software architecture. With an chord with design, as separation of concerns is one of encompassing definition of software architecture as the leading approaches to tackling a design problem’s “the set of principal design decisions governing a sys- complexity. Unfortunately, this design-oriented per- tem”[78], it engages the full range of design activities spective seems to have given way to AOP language and includes the full range of participants in the design minutiae and a focus on “aspectizing” any and all soft- process. Software architecture encompasses work in ware artifact. Nonetheless, the critical role of the pro- modeling and representation, design methods, analysis, gramming language in the design process persists, and visualization, supporting the realization of designs into AOP has and continues to have an impact as such. code, experience capture and reuse, product lines, de- ployment and mobility, security, adaptation, and so on. Design Analysis Software architecture research began in earnest in the early 1990’s (e.g. [66, 73]), though the term is dec- One of the reasons we design is to reduce risk by ades older (it is found, for instance, in many works enabling prediction of system properties. Not surpris- from the early 70’s). Work in the 90’s was initially ingly, the field has devised numerous ways of perform- focused largely on matters of design representation ing design-based analyses. Many of these have been [56], though the whole movement could be character- described, for example, in the SAVCBS workshop se- ized by a desire to provide substance, structure, and ries (Specification and Verification of Component- specificity to the historic field of software design. Ar- Based Systems). Most of these analyses concern exter- guably, software architecture has been focused on the nally visible properties, such as reliability, real-time maturation and professionalization of a field previously constraints, or concurrency, although a fair amount of best characterized as craftsman-like. work also concentrates on properties internal to a de- The successes achieved by software architecture sign, such as structural quality or reusability [71]. over the past fifteen years span from commercial use of Different design representations are suited to differ- product-line architectures, such as at Philips [59], to ent kinds of analyses; new analyses may require new the architectural underpinnings of the World Wide notations to be used. Web, as characterized by the REST style [27]. Architecture is a backdrop for much of the direc- Component-Based Design tions for software design that we characterize in the remainder of the paper; its importance is reflected by A desire to structure large-scale business applica- its inclusion in this paper’s title. tions in terms of standard, reusable components contin- ues to drive a non-trivial part of the industrial software 4. Design, Designing, and Designers landscape. While each guarantees somewhat different properties as emphasized by somewhat different usage The careful reader will notice that we have, so far, scenarios, component-based design, model-driven ar- refrained from defining software design, or even design chitecture, and web services all can be grouped as ad- itself. So it is with the contributions discussed in Sec- dressing this desire in a similar manner. In fact, they tions 2 and 3, which by and large typify design accord- can be seen as evolving from one another, with compo- ing to a certain perspective (e.g., a phase, in the code, nent-based design focusing on reuse of the individual art, engineering) and then work within this perspective component, model-driven architecture on standardiza- to make their contributions. tion of components into reusable middleware [30, 40], To understand how these perspectives relate and to- and web services on reuse of components and middle- gether help or hinder in advancing the field as a whole, ware across distributed and decentralized applications. it is critical that the field establishes a common basis Of course, different components do not magically fit from which its progress can be judged. The following together. A particular challenge is to design the “glue” summarizes a general model of design that is intended that bridges mismatches in functionality, interfaces, and to form such a basis [13]. The model consists of two interaction paradigms. interrelated parts: one part capturing the essence of design-the-product, the other part capturing the essence of design-the-process. When used as a noun, design normally indicates the When used as a verb, design normally indicates the artifact (product) that emerges from the design process, process by which a design is achieved. It is understood some physical document or other kind of representation to be a human-centered process, involving varied that articulates the intent of the designer. This product stakeholders. It is also understood to be strongly goal- results from the choices the designer made, choices that driven and drawing upon established knowledge of the form an abstraction of that what is eventually desired to designer and the field at large. be realized in the real world [49]. The general design literature has made precise char- These words are in some ways obvious, but in other acterizations of this process, which are brought to- ways not sufficiently precise to help guide a field. The gether in Figure 3. The design process is one of infor- general design literature has made various characteriza- mation manipulation (broadly construed to encompass tions that can be used as such (e.g., Simon [74], Nor- initial creation, transformation, and deletion), with four man [58], Schön [72]). Figure 2 presents a visual of the types of information involved: goals, ideas, and knowl- amalgamate of these characterizations as they pertain to edge, which are all mental, and representations, which the design product. The figure distinguishes the design are physical expressions of mental information. Each of space from the outcome space. During design, we men- these types of information is phrased in one or more tally operate in the design space (where each point languages, and tools may be used to edit and/or inter- represents a unique set of design decisions), but con- pret representations. Within this setting, designers en- tinuously make decisions that reflect upon the outcome gage in one or more activities, through which they – space (where each point represents a unique artifact). directly and indirectly – explore the design space. The That is, each design decision alters the set of outcomes design process, then, is defined as the set of informa- that are still possible (SP), cutting away some and re- tion manipulation activities through which a successful enabling others. A design, then, is a point in the design design is obtained. space that represents a set of decisions that together delineate a set of possible outcomes in the outcome space.2 The customer brings into this their understanding of what are desirable outcomes (D), which, whether or not explicitly stated, act as constraints on the design proc- ess. Another set of constraints is exercised by the avail- able materials from which an outcome is constructed by following a design’s blueprint: a design should describe only outcomes that are feasible (F). A successful design Figure 3. Design – The Process. is one that restricts its still possible outcomes to those that are desirable and feasible. An important property of this general model of de- sign is that it does not bias itself towards any individual perspective on software design. Rather, it supports the field in giving it the ability to precisely relate different perspectives and understand their emphases, strengths, and weaknesses.
The Elements of Design Research
A corollary from the preceding discussion is that the model points toward exactly where it is possible for a discipline as a whole to make progress in better sup- porting its designers. Particularly, it can:
• Improve the materials from which a product that is Figure 2. Design – The Product. envisioned by a (finalized) design is eventually in- carnated in the real world. For example, the avail-
ability of newer, lighter composites enabled differ- 2 This discussion is not meant to imply the existence ent kinds of planes exhibiting different weight and of a separate design phase. The spaces we refer to are aerodynamic properties to be designed. ephemeral and largely present as a result of the way in which human’s think – through abstraction. • Improve the languages that are used for capturing representations, an observation that is a natural outflow goals, ideas, and knowledge. Alexander’s design from the general model of design. The effectiveness of patterns are an example of such an advance, bring- such communication is determined by the language(s) ing together goals and ideas in a single representa- used [22]. Presence of a design team also induces re- tion that furthermore supports easy adoption. quirements for coordination of its design activities. • Improve the general knowledge the community has Such coordination could involve formal management if about its design domain and design processes. For the task is large enough. instance, the human genome project is of tremen- Second, however the design is produced, other indi- dous value to the design of new medicines, provid- viduals, playing other roles, are critically engaged with ing a data bank of knowledge that previously was the design. They must be able to understand and use it. unattainable. In traditional development practices wherein the im- • Improve the portfolio of activities that are used in plementation activity is separate from the design (more the design process. IDEO’s focused form of brain- about this below), the implementers must be able to storming is an example of an activity that led to comprehend and utilize the design. The practical chal- improved results, both in terms of time and out-of- lenges of this become highlighted should such imple- the-box solutions [45]. mentation be contracted to another firm, perhaps to one • Improve the tools with which design activities are on another continent. In other situations, the customer supported, particularly in creating and interpreting may be desirous of participating in substantive review representations. For example, the automotive in- of a design. In yet other situations end users may be dustry has made significant leaps in their ability to participants in the design process. All of these engage- design by moving from clay models to CAD/CAM ments with design highlight the critical role of and de- designed 3D visualizations. mands on shared representations of design. Third, beyond just recognizing the existence of a All progress, whether in the form of a new methodol- multiplicity of designers and “design readers”, we also ogy, notation, metric, or analysis algorithm, to name a must recognize that the multiple stakeholders of a sys- few, will eventually reduce to these five basic underly- tem (can) all contribute to the design itself. The typical ing categories. perspective has been that, since software is being de- signed, software specialists are the only ones who The Community of Designers properly determine the software’s design. As discussed in detail in [57], however, both application domain Just as it is important to understand the fundamental experts and business stakeholders are properly con- elements of design, so it is important to recognize the tributors to a system’s architecture. Domain experts richness of the community of designers – those who naturally know or determine the key abstractions for a design, who contribute to the design, and who must system, acceptable strategies for meeting regulatory interact with design representations, designers, and requirements, or provide vital insights on what parts design processes. Historically, design has largely been and in what ways the design must be flexible to ac- seen as a somewhat provincial task performed by a commodate potential future changes. Business-focused small number of software specialists – perhaps one stakeholders may determine key boundaries for a prod- “chief designer” – during a circumscribed period in a uct-line architecture, and hence determine critical soft- project’s lifecycle, namely following requirements ware interfaces. Design, thus, is not the exclusive prov- analysis and preceding any implementation. Clearly, ince of the software technologist; the multiple and such a simplistic notion is either counter to what really proper contributions from the wide community of happens in a project, or if actually followed yields sub- stakeholders must be accommodated. This final com- par results. In truth, the number and types of individu- ment is not easy to achieve, however. Separate stake- als with vital interests in a project’s design represents a holders likely require (or at least request) views onto an broad community of interest [29]. Existence of this emerging design which are idiosyncratic to their per- community imposes some particular demands on de- spectives. Supporting multiple viewpoints while ensur- sign; recognition of the breadth of the community high- ing consistency among them constitutes a current chal- lights opportunities for improving our practice and lenge towards which the community has made progress expanding our research agenda. (e.g., the 4+1 model [50], analyses to discover incon- First, for a project of any significant size, more than sistencies [26], and an understanding that certain forms one designer will be involved. Existence of multiple of inconsistency must be tolerated [15, 28]), but for designers thus imposes demands for communication of which much work remains to be done. design concepts [21]. Communication implies shared Fourth, arguably the design community increasingly section is devoted to discussing a variety of more spe- includes the end user. Common applications such as cific directions. Before moving to the more specific spreadsheets and word processors actively invite the discussion however, we consider three general issues. end user to customize – i.e., design – their working First is the matter of design decisions. Designing is environment and the complex artifacts produced with fundamentally a matter of making choices – how to desktop tools. At best the software engineering com- accomplish something, how to represent something. munity has barely recognized this community of de- That suggests that an effective approach to design signers; after all, they are not software specialists, have should offer a solid understanding of choices: what little or no formal training in design, and produce de- they are, recognizing when they are made, what the signs researchers may dismiss as trivial, or simply as alternatives were, and capturing them in such a manner poorly done. But the enormous number of end users, as to allow retrospection. In typical practice we are far the substantial ability for customization and design from having a grasp on this: decisions are often implic- presented by desktop applications, and the potential for itly made. It is not until later that we recognize that improving the quality of end user designs argues certain functionalities or properties were precluded, or strongly for design researchers to turn their attention to inhibited, by an early choice. Decision support systems this special world. As one example, spacecraft systems from the 1980’s, such as gIbis [23], offered explicit designers use complex, interlocking Excel spreadsheets support for formally considering choices facing a to design new systems and missions [55]. These com- group. This type of support is needed, but must be pro- plex spreadsheets are designed, however, without any vided in a lightweight manner that is integral to and higher level of abstraction or representation; under- supportive of design. Perhaps more important, how- standing them and “verifying” them is left to the engi- ever, would be practices to aid in recognizing when neer, who must interpret the macros pervading the choices are being made. spreadsheets. A better way is surely possible. Second is the matter of the place of design in the software engineering process. As the discussion in the 5. Research Directions previous section indicated, the activity of design is not limited to one individual or one circumscribed place in The introductory section of this paper indicated how the development process. Critical decisions – design design will remain an enduring challenge. As our abil- decisions – are made throughout system development ity to design solutions to current statements of wants by a variety of stakeholders. Talk of “requirements and needs improves and becomes more predictable, our engineering” that is wholly independent of design, for conception of what might be achieved expands. As “the instance, is frequently either sophistry or simply means” improves and rises, “the task” becomes more counter-productive. As critical decisions about a sys- adventuresome and demanding. Our ability to design tem are made – whenever they are made – design is must be correspondingly enhanced to make use of the being done, the architecture is being established and improved materials, tools, and mechanisms to create should be recognized as such. Similarly, implementa- solutions to the new goals and dreams. Seen in this tion is improperly and unrealistically considered the general light, all the elements of design research listed rote translation of design to code, sometimes to the in Section 4 above will persist; it is a matter of under- point where a design intentionally does not make a standing and improving: choice of programming language so to be general in nature. Key choices made in and about the implementa- • the materials – the conceptual building blocks – tion process, such as the decision to use a particular from which designs are eventually realized as arti- implementation framework or programming language, facts in the real world. are important parts of system design, affecting future • the languages that are used for capturing goals, strategies for system modification and adaptation. The ideas, and knowledge. importance of such design should not be overlooked. • the general knowledge the community has about its The challenge for design researchers is to provide prac- design domain and design processes. tical guidance to those involved in setting system re- • the portfolio of activities that are used in the de- quirements, in coding the system, and indeed in all sign process. other aspects of system development for their appropri- • the tools with which design activities are sup- ate participation in design. More generally, the ques- ported. tion is how to structure software development proc- While comprehensive, this list is too generic to be esses to support a robust, modern conception of design. of much use in setting directions; the remainder of this Third is the matter of choice and evaluation [32, relating such diverse sets of concerns. Extensible archi- 74]. As designers confront issues, a set of choices tecture description languages are a foundation, but their emerge. Beyond recognizing and recording the choices modeling capabilities must be supported with flexible made, designers need support for evaluating alternative environments and design processes. choices so to guide them towards a design’s objectives. This strongly relates to the need to manage evolving Analysis techniques may focus on functional or non- architectures. When stakeholders make changes, it is functional system properties, and may span to analysis often the case that the architecture degenerates. Espe- based on economic arguments [12, 77]. While devel- cially with product line architectures, it is known that opment of individual techniques continues to be even a pungently cohesive initial definition slowly but needed, the field also should find ways in which such surely may morph into a set of disjoint product archi- techniques can be combined to enable multiple proper- tectures. Processes have been employed to ameliorate ties to be jointly assessed, in the manner of statistical this problem, but overall our level of understanding is decision theory for example, to enable broadly in- still limited and our tool support for carrying out such formed choices to be made. processes trails significantly. Throughout the design process, whether it is a high- Directions Reflecting Good Recent Progress level architecture or a low-level UML class diagram, it is generally important to ensure that certain properties In defining a research agenda, it is important to rec- are met, such as, for instance, behavioral consistency, ognize those research directions that “work”, have had real-time performance constraints, reliability, levels of impact already, and should be explored further because security, and concurrency behavior. The analysis com- they continue to have promise in advancing the field. munity has made steady progress in providing analyses The first direction we discuss as such is software ar- that can provide such guarantees and continues to work chitecture. It is interesting to put architecture in light of on faster and more efficient analyses, analyses for new the five directions of design research presented in Sec- properties, and general infrastructures[16, 24]. tion 4. To date, advances have included, among others, A particular challenge is to make these analyses, and architectural middleware, description languages, styles, the modeling of the information that is needed to drive design methods, and environments, which collectively them, an integral part of the design process, rather than cover the five research dimensions along which pro- some activity that is performed as a “check” when the gress can be made. That is, architecture has turned out design process has finished. Two problems persist: the to be a natural fit in pushing design research forward. need to create precise representations, and the need to Of particular importance is the focus on early design fully, or almost fully, model a design before it can be decisions. Architecture, though it can be mapped onto analyzed. It is incumbent upon the field that these two code effectively, is initially about supporting the ex- problems are overcome, so that analyses become usable ploratory process. Architectural styles are critical in throughout and especially when it matters most: during this regard, documenting accepted solution strategies as rapid generation and evaluation of (not necessarily pre- sets of reusable design decisions that can be readily cise or complete) alternatives, for which analyses are adopted. Clearly-documented and well-packaged styles vital in understanding the tradeoffs inherent in the de- come closest to the original definition of architecture as sign decisions made. “structure, form, and rationale” [66]. As important as the externally-visible qualities of a Architecture has also strongly influenced software design are its internal qualities: is its structure sound, is product lines. The vast majority of software product it optimal, and will it hold up over time? A recent trend lines are actually realized through product line archi- has seen attempts to assign “value” to designs, particu- tectures, which are used to distinguish those parts of larly by employing economic analyses that stem from the system that are shared among all products and those adapting and applying established economic theory to parts that are variable and depend on the product at the domain of software design. Most promising to date hand [70]. The use of product lines has become suc- is the use of Design Structure Matrices [14]; with them, cessful with several success stories emerging that detail it is possible to visually compare different modulariza- how this kind of domain-driven approach can be bene- tions, assign these modularizations values, and in so ficial and provide a competitive advantage. doing understand design tradeoffs, such as whether to That said, there is significant work left to do. Design refactor or to apply aspects. These results, however, involves multiple stakeholders who may have radically represent only a beginning. Values are assigned mostly different concerns. Having focused strongly on compo- to entire designs, not necessarily individual design de- nent-connector centric approaches, current architectural cisions (though these can be valued in the context of description languages lack facilities for specifying and given design changes). Values also are “instant”, for that employs a brute-force strategy that is able to pro- the design as it is now; not how they stand up against vide at least as good results without requiring use of future design changes. A critical dimension of future any standard mark-up or meta-data. This, of course, is work, then, is to find mechanisms of valuing individual the beauty of today’s Google search as applied to design decisions over time. document searches. One long-term direction, therefore, Another important aspect of this work lies in the his- is to develop search algorithms that perform architec- torical lessons it can teach. Applying Design Structure tural abstraction automatically, and then “page-rank” Matrices to numerous designs, both good and bad, can those abstractions against the user’s query, where that build a portfolio of examples from which it furthermore query is phrased in terms of architectural properties. may be possible to deduce general principles. The networking that is a key enabler of Internet Finally, we return to the topic of architectural styles search is also a key enabler of improved communica- and, more generally, the capture and reuse of architec- tion between individuals and teams. As the legitimate tural experience. Experience and "good design prac- role of the many stakeholders in a design process is tice" can be captured at different levels of abstraction recognized, advances in network communications can (from source code up to the highest level of system be brought to bear to improve their participation. Col- structure) and with different degrees of generality laboration technologies in general offer significant po- (from useful within all application domains to useful tential for the design process [39]. Communication only within highly specialized application domains). technologies are, relatively-speaking, free; designers We need the ability to capture the lessons from prior should exploit that. developments at all points in this space, and to do so in Display technology offers another basis for im- a manner that effectively enables other engineers to provement in design practice. Very high resolution, find, understand, assess, and apply the lessons to the very large screen displays are now readily available. development of new systems. In simplest terms this Such displays give designers the potential of seeing could involve developing extensive catalogues of archi- more of a design from more perspectives simultane- tectural styles. The richness and variety of experience ously. And why should design be confined to the flat- demands better ways of capturing, finding, and using land of 2-D displays? Other scientific disciplines have knowledge, however. Other design disciplines have already exploited high-resolution displays; it remains matured by doing so, it is time we do so as well. for software designers to design such support for their own discipline. Designers should have displays on their Directions From New Capabilities desktops that are at least as large as the televisions in their homes. Beyond the desktop, there is no reason Progress in computer science has often been pro- why teams do not have specialized design rooms pelled – or compelled – forward as the result of ad- equipped with numerous touch-sensitive displays and vances in hardware. So it is now with design. Advances batteries of computers that enable instant analysis. in networking, display technology, storage, and proces- The continuing decline in the price of storage with sor speed offer the potential for significant advances in an accompanying increase in capacity suggests other the practice of design. new directions for design. Why not always record de- As a first instance, consider the potential of search- sign rationale – even as video? Keying video/audio ing for domain knowledge, prior designs, evaluations capture to the designers workstation activities, context, of designs, “similar structures”, and so on, in the man- and display offers unprecedented potential for retro- ner of Google. That is, the ability to access information spectively understanding a design and reusing the in- across the Internet, and especially the ability to search sights present at the time of design. In the case of de- that information in comprehensive fashion, offers the sign forensics following a system failure, for example, potential for exploiting experience from prior designs such storage offers the potential for identifying the root in a manner far beyond anything we have yet seen. A cause of a failure, and hence for eliminating related simple use of existing Google-like search will not be latent errors elsewhere in a system. sufficient, however. A designer will seldom be search- Lastly, the continuing rise in processor speeds sug- ing, for example, for a module with a specific textual gests that designers, and those who develop design interface. A designer will want to search based on vari- tools, should never be restrained by a perception of ous architectural abstractions. Enabling search based something “taking too long”. Nor should tool develop- on architectural meta-data, for instance, is a near-term ers be distracted into complicated optimizations of, possibility for meeting this goal. Yet any search e.g., analysis procedures, when the use of simple brute scheme that requires some structured meta-data as in- force suffices. If something seems to take too long, just put stands the risk of being overtaken by a technology task a few dozen more processors to the problem, or continue without such breadth invites organizational simply wait for the next generation of processors to “surprises” and application system failures. appear. The time to develop a reliable optimization Fourth is the design of applications as seen and ex- may well exceed the time for a doubling of processor perienced by users. This was discussed in the Introduc- speed. tion as the “second type” of design. The need and op- In summary, let us as designers exploit advances in portunity is profound; further discussion is reserved for computation to advance the practice of design. Our task the Challenges section. is as worthy of innovative use of technologies as our The next two directions are closely related and are clients’ tasks are. motivated, at least in part, by economics. The first of these is supporting design recovery and analysis. Estab- Directions From Design Imperatives lished systems represent significant economic assets. To the extent that such assets can be used to meet new For software design and architecture to mature into organizational needs, economic efficiencies are real- a robust discipline capable of handling the challenges ized. Recovering the architecture of existing systems posed by emerging applications, advances in several enables assessments of potential future uses to be made areas are imperative. Our list here is eclectic, reflecting so that adaptations can be based on solid architectural our perception of particularly poignant needs. understandings. While several research projects in this First is adequate support for moving from architec- field exist and have yielded promising initial results ture to implementation, and fluidly moving between (see, e.g., [18, 36, 37]), there is still much to be done. design and coding tasks. If design does not ultimately The second and related direction is actively managing support production of a satisfactory implementation design evolution – in particular mitigating architectural (assuming that the resources and the will to produce are decay. Here the issue is not recovering a design to both present), then it is a failed effort. Many current merely enable the first steps of progress to a new or design approaches fall silent when it comes to imple- improved system, but the task of assessing an existing mentation. Since key design decisions may be made in design and evaluating alternatives for modifying it to the implementation context, evolution of the architec- meet new and changing needs. Clearly to the extent the ture must be seamlessly integrated across the contexts. architecture is explicit and faithful to the implementa- Seamless integration implies full traceability between tion, this process is facilitated. But that is only the be- code and higher abstractions, and supports accountabil- ginning; an evaluation framework and process to assist ity of design decisions. in comparing alternative modifications is needed. Such Second is the ability to represent all stakeholders in- evaluations must not only support examining how im- terests, as discussed earlier. Multiple interests and mul- mediate demands can be met, but predict likely conse- tiple perspectives impose demands for assessing or quences for future, as yet unspecified, demands. guaranteeing consistency of design decisions (or for the Lastly, emerging application needs argue for design management of inconsistencies between them), as well techniques that yield self-adaptive systems. An impor- as demands for multiple presentations of select design tant topic in its own right, we refer the reader to [48]. data. Third, as software applications become ever-more Directions From Examining Our Past interwoven into organizations and society, we must develop means for the co-design of software and or- We learn from our successes, but we also learn from ganizational/societal systems. Introduction of a tech- our mistakes. This is an age-old lesson that has fueled nology into a group or organization may radically much progress in other design fields. Bridge design as change how the group behaves – think, for example, of it is today would not be as advanced without the careful how e-mail has altered both personal and public com- study of past structural failures [76]. The study of “why munication patterns. While a robust literature exists things break” has fueled the creation of newer, stronger describing how such organizational changes have oc- materials [25]. And a central theme in Petroski’s well- curred as the result of introducing software technolo- known writings is how failure has been a motivator for gies, we need a design discipline which integrates the design innovation [67-69]. intentional shaping of software technology with the How do we perform in software in this regard? Un- intentional shaping of organizations (one easy example fortunately, the answer is “not good”. We do experi- is the integrated performance of business process reen- ence failures, but the field does not profit from them as gineering with design of software systems for that busi- other disciplines do. A “we will just fix it in the code” ness). For co-design to take place, a broad range of attitude is far too prevalent, and we seem to have been expertise must be woven into the process of design. To lulled into a modus operandus in which the importance of design is, consciously and subconsciously, underval- guidelines, and a small handful of general design prin- ued. Compare the software view of design once again ciples. This work has to continue and be broadened to with that of bridge design. First off, one must appreci- cover all aspects of the design product and process. ate the effort that goes into a bridge’s design. Except Finally, we observe that we must not just understand for a few systems, our discipline rarely performs this good and bad design products, but also focus some of much design. Second, when something fails on a our efforts on understanding good and bad design prac- bridge, it is the design that is examined, and lessons are tices. By this we explicitly do not mean high-level ap- drawn from it. Such is not the practice in software; we proaches (e.g., Agile), but rather the approaches and rarely go back, carefully study a “failed design”, de- techniques that expert designers employ in designing duce lessons as to why the software (use, deployment, their software. For instance, it is well-known that prod- or even development itself) failed, and what we should uct designers may sketch hundreds of alternatives be- do differently, design-wise, next time – let alone share fore honing in on an eventual choice. Do software de- these lessons with the community. sign experts follow such an approach? If not, what do Any approach to learning from the past must start they do that makes them successful? Can these skills be with examples. Unfortunately, no software design ex- explicated and communicated to others? amples seem to be available. Textbooks contain small- Overall, the undercurrent of this section is that soft- ish systems. Search the web for “Good Software De- ware design is still far removed from being an estab- sign” or “Bad Software Design Examples” and not a lished discipline. To move forward, it is critical the single system comes forward (though lots of advice on field engages in the necessary deep scientific study of how to create a “good” design comes forward). Com- software design and designing. pare this to building architecture, where one can find book after book in the bookstore, including books of Directions From Looking Outside of CS “great designs”. Clearly, a first challenge for the com- munity is to begin assembling archives of good and bad While the design of software is a relatively new ac- design examples. By this we do not just mean UML tivity, having only been around for sixty years at the diagrams, but carefully documented, multi-level and most, design has been practiced in other fields for cen- multi-view explanations that provide in-depth insight turies. While sometimes still taught as a craft, or into underlying design decisions and their ramifica- learned through apprenticeship, design is newly taking tions. It is interesting, in this regard, to examine the shape as an academic discipline, even as a science. HCI literature. In it, one can find numerous papers that There is a Design Research Society [1] (which spon- introduce novel interfaces and describe their underlying sors a conference on doctorate research in design), and design motivations. Such a practice has not transitioned a wide literature. New university programs in design into the software engineering conferences as of yet. are emerging, such as Stanford’s “d-School” [7]. All We must also promote excellence in design. The this suggests that there is much that software research- SPLC product line hall of fame is an example of such ers can consider and draw from in order to advance recognition, as is the aforementioned ACM Software design specifically within the software field. A few Systems Award. In either case, though, we note that examples have already appeared in the preceding text: regrettably the actual details of the product and design we have referred to work in industrial engineering [44], that received the award are never shared with the architecture [11, 19], design processes [72], and broader community. Perhaps ACM or IEEE should civil/mechanical engineering. We provide a few addi- consider establishing an annual prize for the best soft- tional examples here, most of which are inspired by ware design, requiring that winning designs are placed building architecture. in the public domain.3 While architecture has already been mentioned, and From examples, we must then deduce patterns, prin- has been used for many years as, at least, an analogous ciples, do’s and do not’s, and other general understand- activity to building software, the richness of the build- ings that help individuals in building up a repertoire of ing architecture discipline suggests that there are still knowledge that can assist them in designing. Some of further insights to mine. For instance, Parnas’s dictum that effort is underway; we mention architectural styles, about designing software for ease of change [63] is software patterns and anti-patterns, design critics, bad explored, by analogy, with substantially greater rich- smell detection and refactoring techniques, HCI design ness in Stewart Brand’s “How Buildings Learn” [19]. The several layers of a building’s architecture deter- mine the ways in which the building can be adapted to 3 Of course, we can leave our version of the Razzies meet new needs. Bottom-up and top-down approaches (http://www.razzies.com) to an appropriate blog. to such design are considered and extensively illus- trated. It is a book that, while containing no reference what its aesthetic is, how it affects its user. In contrast, to software development, can be read, appreciated, and most software engineering courses spend no time applied by software engineers. studying existing design, instead plunging ahead with Another practice from architecture is that of a de- green-field approaches, yielding a too-predictable out- sign charette. A charette is related to software’s design come. reviews and walkthroughs, but is closer in spirit to ag- ile design, for the purpose of a charette is to move a Barriers To Progress design forward quickly, by developing and critiquing design in a group setting. In educational settings, cha- Having made a broad set of suggestions, we must rettes are part of design studios, where regular design acknowledge that significant barriers persist to making reviews take place. The normal practice of architecture these kinds of advances a reality in practice. First, as is to develop models suitable for and used in periodic, we observed earlier, design is seriously undervalued by active, productive, constructive group design reviews. many. On the one hand, we admit that there is some Perhaps most inspirational from the world of archi- basis for such undervaluing: the tools and techniques tectural design is the development of computer-based available to the average practitioner are not necessarily building models that enable designers and users (ten- very good, especially when put in light of the full spec- ants, residents) alike to fly through a proposed design, trum of considerations discussed in Section 4. This simultaneously seeing, as desired, both the internal state of affairs makes it difficult to convert the skeptic structure of the building and the appearance and ser- or to provide credible evidence that proper design(ing) vices of the building. In software design these concepts does make a difference. On the other hand, such nega- are almost always reviewed separately: how the code is tive attitude hinders progress: the effort spent objecting organized is considered almost independently of what might be better spent making advances or at least en- the user’s experience with the application will be. In couraging others to do so. building architecture, the intrinsic relationship between Second, designers are not necessarily equipped with these two views is understood; if the residents of a the right skills and, worse, they may or may not know house know in advance where load-bearing beams are whether their skills match up to a project at hand. Who they can adjust their expectations for how the building is qualified and how do they acquire their skills? Cer- might be modified in the future. Seeing how well, or tainly, some designers are simply great, whether by how poorly, the user interface is separated from the rest experience or intuition. But a vast majority has to ac- of an application’s code can reveal whether managers quire their skills somehow, yet a culture of apprentice- could sensibly direct a desktop application to be retar- ship is virtually non-existent. Granted, not all software geted as a web service. needs a great designer, but even the “average designer” Architecture even suggests how we might rethink must learn somehow. the composition of our academic teaching faculty. Ar- Compounding this problem is the remarkable toler- chitecture schools typically include many practicing ance that software professionals seem to have. If the architects, just as music schools include many practic- tools that we use to design are incomplete, inelegant, ing musicians. The conviction is that students can only and difficult in their use, then how can we be expected have an adequate understanding of their discipline to produce designs that are complete, elegant, and lead through engagement with faculty regularly acquainted to easy-to-use systems? And this does not just hold for with the full breadth of disciplinary challenges. One design tools. Poorly designed user interfaces and could examine many computer science departments and clunky programs abound. Where are we to find our find no faculty qualified to construct any application inspiration for quality? larger than a compiler – a task trivial in comparison A root cause can be found in the education of soft- with the challenges regularly faced by many profes- ware engineers [49, 53]. Most stem from a “standard” sionals in industry. Students must also engage in the Computer Science program, which incorporates at best practice, and do so repeatedly. a few software engineering courses and involves nu- Many design professions have another practice from merous other courses which ignore the lessons of soft- which we could benefit: the study of designs. Designers ware engineering altogether. Extensive practice with of luxury goods, buildings, machinery, and consumer significant software design problems is impossible in goods alike spend significant time assessing – studying this setting. The past decade has seen the emergence of – existing designs. The objective is not only to under- Software Engineering (e.g, [5, 6]) and Informatics stand how something works, but to assess its “non- (e.g., [2-4]) majors. The focus of most such programs functional properties” – what brand sense it conveys, is on design, a trend we welcome. Still, the materials available from which to teach design are limited and ceiling truss. Imagine now interactive cut-aways of much innovation is necessary in this regard. buildings, whereby the designer could move skylights To offer hope, there is the advantage of time. Early and see the consequences for the roof’s structure, or reports from the SIGSOFT Impact project indicate that change specifications on a window and note how the research advances may take up to ten or sometimes quality of interior light improves. even twenty years from initial idea to widespread prac- Realizing an analogous vision for software design tical use, as the original idea must find traction and requires our supporting the design and visualization of morph to reflect practical needs and considerations user functionality at least as well as our supporting the [60]. So, in a field that is as young as software engi- design and visualization of software structures. Not neering, perhaps we are not doing so badly? only must we see and manipulate components and con- Improvements and overcoming the barriers we men- nectors in an architecture, but see, as we do so, how the tioned, though, will require the community to undergo user’s data display is changed, or how the electronic a drastic change in mindset. Rather than following the commerce purchasing experience is shaped, or how next hype into believing software development “can be facilities for controlling the chemical plant are set. made easy”, a true discipline must emerge in which it is The community must develop the languages, tech- recognized that design is a critical activity that involves niques, and tools for enabling the multitude of stake- serious and difficult work. And herein may lay the most holders in an application design to sketch, evaluate, difficult barrier of them all. revise, and refine design concepts for applications. Success will be achieved when clients are able, through 6. Challenges and Vision working with the design team, to see their tasks in new ways and are able to innovate new ways of meeting Design and architecture as described comprises a those tasks. broad field and arguably sits at the very core of soft- ware engineering. All of its aspects are vital: ways of Community Challenges designing, architectural representations, means for per- forming analysis, techniques for transitioning a design Achieving the technical vision will require long- into an implementation, ways of capturing design ex- term financial support, new venues for publication and perience, and so on. Absence of progress in any one of community analysis of designs and design technology, the areas discussed impedes progress in the others. a new sense of who the design community comprises, Thus, broadly based advancement on the whole set of and, perhaps, some “incentives”. sub-topics constitutes a grand challenge for software The critical enabler for progress is, of course, ade- engineering – an appropriate, critical focus for software quate funding. The centrality of design and architecture engineering research. We conclude, therefore, not with to software development demands that significant, sta- a specific design problem as a grand challenge for the ble funding be directed to these activities. The National field, but rather repeat and highlight a few technical Science Foundation’s Science of Design program is a items, providing a bit of a vision for the future, offer good start in this direction, but support for design re- some directions for community activities, and finish search should not be limited to the NSF; other agencies with a speculation on the long future of “software” de- should make this field a priority as well. Such support sign. should also be continuing. Design will not be “solved” after three years of work; indeed, as we have argued, Technical Challenges design will always be a challenge – our aspirations will not abate. Designing a software application involves designing Software design and architecture research also needs its structure as well as its user-observable properties, adequate forums for the presentation and review of functional and non-functional alike. By removing the research advances. Drawing from the study of design in counterproductive boundary between requirements and other fields, forums are also needed for the public pres- design, a holistic view of product conception emerges. entation and review of designs themselves. Such review By analogy to building architecture, a building can be can inspire other designers, reveal properties of new seen as being composed of beams, bricks, pipes, glass, design techniques and tools, and add to the repertoire and wires, but also being composed of living spaces, of design experience. Design research often does not galleries, sun rooms, and cooking facilities. Building have the same character as research in other fields, architects can show clients cut-away views of build- such as software testing and analysis. Hence traditional ings, simultaneously revealing both structure and facil- forums and criteria are unlikely to be adequate or ap- ity, the interrelationships between natural light and propriate for review of design advances. New forums for the discussion of software design trast, have always dealt with an intangible product: would also be supportive of expanding the community software; we are accustomed to designing, modeling, of contributors. As software design is recognized as and assessing a broader set of realities. engaging teams of designers with expertise spanning If we therefore extrapolate the concept of “soft- specific application domains, business planners, and ware” beyond the traditional confines of the computer software specialists, a forum in which all would feel “at to encompass radically different intangible products, home” would be productive. such as this example automotive interaction, an excit- Lastly, there is nothing like an incentive to spark ing frontier opens up. Software designers may be able quick advances in a field. Building architects are annu- to lead the way into conceptualizing, modeling, and ally awarded the Pritzker Prize, an award that carries building new kinds of intangible products. Working not only international fame but a $100,000 reward. In cooperatively with designers from other specialties, the fact, design awards are common in many fields: auto- prospect is for creating new kinds of highly complex motive design, industrial design, fashion design, and so systems that are now barely imaginable. on. Why not spark innovation in software design by Software design and architecture have a long future creation of a corresponding prize? A similar kind of ahead of it. inducement for advancement is a challenge prize, such as the Ansari X-Prize was for space flight. Establishing 7. Acknowledgments appropriate criteria and processes for evaluating soft- ware designs would be a challenge, but the effect on This work was supported in part by the National the community could be significant. For instance, the Science Foundation, under grants 0438996 and evaluation could cover the process by which the design 0536203. was produced, as well as design itself. We would like to thank Alex Baker, Eric Dashofy, Peter Freeman, Michael Gorlick, Neno Medvidovic, A Vision For The Long Future Peyman Oreizy, David Redmiles, Lee Osterweil, and Alexander Wolf for ongoing collaborations and fruitful One of the themes of this article has been that soft- discussions that have fueled the opinions expressed in ware design and architecture has been, and will remain, this paper. an intellectual challenge: as our abilities to effectively design for one set of challenges become more effective, 8. References a new set of design challenges emerge to demand yet further advances. The limit on this cycle is simply the [1] Design Research Society. definition of “software”. By expanding our sense of