Institute of Design and Assessment of Technology
Vienna University of Technology
Argentinierstrasse 8, A-1040 Vienna, Austria
This paper describes a prototype called ``CoPlan'' from the users' point of view. CoPlan supports cooperation between distributed professionals in architectural planning. CoPlan uses Web and database technologies to create a common information space between planners and producers. It offers several applications derived from users' specific needs, such as data access and decision support tools. These applications have been developed by applying methods of cooperative prototyping. CoPlan is customizable by users, is integrated with companies' present infrastructures and is based on Open Source Software. The architectural design practices CoPlan has to support are based on the notion of open planning. Open planning asks for a conceptual shift from working with fixed elements or solutions to working with place-holders which represent open design decisions. Place-holders are defined by several parameters and relations between these parameters.
Keywords: systems design, common information space, CSCW, cooperation work in architectural planning, Web technologies
Intense interactions and sharing of information resources between professionals became essential to improve the productivity and services companies develop. The Internet offers a communication network that enables cooperation between different companies around a joint project. Since more connectedness and more concurrent access to common data resources are required, it is necessary to develop new infrastructures to arrange collaboration among distributed actors and to ensure the consistency of shared data resources during the collaboration process. Existing technical and organizational environments need to be enhanced and adapted to the needs of their users.
In architectural planning a cooperation between architects and producers of construction elements is a necessity . Architectural planning is a closed process, and constructing is still based on applying traditional skills and know-how. There are some problems architects have to deal with when they have to cooperate with producers of construction elements .
First, products and materials offered by producers are barely compatible with each other. It is very difficult and often impossible to combine elements of different materials, sometimes even produced by the same company. There are no standards for the construction of architectural elements and no standardized interfaces for combinations. Joints between elements must be designed each time from the scratch. When the construction begins, incompatibility problems usually arise unexpectedly. That can cause an unavoidable increase of construction costs and delays in the progress of the construction. There are some articles about modularization of components, planning with prefabricated elements, and innovative solutions for interfaces design   . However, there are very few implemented projects. There is a need to find out new possibilities to apply industrial prefabrication in the architectural construction, especially based on design and implementation methods applied in work practices.
Second, construction elements are offered in a very classifying and structured form, which is restricting the design work of architects. Most producers offer either only small construction elements, or completely prefabricated large components with no or very few possibilities for variations. Architects can not make best use of them.
Third, architects and producers have their own visual culture, with their own specific drawings, plans, standards, notations, and layers (e.g. in CAD drawings). Practices of architectural planning and implementing are defined and shaped by these factors. The type of visualization determines the view of the object-in-development and influences the work trajectory of design and implementation, without considering the technical and economical conditions and circumstances of production, montage and maintenance of the building or its construction elements.
Additionally, contact to producers is usually established in a very late project phase. At the time planners look for producers, the detailed plan of construction components are normally finished and architects' requirements are fixed. The call for producers usually includes the very specific solutions architects have developed and very concrete element types and specifications architects have decided to use. This means that it is often too late to use other materials or elements than the planned ones, because of several dependencies between construction elements.
In this context the main support that needs to be given by computers is the information exchange between planners and producers. The interface between both communities of practice is presently established in form of face to face meetings, telephone calls, and if necessary, by sending relevant documents to one another by fax or ordinary mail. Generally there is no electronic communication or computer support. Information to communicate can be text (regulations, specifications, price lists, etc.) or image (CAD-plans, hand-drawings, photos, etc.). One goal is to transmit architects' requirements (that enable the understanding of the solution) and design ideas to producers. Additionally, a shared platform between architects and producers can be used to support interactions and working together on a common project. By using Web technologies user-tailored applications can be developed, which have to be compatible with different computer platforms and integrated with the present information infrastructures.
In the next section work practices of architects are described. Based on the ethnographic studies we carried out  , artefacts architects create and communicate with producers and current cooperation practices are presented. The notion of open planning is introduced. Section 3 presents the implemented prototype CoPlan from a users' point of view. Section 3 is followed by conclusions.
Work practices of architectural design are based on coping with complexity. This can be observed in daily work processes, in cooperation between members of the project team and with the external partners, in dealing with and developing of architectural techniques, materials, and resources . A typical architectural project is structured in phases whereas each project phase ends with the production of an artefact like preliminary design, design specifications, detailed plan, costs, etc. These artefacts are usually presented to the building owner at the end of each project phase. It is always possible and often necessary to change the design after these meetings.
As a result of several research projects a methodological approach to architectural design work has been developed, which is called `open planning'  . ``Open planning as an architectural practice can be characterized as a) conceptual, thinking in images, metaphors, and analogies; b) moving on in a process of encircling specific design problems; and c) systematically enlarging the solution space and holding it open.'' [9, p.20] Openness implies that design decisions are not made too quickly. The work of involved actors need to be in a form that is open to the possibility of change. This need for change can arise from many sources, such as the client's ideas and requirements, technical constraints, new products, regulations and norms. This may not only require to maintain things at different stages of incompletion. It asks for a conceptual shift from working with fixed elements or solutions to working with place-holders which stand for any openness in relation to a set of parameters and to look at specifications as partial and preliminary.
Due to economic reasons it is also important to keep product specifications open as long as possible. The total time for architectural planning from the start of the project to the beginning of construction is long. The price and specifications of products on the market, available at the time the project started, may have been changed in the meantime. New products may be offered or old products may have been withdrawn from the market.
Reasons given above call for an application that supports working with place-holders and keeping the value of elements' parameters open as long as the project development allows. In the next section the implemented prototype CoPlan is presented which supports open planning and decision making of architects regarding the choice of construction elements.
The system ``CoPlan'' (Cooperative Planning) is a shared information space that is accessible for architects and their partners such as producers. CoPlan enhances the work environment of both architects and producers. It offers an electronic space for sharing of data resources, for cooperating by using common artefacts, and for exchanging relevant data and documents easily in all project phases. The sharing of data resources is sequential, and the resources are dynamic. One actor adds information to shared data resources which are needed by the next actor for taking action or making a decision.
In the remainder of this section CoPlan will be described in detail from a users' point of view. CoPlan's features will be presented by illustrating its daily use both by architects and producers cooperating with architects in a construction project. CoPlan's front-end applications implemented for the architects' use and the Web interface implemented for remote access will be introduced. At the end of the section CoPlan's further features will be specified briefly.
Architects' work is organized within projects. Projects are divided into phases which are determined by deadlines or specific decisions architects make. Projects can include a lot of organizational, temporal or financial information that can influence the projects' progress. In architectural projects persons from inside or outside can be given different roles, which may be rearranged repeatedly during the project. When architects start designing a project they first create the relevant project data (usually by entering its name such as `Wohnhaus1') into the CoPlan's central database by using an ODBC interface (Figure 1). To create new projects architects can take over structures of previous projects with similar elements. They can define several elements (like `WA' for walls), which include subelements usually identified with a code (like `WA.17' for fire walls, `WA.21' for walls between the flats). These codes are mainly used as references to the entities in the CAD drawings of the architectural plans.
CoPlan structures projects' subelements into three groups:
The main subelement data. This includes a description of subelements (e.g. fire wall to existing old building), links and references to other subelements that can be found in CoPlan (e.g. concrete-FT, brick wall), in a catalog of a producer (which is paper-based or available on a CD-ROM) or in the Internet. Additionally, information about producers of construction elements, vendors, their products and delivery conditions can be added.
Restrictions and givens. Restrictions given by building owners as well as regional building regulations can be stored related to the subelements. Design ideas and architects' principles (e.g. easy to reach from outside) can also be attached accordingly. To communicate the design ideas and project progress architects often attach CAD drawings or hand-drawn sketches to the project data (appendix). These files show usually additional restrictions given by the design.
Subelement properties. For each subelement, several property categories can be created by architects (e.g. element properties of walls). Important is that these property groups contain user-defined single parameters (e.g. height between floors, length of the element, surface, max. thickness) that can be assigned to subelements depending on the element type. These subelement parameters are first set by architects. They can be marked as ``fixed'' or ``open'', which depends on several factors. Design ideas, dependencies between parameters of some construction elements, and other technical measurements can be reasons to fix or keep the values of elements' parameters unset (open). Decisions about material and products including corresponding design parameters can be kept open for further changes as long as possible.
Setting subelement parameters ``fixed'' or ``open'' supports open planning and planning with place-holders. A place-holder represents an open design decision, e.g. the length of the element has no value and marked as ``open'', which means that the architect did not decide or did not know the value yet because the design is not completed, and which, at the same time, means that producers can offer an element with any approriate length in this category, because it is still ``open''. Of course, there are dependencies between the parameters of the construction elements and every change in the design influences the related parameters, no matter whether ``fixed'' or ``open''.
The infrastructure CoPlan creates is a common information space (CIS) accessible by all participants. CISs play an open and malleable role within a local community of practice [1, p.94]. At the same time, they accommodate ``boundary objects, packaged and being turned into immutables to allow sharing across contexts and different communities of practice'', such as architects and producers. The CIS created by CoPlan helps the negotiation and articulation of element design between professionals participating in a project. It contains different types of contextual information: information about previous and current projects, information about products and production processes of different producers, information about the context of a project like data about its geographical location and environment, information about restrictions and regulations, norms and standards.
By means of CoPlan's CIS, all values added by architects can synchronously be communicated with producers. If the necessary authorization is granted by architects, producers can access the data in the central database though a common gateway interface (CGI). They can access the central CoPlan server by using any Web browser. Searching in and adding new data into the central database, retrieving a file from and saving onto the file system on the CoPlan server are easily done by means of HTML forms transmitted through HTTP (Hypertext Transport Protocol).
For instance, if a producer, interested in the project `Wohnhaus1', wants to know about the parameters of the wall elements, he or she can search for the project `Wohnhaus1' after logging into CoPlan (Figure 2). If the project has been found, its elements are retrieved and displayed automatically. Activating a link in the HTML file calls a SQL query on the server through CGI. The producer then can search for subelements, e.g. for the fire walls `WA.17'. All element parameters entered by the architect are displayed with additional options for the producer: The producer can add his or her offer by entering vendor and product data, and by putting images or documents to the CoPlan's file server. Additionally, new parameter values, that the producer can offer in that specific project, can be submitted after filling in the HTML form. Producers have also the possibility to mark their element parameters as ``fixed'' or ``open'', depending on the flexibility they have in the production of the required elements.
CoPlan makes decision making for architects easier (Figure 3). It offers a front-end tool that supports a comparison between elements and materials offered by different producers. Data of finished projects are made available in order to access previous experiences gathered, design ideas developed and contacts established.
Architects can choose among elements and subelements in a specific project a solution is needed for. They also can choose between producers who offered their products in the same project. After configuring these comparison parameters, architects can start with displaying subelements' values entered by different producers. Architects can compare these values either with their initial requirements or with offers of other producers. They also see the properties ``fixed'' and ``open'' for each parameter. If they decide to take a product they can mark it as fixed. The comparison can be repeated as often as necessary, with enabling temporal or permanent fixations of elements' values.
CoPlan offers a customizable interface for architects. Architects can define and label their own project elements and subelements. They can assign several property categories to subelements, such as element properties of walls, with user-defined and user-labeled single parameters, such as height between floors, length of the element or max. thickness. Additionally, both architects and producers can attach documents to the project in order to communicate the very specific details with each other.
CoPlan enables data access to users only through views depending on their profession and function in current projects. Views are created in the database automatically when a user is added to the system, which can be done in the current version only by architects. In database terms, views are virtual relations. They are derived from and represented by base relations and tables [4, p.18]. They do not contain their own data in addition to the data of base relations. On the other hand in CoPlan terms, views enable controlled access to database structures and through this to the common information space. Producers accessing project data in CoPlan do not see the data that other producers add to the system unless they are authorized to. Only architects have the full control of all data in the system, by using the MS Access front-end application or database tools.
CoPlan integrates the present information and computer structures of a company. The Intranet of architects and producers must be connected to the Internet. CoPlan uses standard network protocols (such as TCP/IP, FTP, HTTP). Different SQL-based databases can be integrated without any problem . In the current version Adabas D is used. CoPlan is based on Open Source Software for which updates are available easily and regularly. It uses Linux as operating system, Apache as HTTP server, and PHP3 for programming the CGI (Figure 4).
CoPlan is scalable. It can be used in a small configuration, e.g. only to support one architect with one producer. But it can also be used to support a larger network of professionals cooperating around a project.
Many distributed, intertwined and interdependent work activities need to be coordinated in order to make the schedules in time. Coordination and collaboration between different communities of practice can be established by accessing the common artefacts created and modified by all participants.
In design disciplines like in architectural planning it is important to communicate ideas and principles with collaborating partners. One way to do that is to use the artefacts themselves, e.g. by attaching additional relevant information to them. By means of shared information spaces consisting of common artefacts and available on the Web, continuous cooperation between distributed actors can be established around a joint project. The design of common information spaces must include the design of regulations for data access and permissions to the shared artefacts.
Architectural design needs open planning methods and furthermore applications as well as infrastructures that support them. CoPlan is a first prototype for this purpose. It applies Web and database technologies to create a common information space. It offers different applications depending on users' specific needs. Further development is needed to improve controlling and monitoring of data access, to ensure data integrity e.g. by means of triggers by applying ECA rules, and to support other phases of architectural planning such as call for partners.
This document was generated using the LaTeX2HTML translator Version 99.1 release (March 30, 1999)
Copyright © 1993, 1994, 1995, 1996,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 -no_navigation koopl.tex
The translation was initiated by Hilda Tellioglu on 1999-12-11