ARCHITECTURE (DISAMBIGUATION): MAPPING A RESOURCE-BASED DESIGN PROCESS SYSTEM Ahmed K. Ali1 1Texas A&M University, College Station, Texas ABSTRACT: The process of designing and developing a building from conception to realization is indeed a sequence of creative and rigorous activities that combine the art of architecture with its scientific, engineering and financial aspects. Like other creative activities, the design process charts a path that is not always straightforward and, in fact, is likely to include multiple investigative sub-design procedures. Previous attempts to define the architectural design process have been vague and confusing to those in other disciplines. In this paper, we introduce a novel method of integrating system thinking into architectural design by mapping its processes in a standard modeling language. We present a decision-support framework using process mapping in order to incorporate sustainable building materials and resource reuse decisions into architectural design practice. We turned to other disciplines’ knowledge bases, such as Business Information Technology (BIT), to develop a workflow system for the Design-Bid-Build (DBB) process. Mapping both current and the proposed design processes, including their activities, workflow, processes and decision nodes, was critical in defining roles, processes, and subsequent decisions. A literature review suggests that there are five types of design processes, which are somehow defined as linear, divisional, centralized, cyclical and investigative. However, no attempts have been made to map their processes using a systematic methodology. In this study, we utilized a qualitative methodology to capture the required knowledge from industry experts in resource-based design and then integrated our findings into a set of process maps to support the materials decisions of the architectural design team. KEYWORDS: Architecture, System Thinking, Process Design, Resource-Based Design INTRODUCTION When asked what architecture would be like in fifty years and what we could anticipate in the interim, Louis Kahn simply responded, “You cannot anticipate.” Then, he recalled his meeting with a group of General Electric executives who presented him with a depiction of what a “spacecraft” would look like fifty years hence. Kahn listened carefully, then responded with conviction, saying: It will not look like that, because if you know what a thing will look like fifty years from now, you could do it now. But you don't know because the way a thing will be fifty years from now is what it will be. (Kahn and Ngo 1998). Kahn relayed this exchange to a group of architecture students at Rice University in the spring of 1968. Nearly fifty years have passed, and Kahn's statement remains valid today. Unlike Kahn, Ulrich Beck argued that the current era is defined by increasingly global problems, the mitigation of which ultimately require “anticipation” (Beck 1992). Whether we agree more with Kahn or with Beck, we realize the inherent difficulty in anticipating solutions for the complexities of the architectural discipline of tomorrow, especially given that we cannot even define our current design process. Like Kahn, we might not be able to completely anticipate the future of architecture in addressing increasingly global problems, but we might still find it valuable to attempt to redefine the complexity of our current architectural design process through its integration with common mapping language. Literature searches for “architecture of complexity” led us to a foundational article with the same title, written in 1962 by Herbert Simon, then a professor of computer science and psychology at Carnegie Mellon University. His work focused on artificial intelligence, psychology, administration and economics. Simon, in his article, argued that the “architect” of complexity uses hierarchy as the central structural scheme of a system. He defined four aspects of the architecture of complexity, as illustrated in Fig. 1: frequency in the form of hierarchy; the relationship between structure and time; the dynamic properties of hierarchy; and, finally, the relationship between the complex system and its description (Simon 1962). In his later book, The Sciences of the Artificial, Simon defined design as the process by which “we devise courses of action aimed at changing existing situations into preferred ones” (Simon 1969). Simon’s work, which heavily borrowed terminologies from the discipline of architecture (such as design, architect, architecture, structure and hierarchy), leaves us wondering precisely to which domain he was referring: architecture or computer science? In today’s nomenclature, and as a result of the exponential growth of the information technology (IT) and information systems (IS) domains, understanding the terminology at it pertains to its underlying intent can be difficult. 402 ARCC 2017: ARCHITECTURE OF COMPLEXITY In the last fifty years, the fields of artificial intelligence (AI), information technology and computer science have significantly repositioned these terms. For example, in IT, the term “architecture” refers to the system architecture; the term “design” refers to system design or process design, and “architect” refers to the system engineer. The enormous growth of big data, systems and information raises the following questions: How can architects cope with the increasing complexity of the built environment? How can architects move their design process from ambiguous to defined territories? Figure 1: Simon’s four aspects of the “architecture of complexity.” Source: (Author 2017) 1.0. THE DESIGN PROCESS AND THE ARCHITECT To answer these questions, we must begin by acknowledging that architecture, as a discipline, is not solely a commercial transaction, a service activity, or a manufacturing process. It is neither an engineered system nor a mathematical model. Although the general public might perceive that architectural practice is nothing but a business providing services and products, this misconception doesn’t take into consideration the artistic, scientific and creative essence of architecture. In this paper, we refer to architecture as the “physical built environment,” but also acknowledge the wide use of the term in reference to the components of a system for processing information. Inevitably, architects are now asked to navigate new knowledge domains that integrate the possibilities provided by the information age, and therefore, must seek to resolve the conflict that arises in the established practice of passing on traditional skills. As a result, the architect is under pressure to make buildings that are influenced by today’s information age. A distinction between being a process- oriented and a product-driven architect is explained in the book 101 Things I Learned in Architecture School. Frederick’s distinction of being a process-oriented architect characterizes certain qualities regarding the way one assesses design problems, makes decisions and implements solutions (Frederick 2007). If we adopt Simon’s definition of design as a “process by which we devise courses of action aimed at changing existing situations into preferred ones,” we are likely to have a foundational base for building a design theory. Design theory relies on human (or “tacit”) knowledge, because design thinking is outside the boundary of verbal discourse (Daley 1982). Under the scientific paradigm, where findings are presented as description, designers and architects find it very difficult to specifically describe what they think when they design, because design thinking is better expressed through the use of examples and by showing how design is done, rather than through merely describing the process. Here comes our dilemma in the realm of epistemology, which deals with little-objectified knowledge. Design knowledge pertains more to a knowing or a guiding intellectual capacity embedded in human actions and practices (Cross 2001). Therefore, while design knowledge might be difficult to describe, it is not inaccessible for research purposes. Friedman argued Architecture (disambiguation): Mapping a Resource-Based Design Process System: Ali 403 that design knowledge grows in part from practice, and therefore, overlaps with design research (Friedman 2003). The cornerstone of our epistemology is the distinction between tacit and explicit knowledge, where the key to knowledge creation lies in the mobilization and conversion of tacit knowledge. Friedman uniquely defines the position of design relative to science. His view of theory-construction in design research as “design sets on . science’s three legs,” is illustrated in Fig. 2. Figure 2: Friedman’s view of theory construction “design sets on . science’s three legs." Source: (Author 2017) 1.1. Constructing a Design Theory To provide the underpinning theoretical framework for why we are concerned with modeling the design process, we should explain how to construct a design theory. In this study, we primarily deal with prescriptive theory, while acknowledging the fundamental intuition of design as a creative activity, which cannot readily be mapped or prescribed. The work presented here is related to the overlapping territory between the two frameworks of theory. Friedman, in his work on theory building, stated that one should consider a process of forming “models” for the research problem and continue refining these models and repeating the process until one has the simplest possible model that demonstrates all the phenomena under