See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/4250871

Software Design and Architecture The once and future focus of software
engineering

Conference Paper · June 2007

DOI: 10.1109/FOSE.2007.21 · Source: IEEE Xplore

CITATIONS READS
74 1,558

2 authors, including:

Andre van der Hoek

University of California, Irvine
223 PUBLICATIONS 6,274 CITATIONS

SEE PROFILE

All content following this page was uploaded by Andre van der Hoek on 06 February 2016.

The user has requested enhancement of the downloaded file.

 Software Design and Architecture
The once and future focus of software engineering
Richard N. Taylor and André van der Hoek

Richard N. Taylor is a Professor of Information and Computer

Sciences at the University of California, Irvine. He received the Ph.D.
degree in Computer Science in 1980. His research interests are
centered on software architectures, especially event-based and peer-
to-peer systems and the way they scale across organizational
boundaries and decentralized applications. Professor Taylor is the
Director of the Institute for Software Research, has served as
chairman of SIGSOFT, chairman of the ICSE Steering Committee,
and was general chair of FSE 2004. Taylor was a 1985 recipient of a
Presidential Young Investigator Award. In 1998 he was recognized
as an ACM Fellow and in 2005 was awarded the ACM SIGSOFT
Distinguished Service Award.

André van der Hoek is an associate professor in the Department of

Informatics at the University of California, Irvine. He holds a joint B.S.
and M.S. degree in Business-Oriented Computer Science from the
Erasmus University Rotterdam, the Netherlands, and a Ph.D. degree
in Computer Science from the University of Colorado at Boulder. His
research focuses on understanding and advancing the role of design,
coordination, and education in software engineering. André is the
principal designer of the new B.S. in Informatics at UC Irvine and was
honored, in 2005, as UC Irvine Professor of the Year.
 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 sign over the past forty years and more. Fred Brooks
included in his 1975 list of “promising attacks on the
The design of software has been a focus of soft- conceptual essence” the growing of great designers
ware engineering research since the field’s beginning. [21]. Peter Freeman, in 1976 [31], said “Design is
This paper explores key aspects of this research focus relevant to all software engineering activities and is the
and shows why design will remain a principal focus. central integrating activity that ties the others to-
The intrinsic elements of software design, both proc- gether.”
ess and product, are discussed: concept formation, use Design will remain the focus of software engineer-
of experience, and means for representation, reason- ing. Herb Simon, in his classic, The Sciences of the
ing, and directing the design activity. Design is pre- Artificial [75], includes a discussion of design in the
sented as being an activity engaged by a wide range of context of “artificial” fields, such as software develop-
stakeholders, acting throughout most of a system’s ment, saying:
lifecycle, making a set of key choices which constitute “The artificial world is centered precisely on this
the application’s architecture. Directions for design interface between the inner [the means] and outer
research are outlined, including: (a) drawing lessons, [the task] environments; it is concerned with at-
inspiration, and techniques from design fields outside taining goals by adapting the former to the latter.
of computer science, (b) emphasizing the design of The proper study of those who are concerned with
application “character” (functionality and style) as the artificial is the way in which that adaptation of
well as the application’s structure, and (c) expanding means to environments is brought about – and
the notion of software to encompass the design of central to that is the process of design itself.”
additional kinds of intangible complex artifacts.
Put in software engineering parlance, the outer envi-
ronment is the world of requirements, goals, and
1. Introduction wants; the inner environment is the set of software
languages, components, and tools we have for building
Design is the central focus of software engineering.
systems. As software engineering researchers, we are
Design is both a verb and a noun. It is a key thing we
always “raising the floor” – creating new levels of in-
do and that we produce.
frastructure upon which new developments may be
Such crisp statements will alternatively strike one
built. In Simon’s terms, the “inner environment” or
as obvious or, perhaps, as parochial – if not incorrect.
the “means” is ever changing and expanding. As the
Yet if we consider what software engineering is,
floor rises, however, so do our desires and aspirations.
namely a practice directed at the production of software
Though achievements in improving design have been
systems, then design is seen at its heart, as it is in any
obtained over the previous decades, new challenges for
other productive enterprise, whether the creation of
design will thus continuously arise.
skyscrapers, automobiles, toasters, or urban regions.
Not surprisingly, then, many software engineering
researchers, or those acquainted with software devel-
opment, have studied and written about software de-
 sign research of the first type is directed at the me-
chanical organization and structure of the vehicle; de-
Goals and Dreams sign research of the second type is directed at shaping
the car’s appearance, performance, sound, and smell.
"The Task"
Doing a good job of one type of design does not im-
ply doing a good job with the other, yet they are in-
DESIGN trinsically interrelated. Both are important, and are
legitimately the subject of (software) design research.
Work on design of the first type has certainly
"The Means" yielded a wide range of important results over the past
several decades. Numerous development methods have
Materials, Tools, and Mechanisms
been espoused, many based upon the articulation and
application of design “principles” such as modularity
and planning for change. Means for representing de-
Figure 1. The continuing place of design. signs have been devised; domain-specific approaches
have been created and supporting tools supplied. In
Nonetheless, at a suitably abstract level the chal- recent years, particular advances have been made with
lenges for software design today are the same as they regard to product families and the careful specification
were forty years ago. They are the intrinsic challenges of system architectures.
of design: How to create artifacts to obtain goals, how Work on design of the second type has often been
to represent new conceptions, and how to analyze ignored by software engineering researchers, and in-
them. Brooks made this observation twenty years after stead relegated to either other sub-disciplines of com-
the original Mythical Man-Month was published. He puter science, especially human-computer interaction
said the distinctive concerns of software engineering researchers, or simply left to practicing engineers in
now are exactly those he set out earlier, namely “How industry.
to design and build a set of programs into a system; Design of both types is increasingly recognized as a
How to design and build a program or a system into a critical corporate and national asset. Designing of
robust, tested, documented, supported product; How to products is seen as an activity that cannot be effec-
maintain intellectual control over complexity in large tively off-shored – regardless of the shore on which
doses.” [20] (pg. 288). Ten years after that statement it one is standing. Design can be a differentiator that
is still true. determines an organization’s success. The ability to
Arguably all the major threads of software engineer- design effectively is typically the partner of the ability
ing research are directed at improving our ability to to innovate.
meet the challenges of designing software. Work in The remainder of this paper seeks to explore how
requirements engineering contributes to Simon’s “outer and where to advance from the state-of-the art. We pro-
environment”; process research addresses the coordina- ceed by first examining some major historical threads
tion of all activities focused on creating, implement- of design research, then highlighting a few notable
ing, and evolving designs; empirical studies improve current trends. These sections are not merely back-
our ability to assess design artifacts and the processes ground; by straightforward implication from what we
by which they were created; analysis research improves describe, some key directions for software research
our ability to assess candidate designs; work at the emerge. Drawing from the perspectives of these two
patterns and frameworks level improves our ability to sections, we then examine the character of design in
realize designs in source code; and so on. more detail. The remainder of the paper explicitly lays
Though a focus on design has been, and will be, out a set of further research directions, and concludes
the central issue in software engineering, the type of with some challenges and a “long view” of the promis-
design on which our energies have been focused has ing future of software design.
been rather lopsided. Our focus has largely been di-
rected at the design of software qua software. That is,
we focus on the structure of software and its attributes,
2. Paradigms and Persuasions
such as considering what components and connectors
The past forty plus years of design research can be
comprise a system, and what constraints govern their
taxonomized many ways, such as by describing the
interactions. A lesser role in software engineering has
history of models, methods, and tools over time.
been assigned to the design of software as it exhibits
These topics are not independent, however. Rather, the
characteristics to its users. For instance, what “interac-
background or disciplinary orientation of an individual
tive feel” does the application give to its users? What
or group tends to bring along a set of beliefs, choices,
“style” does it exhibit? What is its branding, or dis-
and approaches. Any such perspective, then, drives
tinctive behavioral character? Using the analogy of
specific choices in a variety of areas.
automotive design can make the distinction clear: de-
Prescriptive Design Methods host of profiles publicly available that address a broad
variety of modeling concerns.
Perhaps most familiar to the software engineering
researcher is the perspective of the “software method- The Wisdom of Experience
ologist”. Typified best, perhaps, by work in the 1970’s
and 80’s by such authors as Yourdon [81, 82], Jackson Still focusing on the design of software, but com-
[41, 43], and Parnas [61-65], this strand of work fo- ing at the problem from essentially a bottom-up per-
cuses on the first type of design discussed above, the spective, is a strand of work focused on capturing the
design of software as the artifact of interest, and is an lessons of experience in such a way that future designs
approach that states a principle, then prescribes how to can be guided. The work on “design patterns” is typi-
design based on that principle. cal of this strand. While the “Gang of Four” patterns
Much of this work has been top-down in style; [33] are directed at the programming language level,
principles of design are articulated (“separate abstrac- the concept can be applied at any level of abstraction,
tions”, “use information hiding”, “refine higher-level including requirements (where the experience may be
abstractions into a set of lower-level abstractions”, etc.) captured as “frames” [42]), whole-concept system struc-
and then either methods for employing those principles ture (where the experience is captured as domain-
or notations which highlight or support application of specific software architectures [10, 38, 79]), and gener-
the principles are developed. ally at the level of system components and connectors
One influential strand of work began with Russ (where the experience is captured as styles and architec-
Abbott [8], and was then expanded upon and advocated tural templates [9, 34]).
by authors such as Grady Booch [17]. This design Methods for analysis and restructuring of software
approach is, roughly, “design by simulation”, in which may reflect insights from this research strand, such as
the software application is straightforwardly designed are found in refactoring analysis and reverse engineer-
by creating software objects that correspond to entities ing.
in the real world, and whose methods correspond to Knowledge representation and design rationale re-
actions in the real world. The work contributed to ob- search may contribute to the effective employment of
ject-oriented design, and became in a broader context design based upon the wisdom of experience.
to be supported by methods such as the Rational Uni-
fied Process [51], with designs represented in the Uni- HCI Design
fied Modeling Language (UML) [52].
Innovation in product design and distinctiveness in
Notations product design have long been argued as contributing
to product (and corporate) success [45] – though such
Notations have been a part of software design since innovation is no guarantee of commercial success. The
the beginning. Any time design thought is external- software engineering literature is relatively silent on
ized, such thought must be written down in some the matter of such design, possibly because researchers
structure or form that supports interpretation at a later view the subject as too domain-dependent, and hence
time by others, oneself, or a computerized program. It exclusively the focus of developers within that do-
is no surprise, then, that notations continue to serve as main. Even if one assumes that, it is surprising that
a primary driver of research in the community. software researchers have not focused on the methods
Notations range from informal conventions that are by which innovative domain-specific designs are cre-
established on-the-fly by a group of designers engaged ated.
in a design exercise to precise formalisms that are The exception is user interface design. Often rele-
standards for the field. Two primary concerns in the gated to (at best) the fringes of software engineering
formulation of new notations are expressiveness and research, human-computer interaction research includes
usability. Expressiveness concerns what aspects of a a focus on techniques for developing user interfaces
design can be captured in the notation; usability con- which effectively engage and satisfy the user. Some
cerns the fluidity with which designers can work with lessons of such work are captured, for instance, in pat-
the notation. Though both factors are equally impor- terns for web site design, as found in the work of Lan-
tant, the primary driving force behind the development day and colleagues [80]. This work is partially bottom-
of most new notations has been expressiveness – add- up, in the manner described above, but also reflects
ing modeling capabilities, often for a particular analy- cognitive understandings of how people interact with
sis purpose. web sites and undertake electronic commerce transac-
Extensibility is a required property of any modern tions.
notation, as it is now common knowledge that no The importance of considering this field is indi-
standard notation can fulfill all modeling needs. UML cated, in no small measure, by the repeated failure,
profiles are perhaps best known in this regard, with a over many years, of standard software engineering top-
down design techniques to create pleasing and effective and conversation – all aspects that must be taken into
user interfaces. account.

Design Outside of Software 3. Contemporary Currents

The field of design, and design research, outside of Contemporary currents in design sometimes add
software engineering and computer science is enor- important perspectives to the schools of thought de-
mous. While both types of design discussed above are scribed above, as well as combine, apply, and refine
within this wider world’s view, a greater emphasis is 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 test-driven development makes the design of function-
“agile design” draws from some of its key elements . ality of equal importance to the design of system struc-
Less directly, the capabilities of CAD systems like ture, which represents a rudimentary integration of the
CATIA have been an inspiration throughout. two types of design we discussed in the Introduction.
A further perspective on design exhibited by the Lastly, implicit in the agile approach is that the
larger design world, but which software engineering process of design continues throughout development.
has mostly ignored (or scorned) is that of design as art. With little extrapolation, design can be seen to con-
While Donald Knuth unabashedly titled his monumen- tinue throughout the life of the product – a characteris-
tal series, “The Art of Computer Programming” (e.g., tic not shared with many products from the realm of
[46]) and promoted “literate programming” [47], we physical 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 recog- The original aspect-oriented programming paper
1
nition of excellence in design . states “A design process and a programming language
work well together when the programming language
Cognitive and Social Strategies provides abstraction and composition mechanisms that
cleanly support the kinds of units the design process
A final strand of design research is exemplified by breaks the system into.” It then makes the argument
the work of Donald Schön [72], and found in software that programming languages must conceptually distin-
engineering in the work of, for example, Fischer. A guish components (units of a system’s functional de-
key perspective emerging from this work is what composition) from aspects (system properties that can-
Schön terms reflection: the designer reflects upon the not be cleanly separated and instead crosscut compo-
process and upon the product. Design in this view nents) [54]. This view of AOP strikes an important
emerges as a “conversation” between the materials (the chord with design, as separation of concerns is one of
external constraints on the design, the initial sketches the leading approaches to tackling a design problem’s
attempting to develop a solution) and the designer. complexity. Unfortunately, this design-oriented per-
Design, however, is not a solitary activity. Teams spective seems to have given way to AOP language
of designers interact, varied stakeholders participate, minutiae and a focus on “aspectizing” any and all
and broader communities of practice [29] exist within software artifact. Nonetheless, the critical role of the
which individual designers perform their work. De- programming language in the design process persists,
sign, thus, is a social process, one of information ex- and AOP has and continues to have an impact as such.
change, learning, creative and cognitive stimulation,
Design Analysis
1
The ACM Software Systems Award is an excep- One of the reasons we design is to reduce risk by
tion, though it is not widely promoted – certainly not enabling prediction of system properties. Not surpris-
in the software engineering community.
ingly, the field has devised numerous ways of perform- specificity to the historic field of software design. Ar-
ing design-based analyses. Many of these have been guably, software architecture has been focused on the
described, for example, in the SAVCBS workshop maturation and professionalization of a field previously
series (Specification and Verification of Component- best characterized as craftsman-like.
Based Systems). Most of these analyses concern exter- The successes achieved by software architecture over
nally visible properties, such as reliability, real-time the past fifteen years span from commercial use of
constraints, or concurrency, although a fair amount of product-line architectures, such as at Philips [59], to
work also concentrates on properties internal to a de- the architectural underpinnings of the World Wide
sign, such as structural quality or reusability [71]. Web, as characterized by the REST style [27].
Different design representations are suited to differ- Architecture is a backdrop for much of the direc-
ent kinds of analyses; new analyses may require new tions for software design that we characterize in the
notations to be used. remainder of the paper; its importance is reflected by
its inclusion in this paper’s title.
Component-Based Design
4. Design, Designing, and Designers
A desire to structure large-scale business applica-
tions in terms of standard, reusable components con- The careful reader will notice that we have, so far,
tinues to drive a non-trivial part of the industrial soft- refrained from defining software design, or even design
ware landscape. While each guarantees somewhat dif- itself. So it is with the contributions discussed in Sec-
ferent properties as emphasized by somewhat different tions 2 and 3, which by and large typify design accord-
usage scenarios, component-based design, model- ing to a certain perspective (e.g., a phase, in the code,
driven architecture, and web services all can be grouped art, engineering) and then work within this perspective
as addressing this desire in a similar manner. In fact, to make their contributions.
they can be seen as evolving from one another, with To understand how these perspectives relate and to-
component-based design focusing on reuse of the indi- gether help or hinder in advancing the field as a whole,
vidual component, model-driven architecture on stan- it is critical that the field establishes a common basis
dardization of components into reusable middleware from which its progress can be judged. The following
[30, 40], and web services on reuse of components and summarizes a general model of design that is intended
middleware across distributed and decentralized appli- to form such a basis [13]. The model consists of two
cations. interrelated parts: one part capturing the essence of
Of course, different components do not magically design-the-product, the other part capturing the essence
fit together. A particular challenge is to design the of design-the-process.
“glue” that bridges mismatches in functionality, inter- When used as a noun, design normally indicates the
faces, and interaction paradigms. artifact (product) that emerges from the design process,
some physical document or other kind of representa-
Software Architecture tion that articulates the intent of the designer. This
product results from the choices the designer made,
The many strands of work in software design de- choices that form an abstraction of that what is eventu-
scribed thus far have most fruitfully blended and ma- ally desired to be realized in the real world [49].
tured into the field of software architecture. With an These words are in some ways obvious, but in
encompassing definition of software architecture as other ways not sufficiently precise to help guide a
“the set of principal design decisions governing a sys- field. The general design literature has made various
tem”[78], it engages the full range of design activities characterizations that can be used as such (e.g., Simon
and includes the full range of participants in the design [74], Norman [58], Schön [72]). Figure 2 presents a
process. Software architecture encompasses work in visual of the amalgamate of these characterizations as
modeling and representation, design methods, analy- they pertain to the design product. The figure distin-
sis, visualization, supporting the realization of designs guishes the design space from the outcome space. Dur-
into code, experience capture and reuse, product lines, ing design, we mentally operate in the design space
deployment and mobility, security, adaptation, and so (where each point represents a unique set of design
on. decisions), but continuously make decisions that re-
Software architecture research began in earnest in flect upon the outcome space (where each point repre-
the early 1990’s (e.g. [66, 73]), though the term is sents a unique artifact). That is, each design decision
decades older (it is found, for instance, in many works alters the set of outcomes that are still possible (SP),
from the early 70’s). Work in the 90’s was initially cutting away some and re-enabling others. A design,
focused largely on matters of design representation then, is a point in the design space that represents a
[56], though the whole movement could be character-
ized by a desire to provide substance, structure, and
set of decisions that together delineate a set of possi-
ble 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
process. Another set of constraints is exercised by the
available materials from which an outcome is con-
structed by following a design’s blueprint: a design
should describe only outcomes that are feasible (F). A Figure 3. Design – The Process.
successful design 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 individ-
ual perspective on software design. Rather, it supports
the field in giving it the ability to precisely relate dif-
ferent 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
supporting its designers. Particularly, it can:
• Improve the materials from which a product that
is envisioned by a (finalized) design is eventually
Figure 2. Design – The Product. incarnated in the real world. For example, the
availability of newer, lighter composites enabled
When used as a verb, design normally indicates the different kinds of planes exhibiting different
process by which a design is achieved. It is understood weight and aerodynamic properties to be designed.
to be a human-centered process, involving varied • Improve the languages that are used for capturing
stakeholders. It is also understood to be strongly goal- goals, ideas, and knowledge. Alexander’s design
driven and drawing upon established knowledge of the patterns are an example of such an advance, bring-
designer and the field at large. ing together goals and ideas in a single representa-
The general design literature has made precise char- tion that furthermore supports easy adoption.
acterizations of this process, which are brought to- • Improve the general knowledge the community has
gether in Figure 3. The design process is one of infor- about its design domain and design processes. For
mation manipulation (broadly construed to encompass instance, the human genome project is of tremen-
initial creation, transformation, and deletion), with dous value to the design of new medicines, pro-
four types of information involved: goals, ideas, and viding a data bank of knowledge that previously
knowledge, which are all mental, and representations, was unattainable.
which are physical expressions of mental information. • Improve the portfolio of activities that are used in
Each of these types of information is phrased in one or the design process. IDEO’s focused form of brain-
more languages, and tools may be used to edit and/or storming is an example of an activity that led to
interpret representations. Within this setting, designers improved results, both in terms of time and out-
engage in one or more activities, through which they – of-the-box solutions [45].
directly and indirectly – explore the design space. The • Improve the tools with which design activities are
design process, then, is defined as the set of informa- supported, particularly in creating and interpreting
tion manipulation activities through which a success- representations. For example, the automotive in-
ful design is obtained. dustry has made significant leaps in their ability
to design by moving from clay models to
CAD/CAM designed 3D visualizations.
All progress, whether in the form of a new methodol-
2
ogy, notation, metric, or analysis algorithm, to name a
This discussion is not meant to imply the exis- few, will eventually reduce to these five basic underly-
tence of a separate design phase. The spaces we refer to ing categories.
are ephemeral and largely present as a result of the way
in which human’s think – through abstraction.
The Community of Designers experts and business stakeholders are properly con-
tributors to a system’s architecture. Domain experts
Just as it is important to understand the fundamen- naturally know or determine the key abstractions for a
tal elements of design, so it is important to recognize system, acceptable strategies for meeting regulatory
the richness of the community of designers – those requirements, or provide vital insights on what parts
who design, who contribute to the design, and who and in what ways the design must be flexible to ac-
must interact with design representations, designers, commodate potential future changes. Business-focused
and design processes. Historically, design has largely stakeholders may determine key boundaries for a prod-
been seen as a somewhat provincial task performed by uct-line architecture, and hence determine critical soft-
a small number of software specialists – perhaps one ware interfaces. Design, thus, is not the exclusive
“chief designer” – during a circumscribed period in a province of the software technologist; the multiple and
project’s lifecycle, namely following requirements proper contributions from the wide community of
analysis and preceding any implementation. Clearly, stakeholders must be accommodated. This final com-
such a simplistic notion is either counter to what really ment is not easy to achieve, however. Separate
happens in a project, or if actually followed yields sub- stakeholders likely require (or at least request) views
par results. In truth, the number and types of individu- onto an emerging design which are idiosyncratic to
als with vital interests in a project’s design represents a their perspectives. Supporting multiple viewpoints
broad community of interest [29]. Existence of this while ensuring consistency among them constitutes a
community imposes some particular demands on de- current challenge towards which the community has
sign; recognition of the breadth of the community made progress (e.g., the 4+1 model [50], analyses to
highlights opportunities for improving our practice and discover inconsistencies [26], and an understanding
expanding our research agenda. that certain forms of inconsistency must be tolerated
First, for a project of any significant size, more [15, 28]), but for which much work remains to be
than one designer will be involved. Existence of mul- done.
tiple designers thus imposes demands for communica- Fourth, arguably the design community increas-
tion of design concepts [21]. Communication implies ingly includes the end user. Common applications
shared representations, an observation that is a natural such as spreadsheets and word processors actively in-
outflow from the general model of design. The effec- vite the end user to customize – i.e., design – their
tiveness of such communication is determined by the working environment and the complex artifacts pro-
language(s) used [22]. Presence of a design team also duced with desktop tools. At best the software engi-
induces requirements for coordination of its design neering community has barely recognized this commu-
activities. Such coordination could involve formal nity of designers; after all, they are not software spe-
management if the task is large enough. cialists, have little or no formal training in design, and
Second, however the design is produced, other in- produce designs researchers may dismiss as trivial, or
dividuals, playing other roles, are critically engaged simply as poorly done. But the enormous number of
with the design. They must be able to understand and end users, the substantial ability for customization and
use it. In traditional development practices wherein the design presented by desktop applications, and the po-
implementation activity is separate from the design tential for improving the quality of end user designs
(more about this below), the implementers must be argues strongly for design researchers to turn their at-
able to comprehend and utilize the design. The practi- tention to this special world. As one example, space-
cal challenges of this become highlighted should such craft systems designers use complex, interlocking Ex-
implementation be contracted to another firm, perhaps cel spreadsheets to design new systems and missions
to one on another continent. In other situations, the [55]. These complex spreadsheets are designed, how-
customer may be desirous of participating in substan- ever, without any higher level of abstraction or repre-
tive review of a design. In yet other situations end sentation; understanding them and “verifying” them is
users may be participants in the design process. All of left to the engineer, who must interpret the macros
these engagements with design highlight the critical pervading the spreadsheets. A better way is surely pos-
role of and demands on shared representations of de- sible.
sign.
Third, beyond just recognizing the existence of a 5. Research Directions
multiplicity of designers and “design readers”, we also
must recognize that the multiple stakeholders of a sys- The introductory section of this paper indicated
tem (can) all contribute to the design itself. The typical how design will remain an enduring challenge. As our
perspective has been that, since software is being de- ability to design solutions to current statements of
signed, software specialists are the only ones who wants and needs improves and becomes more predict-
properly determine the software’s design. As discussed able, our conception of what might be achieved ex-
in detail in [57], however, both application domain pands. As “the means” improves and rises, “the task”
becomes more adventuresome and demanding. Our rote translation of design to code, sometimes to the
ability to design must be correspondingly enhanced to point where a design intentionally does not make a
make use of the improved materials, tools, and mecha- choice of programming language so to be general in
nisms to create solutions to the new goals and dreams. nature. Key choices made in and about the implemen-
Seen in this general light, all the elements of design tation process, such as the decision to use a particular
research listed in Section 4 above will persist; it is a implementation framework or programming language,
matter of understanding and improving: are important parts of system design, affecting future
strategies for system modification and adaptation. The
• the materials – the conceptual building blocks –
importance of such design should not be overlooked.
from which designs are eventually realized as arti-
The challenge for design researchers is to provide prac-
facts in the real world.
tical guidance to those involved in setting system re-
• the languages that are used for capturing goals,
quirements, in coding the system, and indeed in all
ideas, and knowledge.
other aspects of system development for their appropri-
• the general knowledge the community has about
ate participation in design. More generally, the ques-
its design domain and design processes.
tion is how to structure software development proc-
• the portfolio of activities that are used in the de-
esses to support a robust, modern conception of de-
sign process.
sign.
• the tools with which design activities are sup-
Third is the matter of choice and evaluation [32,
ported.
74]. As designers confront issues, a set of choices
While comprehensive, this list is too generic to be emerge. Beyond recognizing and recording the choices
of much use in setting directions; the remainder of this made, designers need support for evaluating alternative
section is devoted to discussing a variety of more spe- choices so to guide them towards a design’s objec-
cific directions. Before moving to the more specific tives. Analysis techniques may focus on functional or
discussion however, we consider three general issues. non-functional system properties, and may span to
First is the matter of design decisions. Designing is analysis based on economic arguments [12, 77]. While
fundamentally a matter of making choices – how to development of individual techniques continues to be
accomplish something, how to represent something. needed, the field also should find ways in which such
That suggests that an effective approach to design techniques can be combined to enable multiple proper-
should offer a solid understanding of choices: what ties to be jointly assessed, in the manner of statistical
they are, recognizing when they are made, what the decision theory for example, to enable broadly in-
alternatives were, and capturing them in such a manner formed choices to be made.
as to allow retrospection. In typical practice we are far
from having a grasp on this: decisions are often im- Directions Reflecting Good Recent Pro-
plicitly made. It is not until later that we recognize gress
that certain functionalities or properties were precluded,
or inhibited, by an early choice. Decision support sys- In defining a research agenda, it is important to rec-
tems from the 1980’s, such as gIbis [23], offered ex- ognize those research directions that “work”, have had
plicit support for formally considering choices facing a impact already, and should be explored further because
group. This type of support is needed, but must be they continue to have promise in advancing the field.
provided in a lightweight manner that is integral to The first direction we discuss as such is software
and supportive of design. Perhaps more important, architecture. It is interesting to put architecture in light
however, would be practices to aid in recognizing of the five directions of design research presented in
when choices are being made. Section 4. To date, advances have included, among
Second is the matter of the place of design in the others, architectural middleware, description languages,
software engineering process. As the discussion in the styles, design methods, and environments, which col-
previous section indicated, the activity of design is not lectively cover the five research dimensions along
limited to one individual or one circumscribed place in which progress can be made. That is, architecture has
the development process. Critical decisions – design turned out to be a natural fit in pushing design research
decisions – are made throughout system development forward.
by a variety of stakeholders. Talk of “requirements Of particular importance is the focus on early de-
engineering” that is wholly independent of design, for sign decisions. Architecture, though it can be mapped
instance, is frequently either sophistry or simply onto code effectively, is initially about supporting the
counter-productive. As critical decisions about a sys- exploratory process. Architectural styles are critical in
tem are made – whenever they are made – design is this regard, documenting accepted solution strategies
being done, the architecture is being established and as sets of reusable design decisions that can be readily
should be recognized as such. Similarly, implementa- adopted. Clearly-documented and well-packaged styles
tion is improperly and unrealistically considered the
come closest to the original definition of architecture As important as the externally-visible qualities of a
as “structure, form, and rationale” [66]. design are its internal qualities: is its structure sound,
Architecture has also strongly influenced software is it optimal, and will it hold up over time? A recent
product lines. The vast majority of software product trend has seen attempts to assign “value” to designs,
lines are actually realized through product line architec- particularly by employing economic analyses that stem
tures, which are used to distinguish those parts of the from adapting and applying established economic the-
system that are shared among all products and those ory to the domain of software design. Most promising
parts that are variable and depend on the product at to date is the use of Design Structure Matrices [14];
hand [70]. The use of product lines has become suc- with them, it is possible to visually compare different
cessful with several success stories emerging that detail modularizations, assign these modularizations values,
how this kind of domain-driven approach can be bene- and in so doing understand design tradeoffs, such as
ficial and provide a competitive advantage. whether to refactor or to apply aspects. These results,
That said, there is significant work left to do. De- however, represent only a beginning. Values are as-
sign involves multiple stakeholders who may have signed mostly to entire designs, not necessarily indi-
radically different concerns. Having focused strongly vidual design decisions (though these can be valued in
on component-connector centric approaches, current the context of given design changes). Values also are
architectural description languages lack facilities for “instant”, for the design as it is now; not how they
specifying and relating such diverse sets of concerns. stand up against future design changes. A critical di-
Extensible architecture description languages are a mension of future work, then, is to find mechanisms
foundation, but their modeling capabilities must be of valuing individual design decisions over time.
supported with flexible environments and design proc- Another important aspect of this work lies in the
esses. historical lessons it can teach. Applying Design Struc-
This strongly relates to the need to manage evolv- ture Matrices to numerous designs, both good and bad,
ing architectures. When stakeholders make changes, it can build a portfolio of examples from which it fur-
is often the case that the architecture degenerates. Espe- thermore may be possible to deduce general principles.
cially with product line architectures, it is known that Finally, we return to the topic of architectural styles
even a pungently cohesive initial definition slowly but and, more generally, the capture and reuse of architec-
surely may morph into a set of disjoint product archi- tural experience. Experience and "good design practice"
tectures. Processes have been employed to ameliorate can be captured at different levels of abstraction (from
this problem, but overall our level of understanding is source code up to the highest level of system structure)
still limited and our tool support for carrying out such and with different degrees of generality (from useful
processes trails significantly. within all application domains to useful only within
Throughout the design process, whether it is a highly specialized application domains). We need the
high-level architecture or a low-level UML class dia- ability to capture the lessons from prior developments
gram, it is generally important to ensure that certain at all points in this space, and to do so in a manner
properties are met, such as, for instance, behavioral that effectively enables other engineers to find, under-
consistency, real-time performance constraints, reliabil- stand, assess, and apply the lessons to the develop-
ity, levels of security, and concurrency behavior. The ment of new systems. In simplest terms this could
analysis community has made steady progress in pro- involve developing extensive catalogues of architec-
viding analyses that can provide such guarantees and tural styles. The richness and variety of experience
continues to work on faster and more efficient analy- demands better ways of capturing, finding, and using
ses, analyses for new properties, and general infrastruc- knowledge, however. Other design disciplines have
tures[16, 24]. matured by doing so, it is time we do so as well.
A particular challenge is to make these analyses,
and the modeling of the information that is needed to Directions From New Capabilities
drive them, an integral part of the design process,
rather than some activity that is performed as a “check” Progress in computer science has often been pro-
when the design process has finished. Two problems pelled – or compelled – forward as the result of ad-
persist: the need to create precise representations, and vances in hardware. So it is now with design. Ad-
the need to fully, or almost fully, model a design be- vances in networking, display technology, storage, and
fore it can be analyzed. It is incumbent upon the field processor speed offer the potential for significant ad-
that these two problems are overcome, so that analyses vances in the practice of design.
become usable throughout and especially when it mat- As a first instance, consider the potential of search-
ters most: during rapid generation and evaluation of ing for domain knowledge, prior designs, evaluations
(not necessarily precise or complete) alternatives, for of designs, “similar structures”, and so on, in the
which analyses are vital in understanding the tradeoffs manner of Google. That is, the ability to access infor-
inherent in the design decisions made. mation across the Internet, and especially the ability to
search that information in comprehensive fashion, of- cause of a failure, and hence for eliminating related
fers the potential for exploiting experience from prior latent errors elsewhere in a system.
designs in a manner far beyond anything we have yet Lastly, the continuing rise in processor speeds sug-
seen. A simple use of existing Google-like search will gests that designers, and those who develop design
not be sufficient, however. A designer will seldom be tools, should never be restrained by a perception of
searching, for example, for a module with a specific something “taking too long”. Nor should tool devel-
textual interface. A designer will want to search based opers be distracted into complicated optimizations of,
on various architectural abstractions. Enabling search e.g., analysis procedures, when the use of simple brute
based on architectural meta-data, for instance, is a near- force suffices. If something seems to take too long,
term possibility for meeting this goal. Yet any search just task a few dozen more processors to the problem,
scheme that requires some structured meta-data as in- or simply wait for the next generation of processors to
put stands the risk of being overtaken by a technology appear. The time to develop a reliable optimization
that employs a brute-force strategy that is able to pro- may well exceed the time for a doubling of processor
vide at least as good results without requiring use of speed.
any standard mark-up or meta-data. This, of course, is In summary, let us as designers exploit advances in
the beauty of today’s Google search as applied to computation to advance the practice of design. Our
document searches. One long-term direction, therefore, task is as worthy of innovative use of technologies as
is to develop search algorithms that perform architec- our clients’ tasks are.
tural abstraction automatically, and then “page-rank”
those abstractions against the user’s query, where that Directions From Design Imperatives
query is phrased in terms of architectural properties.
The networking that is a key enabler of Internet For software design and architecture to mature into
search is also a key enabler of improved communica- a robust discipline capable of handling the challenges
tion between individuals and teams. As the legitimate posed by emerging applications, advances in several
role of the many stakeholders in a design process is areas are imperative. Our list here is eclectic, reflecting
recognized, advances in network communications can our perception of particularly poignant needs.
be brought to bear to improve their participation. Col- First is adequate support for moving from architec-
laboration technologies in general offer significant po- ture to implementation, and fluidly moving between
tential for the design process [39]. Communication design and coding tasks. If design does not ultimately
technologies are, relatively-speaking, free; designers support production of a satisfactory implementation
should exploit that. (assuming that the resources and the will to produce
Display technology offers another basis for im- are both present), then it is a failed effort. Many cur-
provement in design practice. Very high resolution, rent design approaches fall silent when it comes to
very large screen displays are now readily available. implementation. Since key design decisions may be
Such displays give designers the potential of seeing made in the implementation context, evolution of the
more of a design from more perspectives simultane- architecture must be seamlessly integrated across the
ously. And why should design be confined to the flat- contexts. Seamless integration implies full traceability
land of 2-D displays? Other scientific disciplines have between code and higher abstractions, and supports
already exploited high-resolution displays; it remains accountability of design decisions.
for software designers to design such support for their Second is the ability to represent all stakeholders
own discipline. Designers should have displays on interests, as discussed earlier. Multiple interests and
their desktops that are at least as large as the televi- multiple perspectives impose demands for assessing or
sions in their homes. Beyond the desktop, there is no guaranteeing consistency of design decisions (or for the
reason why teams do not have specialized design management of inconsistencies between them), as well
rooms equipped with numerous touch-sensitive dis- as demands for multiple presentations of select design
plays and batteries of computers that enable instant data.
analysis. Third, as software applications become ever-more
The continuing decline in the price of storage with interwoven into organizations and society, we must
an accompanying increase in capacity suggests other develop means for the co-design of software and orga-
new directions for design. Why not always record de- nizational/societal systems. Introduction of a technol-
sign rationale – even as video? Keying video/audio ogy into a group or organization may radically change
capture to the designers workstation activities, context, how the group behaves – think, for example, of how e-
and display offers unprecedented potential for retro- mail has altered both personal and public communica-
spectively understanding a design and reusing the in- tion patterns. While a robust literature exists describ-
sights present at the time of design. In the case of de- ing how such organizational changes have occurred as
sign forensics following a system failure, for example, the result of introducing software technologies, we
such storage offers the potential for identifying the root need a design discipline which integrates the inten-
tional shaping of software technology with the inten- ence failures, but the field does not profit from them as
tional shaping of organizations (one easy example is other disciplines do. A “we will just fix it in the code”
the integrated performance of business process reengi- attitude is far too prevalent, and we seem to have been
neering with design of software systems for that busi- lulled into a modus operandus in which the importance
ness). For co-design to take place, a broad range of of design is, consciously and subconsciously, under-
expertise must be woven into the process of design. To valued. Compare the software view of design once
continue without such breadth invites organizational again with that of bridge design. First off, one must
“surprises” and application system failures. appreciate the effort that goes into a bridge’s design.
Fourth is the design of applications as seen and ex- Except for a few systems, our discipline rarely per-
perienced by users. This was discussed in the Introduc- forms this much design. Second, when something fails
tion as the “second type” of design. The need and op- on a bridge, it is the design that is examined, and les-
portunity is profound; further discussion is reserved for sons are drawn from it. Such is not the practice in
the Challenges section. software; we rarely go back, carefully study a “failed
The next two directions are closely related and are design”, deduce lessons as to why the software (use,
motivated, at least in part, by economics. The first of deployment, or even development itself) failed, and
these is supporting design recovery and analysis. Es- what we should do differently, design-wise, next time
tablished systems represent significant economic as- – let alone share these lessons with the community.
sets. To the extent that such assets can be used to meet Any approach to learning from the past must start
new organizational needs, economic efficiencies are with examples. Unfortunately, no software design ex-
realized. Recovering the architecture of existing sys- amples seem to be available. Textbooks contain small-
tems enables assessments of potential future uses to be ish systems. Search the web for “Good Software De-
made so that adaptations can be based on solid archi- sign” or “Bad Software Design Examples” and not a
tectural understandings. While several research projects single system comes forward (though lots of advice on
in this field exist and have yielded promising initial how to create a “good” design comes forward). Com-
results (see, e.g., [18, 36, 37]), there is still much to pare this to building architecture, where one can find
be done. The second and related direction is actively book after book in the bookstore, including books of
managing design evolution – in particular mitigating “great designs”. Clearly, a first challenge for the com-
architectural decay. Here the issue is not recovering a munity is to begin assembling archives of good and
design to merely enable the first steps of progress to a bad design examples. By this we do not just mean
new or improved system, but the task of assessing an UML diagrams, but carefully documented, multi-level
existing design and evaluating alternatives for modify- and multi-view explanations that provide in-depth in-
ing it to meet new and changing needs. Clearly to the sight into underlying design decisions and their rami-
extent the architecture is explicit and faithful to the fications. It is interesting, in this regard, to examine
implementation, this process is facilitated. But that is the HCI literature. In it, one can find numerous papers
only the beginning; an evaluation framework and proc- that introduce novel interfaces and describe their under-
ess to assist in comparing alternative modifications is lying design motivations. Such a practice has not tran-
needed. Such evaluations must not only support exam- sitioned into the software engineering conferences as of
ining how immediate demands can be met, but predict yet.
likely consequences for future, as yet unspecified, de- We must also promote excellence in design. The
mands. SPLC product line hall of fame is an example of such
Lastly, emerging application needs argue for design recognition, as is the aforementioned ACM Software
techniques that yield self-adaptive systems. An impor- Systems Award. In either case, though, we note that
tant topic in its own right, we refer the reader to [48]. regrettably the actual details of the product and design
that received the award are never shared with the
Directions From Examining Our Past broader community. Perhaps ACM or IEEE should
consider establishing an annual prize for the best soft-
We learn from our successes, but we also learn from ware design, requiring that winning designs are placed
3
our mistakes. This is an age-old lesson that has fueled in the public domain.
much progress in other design fields. Bridge design as From examples, we must then deduce patterns,
it is today would not be as advanced without the care- principles, do’s and do not’s, and other general under-
ful study of past structural failures [76]. The study of standings that help individuals in building up a reper-
“why things break” has fueled the creation of newer, toire of knowledge that can assist them in designing.
stronger materials [25]. And a central theme in Pet- Some of that effort is underway; we mention architec-
roski’s well-known writings is how failure has been a tural styles, software patterns and anti-patterns, design
motivator for design innovation [67-69].
How do we perform in software in this regard? Un- 3
fortunately, the answer is “not good”. We do experi- Of course, we can leave our version of the Razzies
(http://www.razzies.com) to an appropriate blog.
critics, bad smell detection and refactoring techniques, to software development, can be read, appreciated, and
HCI design guidelines, and a small handful of general applied by software engineers.
design principles. This work has to continue and be Another practice from architecture is that of a de-
broadened to cover all aspects of the design product sign charette. A charette is related to software’s design
and process. reviews and walkthroughs, but is closer in spirit to
Finally, we observe that we must not just under- agile design, for the purpose of a charette is to move a
stand good and bad design products, but also focus design forward quickly, by developing and critiquing
some of our efforts on understanding good and bad design in a group setting. In educational settings,
design practices. By this we explicitly do not mean charettes are part of design studios, where regular de-
high-level approaches (e.g., Agile), but rather the ap- sign reviews take place. The normal practice of archi-
proaches and techniques that expert designers employ tecture is to develop models suitable for and used in
in designing their software. For instance, it is well- periodic, active, productive, constructive group design
known that product designers may sketch hundreds of reviews.
alternatives before honing in on an eventual choice. Do Perhaps most inspirational from the world of archi-
software design experts follow such an approach? If tectural design is the development of computer-based
not, what do they do that makes them successful? Can building models that enable designers and users (ten-
these skills be explicated and communicated to others? ants, residents) alike to fly through a proposed design,
Overall, the undercurrent of this section is that simultaneously seeing, as desired, both the internal
software design is still far removed from being an es- structure of the building and the appearance and serv-
tablished discipline. To move forward, it is critical the ices of the building. In software design these concepts
field engages in the necessary deep scientific study of are almost always reviewed separately: how the code is
software design and designing. organized is considered almost independently of what
the user’s experience with the application will be. In
Directions From Looking Outside of CS building architecture, the intrinsic relationship between
these two views is understood; if the residents of a
While the design of software is a relatively new ac- house know in advance where load-bearing beams are
tivity, having only been around for sixty years at the they can adjust their expectations for how the building
most, design has been practiced in other fields for cen- might be modified in the future. Seeing how well, or
turies. While sometimes still taught as a craft, or how poorly, the user interface is separated from the rest
learned through apprenticeship, design is newly taking of an application’s code can reveal whether managers
shape as an academic discipline, even as a science. could sensibly direct a desktop application to be retar-
There is a Design Research Society [1] (which spon- geted as a web service.
sors a conference on doctorate research in design), and Architecture even suggests how we might rethink
a wide literature. New university programs in design the composition of our academic teaching faculty. Ar-
are emerging, such as Stanford’s “d-School” [7]. All chitecture schools typically include many practicing
this suggests that there is much that software research- architects, just as music schools include many practic-
ers can consider and draw from in order to advance ing musicians. The conviction is that students can
design specifically within the software field. A few only have an adequate understanding of their discipline
examples have already appeared in the preceding text: through engagement with faculty regularly acquainted
we have referred to work in industrial engineering [44], with the full breadth of disciplinary challenges. One
architecture [11, 19], design processes [72], and could examine many computer science departments and
civil/mechanical engineering. We provide a few addi- find no faculty qualified to construct any application
tional examples here, most of which are inspired by larger than a compiler – a task trivial in comparison
building architecture. with the challenges regularly faced by many profes-
While architecture has already been mentioned, and sionals in industry. Students must also engage in the
has been used for many years as, at least, an analogous practice, and do so repeatedly.
activity to building software, the richness of the build- Many design professions have another practice from
ing architecture discipline suggests that there are still which we could benefit: the study of designs. Design-
further insights to mine. For instance, Parnas’s dictum ers of luxury goods, buildings, machinery, and con-
about designing software for ease of change [63] is sumer goods alike spend significant time assessing –
explored, by analogy, with substantially greater rich- studying – existing designs. The objective is not only
ness in Stewart Brand’s “How Buildings Learn” [19]. to understand how something works, but to assess its
The several layers of a building’s architecture deter- “non-functional properties” – what brand sense it con-
mine the ways in which the building can be adapted to veys, what its aesthetic is, how it affects its user. In
meet new needs. Bottom-up and top-down approaches contrast, most software engineering courses spend no
to such design are considered and extensively illus- time studying existing design, instead plunging ahead
trated. It is a book that, while containing no reference
with green-field approaches, yielding a too-predictable morph to reflect practical needs and considerations
outcome. [60]. So, in a field that is as young as software engi-
neering, perhaps we are not doing so badly?
Barriers To Progress Improvements and overcoming the barriers we men-
tioned, though, will require the community to undergo
Having made a broad set of suggestions, we must a drastic change in mindset. Rather than following the
acknowledge that significant barriers persist to making next hype into believing software development “can be
these kinds of advances a reality in practice. First, as made easy”, a true discipline must emerge in which it
we observed earlier, design is seriously undervalued by is recognized that design is a critical activity that in-
many. On the one hand, we admit that there is some volves serious and difficult work. And herein may lay
basis for such undervaluing: the tools and techniques the most difficult barrier of them all.
available to the average practitioner are not necessarily
very good, especially when put in light of the full 6. Challenges and Vision
spectrum of considerations discussed in Section 4.
This state of affairs makes it difficult to convert the Design and architecture as described comprises a
skeptic or to provide credible evidence that proper de- broad field and arguably sits at the very core of soft-
sign(ing) does make a difference. On the other hand, ware engineering. All of its aspects are vital: ways of
such negative attitude hinders progress: the effort spent designing, architectural representations, means for per-
objecting might be better spent making advances or at forming analysis, techniques for transitioning a design
least encouraging others to do so. into an implementation, ways of capturing design ex-
Second, designers are not necessarily equipped with perience, and so on. Absence of progress in any one of
the right skills and, worse, they may or may not know the areas discussed impedes progress in the others.
whether their skills match up to a project at hand. Who Thus, broadly based advancement on the whole set of
is qualified and how do they acquire their skills? Cer- sub-topics constitutes a grand challenge for software
tainly, some designers are simply great, whether by engineering – an appropriate, critical focus for software
experience or intuition. But a vast majority has to ac- engineering research. We conclude, therefore, not with
quire their skills somehow, yet a culture of apprentice- a specific design problem as a grand challenge for the
ship is virtually non-existent. Granted, not all software field, but rather repeat and highlight a few technical
needs a great designer, but even the “average designer” items, providing a bit of a vision for the future, offer
must learn somehow. some directions for community activities, and finish
Compounding this problem is the remarkable toler- with a speculation on the long future of “software”
ance that software professionals seem to have. If the design.
tools that we use to design are incomplete, inelegant,
and difficult in their use, then how can we be expected Technical Challenges
to produce designs that are complete, elegant, and lead
to easy-to-use systems? And this does not just hold for Designing a software application involves design-
design tools. Poorly designed user interfaces and ing its structure as well as its user-observable proper-
clunky programs abound. Where are we to find our ties, functional and non-functional alike. By removing
inspiration for quality? the counterproductive boundary between requirements
A root cause can be found in the education of soft- and design, a holistic view of product conception
ware engineers [49, 53]. Most stem from a “standard” emerges. By analogy to building architecture, a build-
Computer Science program, which incorporates at best ing can be seen as being composed of beams, bricks,
a few software engineering courses and involves nu- pipes, glass, and wires, but also being composed of
merous other courses which ignore the lessons of soft- living spaces, galleries, sun rooms, and cooking facili-
ware engineering altogether. Extensive practice with ties. Building architects can show clients cut-away
significant software design problems is impossible in views of buildings, simultaneously revealing both
this setting. The past decade has seen the emergence of structure and facility, the interrelationships between
Software Engineering (e.g, [5, 6]) and Informatics natural light and ceiling truss. Imagine now interactive
(e.g., [2-4]) majors. The focus of most such programs cut-aways of buildings, whereby the designer could
is on design, a trend we welcome. Still, the materials move skylights and see the consequences for the roof’s
available from which to teach design are limited and structure, or change specifications on a window and
much innovation is necessary in this regard. note how the quality of interior light improves.
To offer hope, there is the advantage of time. Early Realizing an analogous vision for software design
reports from the SIGSOFT Impact project indicate that requires our supporting the design and visualization of
research advances may take up to ten or sometimes user functionality at least as well as our supporting the
even twenty years from initial idea to widespread prac- design and visualization of software structures. Not
tical use, as the original idea must find traction and only must we see and manipulate components and
connectors in an architecture, but see, as we do so, motive design, industrial design, fashion design, and
how the user’s data display is changed, or how the so on. Why not spark innovation in software design by
electronic commerce purchasing experience is shaped, creation of a corresponding prize? A similar kind of
or how facilities for controlling the chemical plant are inducement for advancement is a challenge prize, such
set. as the Ansari X-Prize was for space flight. Establishing
The community must develop the languages, tech- appropriate criteria and processes for evaluating soft-
niques, and tools for enabling the multitude of ware designs would be a challenge, but the effect on
stakeholders in an application design to sketch, evalu- the community could be significant. For instance, the
ate, revise, and refine design concepts for applications. evaluation could cover the process by which the design
Success will be achieved when clients are able, through was produced, as well as design itself.
working with the design team, to see their tasks in
new ways and are able to innovate new ways of meet- A Vision For The Long Future
ing those tasks.
One of the themes of this article has been that soft-
Community Challenges ware design and architecture has been, and will remain,
an intellectual challenge: as our abilities to effectively
Achieving the technical vision will require long- design for one set of challenges become more effective,
term financial support, new venues for publication and a new set of design challenges emerge to demand yet
community analysis of designs and design technology, further advances. The limit on this cycle is simply the
a new sense of who the design community comprises, definition of “software”. By expanding our sense of
and, perhaps, some “incentives”. what software is, in a very liberal sense, numerous
The critical enabler for progress is, of course, ade- exciting opportunities for contributions from software
quate funding. The centrality of design and architecture design researchers emerge, opportunities for which we,
to software development demands that significant, as software designers, have some distinct advantages
stable funding be directed to these activities. The Na- over designers from many other fields.
tional Science Foundation’s Science of Design pro- Consider, for example, the interaction design prob-
gram is a good start in this direction, but support for lem faced by automotive designers. One could argue
design research should not be limited to the NSF; that what car manufacturers are selling is not sheet
other agencies should make this field a priority as metal and rubber, but a “driving experience”. Such an
well. Such support should also be continuing. Design experience constitutes a structured amalgam of sights,
will not be “solved” after three years of work; indeed, sounds, feelings, and smells. Driving a car involves
as we have argued, design will always be a challenge – interaction with not only the control devices in the car,
our aspirations will not abate. but interaction with passengers, audio and visual in-
Software design and architecture research also needs puts, interaction with other vehicles, laws, and traffic
adequate forums for the presentation and review of control systems outside the vehicle. If the design prob-
research advances. Drawing from the study of design in lem is to design that interaction experience, what rep-
other fields, forums are also needed for the public pres- resentation does that design have? The interaction is
entation and review of designs themselves. Such re- fundamentally intangible. Traditional design disci-
view can inspire other designers, reveal properties of plines, such as automotive design, are strongly
new design techniques and tools, and add to the reper- grounded in the physical materials of their traditional
toire of design experience. Design research often does products and designers are unaccustomed to a final
not have the same character as research in other fields, reality that is intangible. Software designers, by con-
such as software testing and analysis. Hence traditional trast, have always dealt with an intangible product:
forums and criteria are unlikely to be adequate or ap- software; we are accustomed to designing, modeling,
propriate for review of design advances. and assessing a broader set of realities.
New forums for the discussion of software design If we therefore extrapolate the concept of “software”
would also be supportive of expanding the community beyond the traditional confines of the computer to en-
of contributors. As software design is recognized as compass radically different intangible products, such as
engaging teams of designers with expertise spanning this example automotive interaction, an exciting fron-
specific application domains, business planners, and tier opens up. Software designers may be able to lead
software specialists, a forum in which all would feel the way into conceptualizing, modeling, and building
“at home” would be productive. new kinds of intangible products. Working coopera-
Lastly, there is nothing like an incentive to spark tively with designers from other specialties, the pros-
quick advances in a field. Building architects are annu- pect is for creating new kinds of highly complex sys-
ally awarded the Pritzker Prize, an award that carries tems that are now barely imaginable.
not only international fame but a $100,000 reward. In Software design and architecture have a long future
fact, design awards are common in many fields: auto- ahead of it.
7. Acknowledgments [15] Balzer, R. Tolerating Inconsistency. Thirteenth In-
ternational Conference on Software Engineering. p.
158-165, IEEE Computer Society Press. Austin,
This work was supported in part by the National Texas, 1991.
Science Foundation, under grants 0438996 and [16] Binkley, D. Source Code Analysis: A Road Map. Fu-
0536203. ture of Software Engineering 2007 Briand, L. and
We would like to thank Alex Baker, Eric Dashofy, Wolf, A. eds. IEEE-CS Pres, 2007.
Peter Freeman, Michael Gorlick, Neno Medvidovic, [17] Booch, G. Object-Oriented Development. IEEE TSE.
Peyman Oreizy, David Redmiles, Lee Osterweil, and 12(2), p. 211-221, 1986.
Alexander Wolf for ongoing collaborations and fruitful [18] Bowman, I.T., Holt, R.C., and Brewster, N.V. Linux as a
discussions that have fueled the opinions expressed in Case Study: Its Extracted Software Architecture.
this paper. Twenty-first International Conference on Software
Engineering. Los Angeles, May 16-22, 1999.
[19] Brand, S. How Buildings Learn: What Happens After
8. References They're Built. Penguin Books, 1994.
[20] Brooks, F.P. The Mythical Man-Month: Essays o n
[1] Design Research Society. Software Engineering. 2 ed., Addison-Wesley, 1995.
<http://www.designresearchsociety.org/>. [21] Brooks Jr., F.P. The Mythical Man-Month: Essays o n
[2] University of California, Irvine, Donald Bren School Software Engineering. Addison-Wesley, 1975.
of Information and Computer Sciences, B.S. in In- [22] Clark, H. and Brennan, S. Grounding in Communica-
formatics. <http://www.ics.uci.edu/informatics>. tion. Perspectives on Socially Shared Cognition.
[3] Indiana University School of Informatics, B.S. o f American Psychological Association, 1991.
Informatics. <http://www.informatics.indiana.edu/>. [23] Conklin, J. and Begeman, M.L. gIBIS: A Hypertext
[4] University of Washington Information School, B.S. Tool for Exploratory Policy Discussion. ACM Trans-
of Science in Informatics. actions on Information Systems: 6(4), p. 303-
<http://www.ischool.washington.edu>. 331 1988.
[5] Milwaukee School of Engineering, B.S. in Software [24] Dwyer, M., Hatcliff, J., Pasareanu, C., Robby, and Vis-
Engineering. <http://www.msoe.edu/eecs/se/>. ser, W. Formal Software Analysis: Emerging Trends
[6] Rochester Institute of Technology Department o f in Software Model Checking. Future of Software En-
Software Engineering, B.S in Software Engineering. gineering 2007 Briand, L. and Wolf, A. eds. IEEE-CS
<http://www.se.rit.edu/degrees.html>. Press, 2007.
[7] d.school – The Hasso Plattner Institute of Design a t [25] Eberhart, M. Why Things Break: Understanding the
Stanford. World by the Way It Comes Apart. Harmony Books:
<http://www.stanford.edu/group/dschool/>. New York, 2003.
[8] Abbott, R.J. Program Design by Informal English [26] Egyed, A. Consistent Adaptation and Evolution of
Descriptions. Communications of the ACM. 26(11), p. Class Diagrams during Refinement. Seventh Interna-
882-894, 1983. tional Conference on Fundamental Approaches t o
[9] Abowd, G., Allen, R., and Garlan, D. Using Style t o Software Engineering. p. 37-53, Barcelona, Spain,
Understand Descriptions of Software Architecture. 2005.
ACM SIGSOFT '93 Symposium on the Foundations o f [27] Fielding, R.T. and Taylor, R.N. Principled Design of
Software Engineering. p. 9-20, ACM Press. Redondo the Modern Web Architecture. ACM Transactions o n
Beach, CA, December, 1993. Internet Technology. 2(2), p. 115-150, May, 2002.
[10] Agrawala, A., Krause, J., and Vestal, S. Domain- [28] Finkelstein, A., Gabbay, D., Hunter, A., Kramer, J., and
specific software architectures for intelligent guid- Nuseibeh, B. Inconsistency Handling in Multi-
ance, navigation and control. 1992 IEEE Symposium perspective Specifications. IEEE TSE. 20(8), p. 569-
on Computer-Aided Control System Design. p. 110- 578, 1993.
116, March, 1992. [29] Fischer, G. Communities of Interest: Learning
[11] Alexander, C. The Timeless Way of Building. Oxford through the Interaction of Multiple Knowledge Sys-
University Press: New York, 1979. tems. User Modeling. 2001.
[12] Bajcharya, S., Ngo, T., and Lopes, C.V. On Using Net [30] France, R. and Rumpe, B. Model-driven Development
Options Value as a Value Based Design Framework. of Complex Systems: A Research Roadmap. Future o f
Seventh International Workshop on Economics- Software Engineering 2007 Briand, L. and Wolf, A.
Driven Software Engineering Research at ICSE'05. eds. IEEE-CS Press, 2007.
May, 2005. [31] Freeman, P. The Central Role of Design in Software
[13] Baker, A. and van der Hoek, A. Examining Software Engineering. Software Engineering Education Free-
Design from a General Design Perspective. Institute man, P. and Wasserman, A. eds. Springer-Verlag: New
for Software Research, University of California, Ir- York, 1976.
vine, Technical Report UCI-ISR-06-15, October, [32] Freeman, P. The Central Role of Design in Software
2006. Engineering: Implications for Research. In Software
[14] Baldwin, C.Y. and Clark, K.B. Design Rules: The Engineering: Research Directions. p. 121-132, Aca-
Power of Modularity. 1, MIT Press: Cambridge, demic Press, 1980.
Mass., 2000. [33] Gamma, E., Helm, R., Johnson, R., and Vlissides, J.
Design Patterns: Elements of Reusable Object-
 Oriented Software. Addison-Wesley Professional [52] Larman, C. Applying UML and Patterns. An introduc-
Computing Series. Addison-Wesley: Reading, MA, tion to object-oriented analysis and design and the
1995. Unified Process. 2nd ed. Prentice-Hall PTR, 2002.
[34] Garlan, D., Allen, R., and Ockerbloom, J. Exploiting [53] Lethbridge, T., Diaz-Herrera, J., LeBlanc, R., and
Style in Architectural Design Environments. ACM Thompson, J. Improving Software Practice through
SIGSOFT '94 Second Symposium on the Foundations Education: Challenges and Future Trends Future o f
of Software Engineering. p. 175-188, ACM Press. Software Engineering 2007 Briand, L. and Wolf, A.
New Orleans, LA, December, 1994.. eds. IEEE-CS Press, 2007.
[35] Greenbaum, J. and Madsen, K.H. Small Changes: [54] Lopes, C.V., Kiczales, G., Mendhekar, A., Maeda, C.,
Starting a Participatory Design Process by Giving Loingtier, J.-M., and Irwin, J. Aspect-Oriented Pro-
Participants a Voice. Participatory Design: Princi- gramming. European Conference on Object-Oriented
ples and Practices Schuler, D. and Namioka, A. eds. Programming. Finland, 1997.
Lawrence Erlbaum Associates: Hillsdale, New Jersey, [55] Mark, G., Abrams, S., and Nassif, N. Group-to-Group
1993. Distance Collaboration: Examining the “Space Be-
[36] Gröne, B., Knöpfel, A., and Kugel, R. Architecture tween”. Eighth European Conference of Computer-
recovery of Apache 1.3 -- A case study. 2002 Interna- Supported Cooperative Work. p. 99-118, Helsinki,
tional Conference on Software Engineering Re- Finland, September 14-18, 2003.
search and Practice. Las Vegas, 2002. [56] Medvidovic, N. and Taylor, R.N. A Classification and
[37] Hassan, A.E. and Holt, R.C. Architecture recovery of Comparison Framework for Software Architecture De-
web applications. Twenty-fourth International Con- scription Languages. IEEE TSE. 26(1), p. 70-93, Janu-
ference on Software Engineering. May, 2002. ary, 2000.
[38] Hayes-Roth, B., Pfleger, K., Lalanda, P., Morignot, P., [57] Medvidovic, N., Dashofy, E., and Taylor, R.N. Moving
and Balabanovic, M. A domain-specific software ar- Architectural Description from Under the Technology
chitecture for adaptive intelligent systems. IEEE TSE. Lamppost. Information and Software Technology.
21(4), p. 288-301, April, 1995. 49(1), p. 12-31, 2007.
[39] Herbsleb, J. Global Software Engineering: The Future [58] Norman, D.A. The Design of Everyday Things. 1st
of Socio-technical Coordination. Future of Software Basic paperback ed., Basic Books: New York, 2002.
Engineering 2007 Briand, L. and Wolf, A. eds. IEEE- [59] Ommering, R.v., Linden, F.v.d., Kramer, J., and Magee,
CS Press, 2007. J. The Koala Component Model for Consumer Elec-
[40] Issarny, V., Caporuscio, M., and Georgantas, N. A tronics Software. IEEE Computer. 33(3), p. 78-85,
Perspective on the Future of Middleware-Based Soft- March, 2000.
ware Engineering Future of Software Engineering [60] Osterweil, L., Ghezzi, C., Kramer, J., and Wolf, A. Edi-
2007 Briand, L. and Wolf, A. eds. IEEE-CS Press, torial ACM TOSEM. 14(4), p. 381-382, 2005.
2007. [61] Parnas, D.L. On the Criteria to be Used in Decompos-
[41] Jackson, M. System Development. Prentice Hall: ing Systems into Modules. Communications of the
Englewood Cliffs, N.J., 1983. ACM. 15(12), p. 1053-1058, 1972.
[42] Jackson, M. Problem Frames. Addison-Wesley Pro- [62] Parnas, D.L. On the Design and Development of Pro-
fessional: Reading, MA, 2001. gram Families. IEEE TSE. 2(1), p. 1-9, 1976.
[43] Jackson, M.A. Principles of Program Design. Aca- [63] Parnas, D.L. Designing Software for Ease of Extension
demic Press, 1975. and Contraction. IEEE TSE. 5(2), p. 128-137, 1979.
[44] Jones, J.C. Design Methods: Seeds of Human Futures. [64] Parnas, D.L., Clements, P.C., and Weiss, D.M. The
John Wiley & Sons, Ltd.: New York, 1970. Modular Structure of Complex Systems. IEEE TSE.
[45] Kelley, T., Littman, J., and Peters, T. The Art of Inno- 11(3), p. 259-266, March, 1985.
vation: Lessons in Creativity from IDEO, America's [65] Parnas, D.L. and Clements, P.C. A Rational Design
Leading Design Firm. Currency/Doubleday: New Process: How and Why to Fake It. IEEE TSE. 12(2), p.
York, 2001. 251-257, February, 1986.
[46] Knuth, D.E. The Art of Computer Programming, Vol- [66] Perry, D.E. and Wolf, A.L. Foundations for the Study
ume 3: Sorting and Searching. Addison-Wesley, of Software Architecture. ACM SIGSOFT Software
1973. Engineering Notes. 17(4), p. 40-52, October, 1992.
[47] Knuth, D.E. Literate Programming. CSLI Lecture [67] Petroski, H. To Engineer is Human. St. Martin's Press
Notes, no. 27., Stanford, California: Center for the 1985.
Study of Language and Information, 1992. [68] Petroski, H. The Evolution of Useful Things. Alfred
[48] Kramer, J. and Magee, J. Self-Managed Systems: An A. Knopf, Inc., 1992.
Architectural Challenge Future of Software Engi- [69] Petroski, H. Invention by Design: How engineers get
neering 2007 Briand, L. and Wolf, A. eds. IEEE-CS from thought to thing. Harvard University Press,
Press, 2007. 1996.
[49] Kramer, J. Is Abstraction the Key to Computing? [70] Pohl, K., Böckle, G., and van der Linden, F.J. Software
Communications of the ACM. 2007. To appear. Product Line Engineering: Foundations, Principles
[50] Kruchten, P. The 4+1 View Model of Architecture. and Techniques. 1 ed., Springer, 2005.
IEEE Software. 12(6), p. 42-50, November, 1995. [71] Sarkar, S., Rama, G.M., and Kak, A.C. API-Based and
[51] Kruchten, P. The Rational Unified Process: An Intro- Information-Theoretic Metrics for Measuring the
duction. Addison-Wesley: Reading, MA, 2000. Quality of Software Modularization. IEEE TSE. 33(1),
p. 14-32, January, 2007.
 [72] Schön, D. The Reflective Practitioner: How Profes- Strategy: Applications to Decision Making Trigeor-
sionals Think in Action., Basic Books, Inc. Publish- gis, L. ed. Risk Books, 1999.
ers: New York, 1983. [78] Taylor, R.N., Medvidovic, N., and Dashofy, E.M.
[73] Shaw, M., DeLine, R., Klein, D.V., Ross, T.L., Young, Software Architecture: Foundations, Theory, and
D.M., and Zelesnik, G. Abstractions for Software Ar- Practice. John Wiley & Sons, 2008. In press.
chitecture and Tools to Support Them. IEEE TSE. [79] Tracz, W. DSSA (Domain-Specific Software Architec-
21(4), p. 314-335, April, 1995. ture): Pedagogical Example. ACM SIGSOFT Software
[74] Simon, H.A. The Sciences of the Artificial. 1st ed. Engineering Notes. 20(3), July, 1995.
The MIT Press, 1969. [80] Van Duyne, D.K., Landay, J.A., and Hong, J.I. The De-
[75] Simon, H.A. The Sciences of the Artificial. 2nd ed. sign of Sites : Patterns, Principles, and Processes
The MIT Press, 1981. for Crafting a Customer-centered Web Experience.
[76] Spector, A. and Gifford, D. A Computer Science Per- Addison-Wesley: Boston, 2003.
spective of Bridge Design. Communications of the [81] Yourdon, E. Techniques of Program Structure and
ACM. 29(4), p. 267-283, April, 1986. Design. Prentice-Hall: Englewood Cliffs, N.J., 1975.
[77] Sullivan, K.J., Chalasani, P., Jha, S., and Sazawal, V. [82] Yourdon, E. and Constantine, L.L. Structured Design:
Software Design as an Investment Activity: A Real Fundamentals of a Discipline of Computer Program
Options Perspective. Real Options and Business and Systems Design. Prentice-Hall, Inc., 1979.

View publication stats