A DISCIPLINE OF SOFTWARE ARCHITECTURE Peter J. Denning* and Pamela A. Dargan** *CS Department, George Mason University, Fairfax, VA 22030 USA, [email protected] **Mitre Corporation, McLean, VA 22102 USA, [email protected] Abstract: Neither software engineering nor software design qualifies as a discipline, but software architecture might. Action-centered design is proposed as the means to build software architecture by joining the two. Key Words: Software engineering, software design, software architecture, action-centered design, ontological mapping, workflow. © 1994, Association for Computing Machinery, Inc. ISSN 1072-5520/94/0100 $3.50 Reprinted with permission from ACM Interactions 1 , 1 (January 1994), 55-65. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permission from <[email protected]>. The software landscape is a mixed field of but never used (Charette 89). Similar problems successes and failures. Most noticeable among persist today (Newport 86). the successes are software packages that turn personal computers into document preparers, Software engineering is characterized as a set of spreadsheets, databases, animators, image formalisms, methods, and practices for displays, drawing tools, financial accountants, producing “reesstmts” -- reliable, economical, tax preparers, legal advisors, encyclopedias, efficient software systems that meet their video games, electronic mailers, network specifications. The persistent inability to achieve browsers, work exchangers, and much more. this goal has led experts to say that software engineering is not a discipline, and that the The failures are disturbing by their number and word “engineering” even conveys the false spectacularity. Peter Neumann has compiled a impression that a discipline exists. The list of the 1500 most disastrous failures of designers of computers recognized early on that software systems since 1972; the list grew by 200 producing “reesstmts” would be a challenge: the cases in 1993 (Neumann 93). Among the most term “software crisis” was already being used in widely known on that list are the aborted NASA the 1960s and inspired the birth of software space mission in 1975 due to a deadlock in the engineering in 1968 (Tichy 92). A long series of distributed control system, the collapse of the innovations including modularity, structured ARPANET in 1980 due to failure of a load programming, chief programmer teams, control algorithm, and the shutdown of a major dataflow diagrams, information hiding, data segment of the AT&T switching network in 1990 abstraction, program verifiers, syntax-directed due to a synchronization bug in the routing editors, programming environments, structured software. A 1979 GAO review of nine software languages, software-parts reusability, visual projects for the Department of Defense showed programming, object-oriented programming that about 2% of the dollars were spent on and design, catalogs of design paradigms, CASE software that was delivered and in use, about a tools, and, most recently, megaprogramming, quarter on software that was never delivered, have produced only modest gains but have not and about half on software that was delivered transformed software engineering into a discipline for producing “reesstmts”. The per- grow into a discipline within a few years and sistence of the software systems crisis over such could resolve the software crisis. a long period leads inescapably to questioning the foundations of software engineering: for the The second claim here is that an ontology of de- field as currently formulated is incapable of sign is needed to bring the two fields together; producing the results it seeks (Andriole 93). neither has such now. (An ontology is a concep- tual framework for interpreting the world in Software design is characterized as a set of prac- terms of actions.) Software engineers see design tices and implementation techniques that allow as a process of gathering requirements into a for- the construction of marketable software systems mal specification and then organizing the soft- that provide form and function satisfying to ware production process, and the software, to users. Software designers tend to think of their meet specifications efficiently and economically. work as a craft best learned through apprentice- Software designers see design as a collection of ship and the design process as a close participa- practices that can only be verbalized as aphor- tion with users. They do not claim to have a isms and rules of thumb; a design is satisfactory discipline. They dispute the claim of software only when a client says it is, an assessment engineers that design is subsumed in software based in part on meeting specifications and in engineering. They say that they do not use soft- part on factors that defy engineering measure- ware engineering methods in their successful ment, such as form, style, esthetics, effective products, that their articles have not been wel- completion of work, freedom from negative come in the software engineering literature, and surprises, anticipation of future cases, and that they have founded such groups as ACM serving organizational and political interests. SIGCHI and the Association for Software Design to pursue investigations of design not fashion- We propose an interpretation of design that is able among software engineers (Kapor 91, Wino- the beginning of an ontology. It is focused on grad 96). the satisfied client and not just the specification- meeting system. It is grounded in a language- Software engineers and software designers share action perspective rather than a systems per- a common interest in developing a discipline spective (Erickson 93). The new interpretation whose practitioners can produce “reesstmts” observes concerns, breakdowns, standard prac- systematically. They disagree on how to accom- tices, institutions, and recurring actions and pro- plish this. Will it require more formalism? More duces means to connect those observations with practice? More emphasis on systems? More software structures. The skill of doing this is emphasis on people? here called action-centered design (Denning and Dargan 96). What is a discipline? To be called a discipline, a field must satisfy three criteria: (a) it has a set of formalisms, methods, models, and processes that Design as Deriving a System are used regularly to produce results, (b) it has a set of standard practices including generally from Specifications accepted community standards for levels of competent performance and criteria for excel- The dictionary lists no less than ten different lence, and (c) its practitioners can reliably fulfill senses of the verb “design”. The primary mean- standard promises to the satisfaction of clients. ing is “to conceive or execute a plan.” Engineers The third criterion is the most important and use the term “design” in a specialized way that least discussed. The question is not whether is consistent with this general definition. formalisms and practices are properly balanced, but what formalisms and practices are necessary Engineers say that design is the dominant para- so that practitioners can keep their promises to digm of engineering. They intend “design” to clients. By these criteria, neither software describe a staged process that begins with a engineering nor software design qualifies as a problem statement, constructs a statement of discipline. requirements and then specifications of a system that solves the problem, builds a prototype Our main claim here is that the missing disci- system, and tests it to demonstrate that it meets pline is neither software engineering nor soft- the specifications within given cost constraints. ware design, but software architecture. It could Like other engineers, software engineers have be constructed by joining software design and used the engineering design process to construct software engineering, following architecture of software systems; in this case they call the pro- buildings as a model. The resulting field would cess the software life cycle model, the most com- mon varieties of which are the waterfall model and the spiral model (Boehm 76, Boehm 87). The We claim that the crisis is more usefully waterfall model was proposed for systems approached as a breakdown of customer satis- whose requirements were fully understood in faction. The standard engineering process offers advance. The spiral model is a more recent little to connect the actions of designers with the extension that accounts for iterations and refine- concerns of customers; the interaction between ments of the system until it converges on one them is limited to the requirements and specifi- acceptable to the customer. Unlike other engi- cations documents (Denning 92a). neers, software engineers cannot claim success for their instance of the engineering design process. They have not developed a systematic method of producing “reesstmts”. Design as Identifying and Taking Many explanations have been proposed to Care of Concerns explain this anomaly. The most