TOWARDS A FLEXIBLE IT-BASED SYSTEM FOR PROCESS STEERING IN ARCHITECTURE DESIGN

TOWARDS A FLEXIBLE IT-BASED SYSTEM FOR PROCESS STEERING IN ARCHITECTURE DESIGN Ahmed Lroussi 1, Alin Zrli 1, Jen-Clude Bignon 2, Gilles Hlin 2 1 Centre Scientifique et Technique du Bâtiment (CSTB), Sophi Antipolis cedex, Frnce 2 Centre de Recherche en Architecture et Ingénierie (CRAI), Nncy cedex, Frnce ABSTRACT: This pper tckles the problem of ssisting the steering distributed design processes in rchitecture. It suggests mcro model oriented steering, bsed on brekpoints notion borrowed from computer field. We formlize the use of brekpoint into process bsed on two notions: Concern Sitution nd Aimed Sitution. A first softwre implementtion is tried strting from this modelling. KEYWORDS: steering of distributed design processes, brekpoint, concern sitution, imed sitution. 1 INTRODUCTION Coordintion of the ctors nd integrtion of their vrious points of view still remin key issue in design processes, nd most of the time the origin of mjor filings. Gthering the vrious skills nd expertise in design in rchitecture nd getting them work together while t the sme time preserving comprehensive nd synthetic vision of the overll construction design process, do require to orchestrte certin degree of coherency while keeping the diversity of bility nd competencies. This pper dvoctes tht putting in plce forml mngement procedures for design in rchitecture hs the power to deeply contribute to the nticipted dministrtion of controlled interctions between ctors, to the mstering of knowledge nd expertise of vrious business processes, to the coopertion of ctors, nd cn gretly help to support decision mking nd constructive trde-offs between the vrious construction plyers. To chieve such n mbition, we indeed consider two levels of mngement in rchitecture design: - The mngement of design processes, which requires the identifiction of pilots whose role is the cognitive synchronistion in design process. This level of mngement llows ll the ctors involved in this design process to get knowledge of the sttes nd ims of process tht form the design ctivity; - The mngement of the design project, which follows the usul rules of project mngement, nd is bsed on synchronistion of time nd spce (tsk lloction, rticultion of ctions, their workflow, etc.). Also, depending on the different cost nd qulity constrints, numerous tools exist in order to instrument project mngement (e.g. Gntt Digrm, project mngement portls, Computer Supported Coopertive Work, etc.). However, there re no tools tht would ssist the design processes pilot to ssure the coherence nd the cohbittion crried by the different ctors of the process. For this reson, we focus in this pper on first-level mngement (design processes mngement) by proposing flexible IT-bsed system for process steering in rchitecture. The pper is orgnized s follows. - In section 2, we present different chrcteristics of design ctivity steering. - In section 3, we propose mcro model of design processes steering tht is bsed on forementioned chrcteristics nd tht refers to the notion of computer debugger (brekpoints). Tht llows us to introduce two concepts linked to design steering in rchitecture (the concern sitution nd the imed sitution). - In section 4, we present first pproch of instrumenttion of design processes steering in rchitecture. 2 THE STEERING OF ARCHITECTURE DESIGN 2.1 A cross-field ctivity The steering of design project in rchitecture consists in conducting the set of ctivities nd processes tht re necessry for the implementtion nd chievement of the building. Observtion of prctices showed us tht both the building to design nd the design process re concerned by this ctivity. Four min skill-relted chllenges re identified: - Mintin the coherence of the building throughout its evolution (coherence between the building nd the need for conception, coherence between the different components of the building). - Tke decisions tht im to orient the process nd vlidte the evolutions of the building. - Integrte the points of view of the different ctors. This is completed on one hnd by nlyzing how the 295

specific knowledge of ech ctor contributes to the globl vision of the building, nd on the other hnd by trnslting the different points of view into specifictions for the building. - Orgnize the coopertion by mnging the network of ctors nd skills in the light of the objectives nd by keeping the convergence in the definition of the solution. The different tsks delivered by the steering ctivity re therefore interdependent nd complementry. Moreover, s the nture nd origin of project influence the steering ctivity, the project cn bring n nswer to mny unfolding schemes tht imply different steering pproch. This is why the design of steering generlly depends on the know how nd personl experience of n ctor. In order to steer effectively, this ctor tckles ech event, new solution, nd new tsk through ll the implictions they cn hve in ll the fields of the project. Therefore, the steering of design ppers nrrowly linked to the evolution of the design process. In tht wy, numerous ctors come up with nswers in order to effectively steer the design processes in rchitecture. They propose to distribute ctivity in n intelligent mnner, to the right ctor, in order to rech the most systemtic possible level of integrtion of his solution. 2.2 A predictive nd rective ctivity The design process is often too complex to be entirely conducted in n intuitive mnner, without being structured beforehnd. A cler frmework tht imposes to the ctor of design certin line of conduct is necessry in order to run the process effectively. However, in order to be effective in the design process, ctors need some degree of freedom. They lso need to be ble to define their own business processes nd dpt them to the needs of projects nd to the evolution of prctices. We consider here the two spects of given process. Design is predictive ctivity, tht hs to be plnned nd instrumented. It is n ctivity for which ctions tht will be implemented re defined beforehnd. At the sme time, design is rective ctivity, tht evolves nd dpts s its content chnges with the environment nd with the personlity of the ctors tht conduct it. All the complexity of the design therefore lies in this dulity. It is therefore greed upon tht design steering consists of orgnizing nd plnning tsks with lredy identified mecnisms nd results. It lso consists in mnging events, ctions nd situtions tht re not initilly known nd formlized. The success or filure of project is often explined by the mnner in which these different unplnned situtions re mnged nd controlled. 3 MODELLING DESIGN PROCESSES IN ARCHI- TECTURE Mny reserchers such s Pen (Peñ 1977) nd Alexnder (Alexnder 1971) consider this process s sequence of problem solving situtions tht cn be treted in different wys in order to be resolved in stisfying mnner. Tking into considertion the nture of the problems to solve nd the degree of their complexity, Rynud (Rynud, 2002) highlights tht the rchitect fces two types of distinct situtions: problem solving sitution with non defined ctions nd nother one tht is directed by multiple gols. Indeed, the ctors of design fces difficulties tht sometimes require to use scientific rules in order to formulte or reformulte the wording of the problem using logicl processes. In spite of tht, this detection is not considered t ll s finl solution. It is n unfinished process nd not closed nd finite system (Prost nd l, 1995). Moreover, the ctors of design often fce problems of multidisciplinry nture nd firmly embedded, tht need multiple stisfying proposl. In n rchitecturl spce, one element cn serve multiple gols of structurl, functionl, rchitecturl, nd even urbnistic order. Moreover, design processes re not liner but dynmic, nd the upcoming solution is the result of n «itertive» pproch. In this sense, we come close to the conclusions of Schön (Schon 1983) nd Visser (Visser 2002), who give to the problem nd its construction cpitl importnce. Hence, the design process is, from mcroscopic point of view, the trnsition from problemtic sitution to n objective one therefore leding to the solving of the problem. This implies, from finer point of view, the lterntive implementtion of problem-solving nd problem- setting ctivities. Nidmrthi (Nidmrthi 1997) comes up with the sme conclusion through descriptive study of ctivities conducted independently by two designers working lone on n identicl given problem. He distinguishes problemsolving ctivities from problem-setting ones. He notices tht these ctivities re conducted throughout the design process. He concludes tht there re not necessrily preliminry to the other design ctivities. The representtion of the problem then evolves throughout the long design process. In ddition to the two dimensions of time (or phses) nd their relted tsks, the dimension tht distinguishes the sttement of the problem from the definition of the solutions should lso be considered. Moreover, we cn ssimilte the tsks to the different professions to which it is ssocited. This choice llows to represent the problem-wording nd problemsolving processes in three-dimensionl spce (see Figure 1). Through this multidimensionl spect of the design processes, we enhnce the lck of model tht llows to fully explin design in rchitecture. Consequently, it becomes necessry to concentrte on the steering ctivity of the design in order to build modeliztion of the design processes in rchitecture tht is steering-oriented. 3.1 The multidimensionl spect of design process in rchitecture: brrier to full modelling During lst century, numerous pproches were creted in order to modelling design process in rchitecture. 296

Figure 1. The multidimensionl spect of design processes. 3.2 A steering-driven mcro model of distributed design processes in rchitecture Design in rchitecture is chrcterized by uncertinty nd the lck of formlized specifictions. Becuse design objectives re continully re-evluted (Simon 1992), it doesn t llow to define unique processes. Moreover, s described by (Drses & Flzon 1996), (Turk et l 1997), (Hnser 2003) the impliction of ctors in design process cn tke vrious forms. Their enggement in the process is similr to Co-design or distributed design (Figure 2). The ctors cn meet these two situtions successively, during the sme project or the sme design process. - Anlysis: it includes ll the ctivities of collection of technicl, regultory, economic, dministrtive dt (e.g. regultory constrints nlysis, nlysis of the documents of nother ctor, etc.) - Proposition: it includes ll the tsks tht llow to implement ides or generte concepts (proposition of n insertion in the site, volumetry proposition, proposition of principle of structure, etc.). These tsks re relized through production tsks nd require coordintion tsks when crried out by mutliple ctors. They list, in recursive mnner, the types of possible responses to the problems encountered. This listing is chieved in the form of options nd hypotheses, from their suggestion to their formultion. Orgnistion plns nd figures s well s sptil development propositions re produced by tking into considertion specifictions from previous phses. They hence hve to reflect the relevnt options nd be coherent with the criteri of functionl nd sptil orgnistion of the project in question. - Evlution of the proposition: it includes both personl nd collective ssessment of proposition. The content nd the scheduling of these ctivities re different following the type of design. We therefore propose to modelize distributed processes of design in rchitecture in the form of mcro process which progression is sequentil nd itertive (figure 3). Figure 3. A mcro model of distributed design processes in rchitecture. Figure 2. Distributed design nd points of synthesis. Hnser, (2003) ccording to (Turk et Al. 1997). The questions to which we im to bring nswers in this rticle concern the specific needs necessry for: - ensuring the steering nd coordintion tsk of the distributed design processes - ensuring coherence between ll the proposed solutions tht re generted by the integrtion of the points of view. In order to stisfy these needs we propose to modelize the distributed processes on the bsis of ctivities lredy identified. This whole set of ctivities serves s common core for ll the observed design projects. In fct, we find these ctivities in the intervention of ech ctor of design either explicitely or implicitely. These ctivities cn be clssified in three types: nlysis, proposition nd evlution. Independently on his entry point in the distributed processes mcro model, n ctor hs the possibility to undergo the three phses in ny order nd s long s it is necessry. In this mnner, n rchitect, for instnce, cn initite rchitecturl design by directly mking technicl proposition (for exmple volumetry nd envelope proposition) intuitively before nlyzing the progrm nd the site nd then go through the evlution phse. This model represents the predictive prt of the steering ctivity. Nevertheless, in prctice, wht llows the pilots to prevent dysfunctions remins their bility to rect quickly nd their globl nd trnsversl vision of design. In order to llow the pilot to monitor the right development of the distributed processes of every ctor involved in the design, we introduce the notion of debugging inspired from computer science. Debugging is the process through which dysfunctions (bugs) re detected, loclized nd corrected. Applying it to design in rchitecture, we propose to bse this notion of debugging on brekpoints in order to suspend processes or to inform the pilot when problems occur. These brekpoints represent the plce nd moment where every ctor of the process cn send n inquiry to the pilot in order to trigger rections to unexpected situtions. These rections to the unexpected situtions cn considerbly modify the building to design or 297

hmper the good development of design processes. They lso represent the rective prt of the steering ctivity. In figure 4 herebelow, the brekpoints (red dots) re positioned on the trnsition mong ctivities. They im to detect problems before committing oneself in the following ctivity. other hnd s the expression of solution for the encountered concern sitution. Bsed on these two concepts, we cn synthesize the content nd the principle of use of the brekpoints by the following process (figure 5). new Concern sitution Assign to pilot new concern sitution Assign to Aimed sitution definition group new Aimed sitution Assign to chosen ctor Problem nd solution principle Principle defined solution Principle Not defined nd modifiction Actors ctivities proposed modifictions Assign to Pilot Aimed sitution NO: new principle Figure 4. A mcro model of design processes steering in rchitecture. Pilot ctivities yes solution Figure 5. Process of the principle of use of the brekpoints. In order to formlize the concept of brekpoints, we ssocite it to two concepts tht re nrrowly linked, generlly implied, nd omnipresent in design projects: the concern sitution nd the imed sitution. - The concern sitution cn be defined s configurtion of project, t given time, tht does not llow continuous nd effective progression towrds the definition of the building to design. It is n obstcle to the progress of the project. It cn lso be considered s set of correlted prmeters nd fcts tht led ctors of design to situtions they did not imgine or nticipte. Regulr, pre-estblished processes re usully undpted to these situtions. In prctice, encountered situtions re considered s problemtic/concern situtions only when they involve severl fields of the project. In the opposite cse, these situtions will be treted loclly nd will not trigger ny specific tretment. In order to be identified s concern sitution nd be treted consequently, given sitution hs to be declred t the pilot s level who mesures its importnce nd decides to lunch or not the problemsolving process. Through our nlysis of some design projects, we hve identified situtions tht led to the triggering of concern situtions. Some of them re the lck of informtion, the unfesbility of the study, the non-respect of regultory constrints, the non-respect of specifictions, incoherences between the propositions submitted by different ctors, nd incoherences between the rtefcts produced by different ctors. - The imed sitution is configurtion of the project tht elimintes the concern sitution when reched. It lso consists of heding towrds the definition or the reformultion of the problem. In this mnner, the ctors of design explicitely define which spects of the project or building will be concerned by this modifiction of the project configurtion. It lso llows them to identify in which fields they cn operte in order to rech the new configurtion of the project. This work is comprised in project steering ctivity nd therefore directly concerns the steering tem. One prticulrity of the imed sitution is tht it includes definition of the objective to rech s well s description of the method used to chieve it. In fct, the imed sitution is built nd stted in wy tht llows it to be. It describes the configurtion tht the project intends to rech but lso the mens to chieve it. It cn be described on one hnd s the construction of n identified problem tht needs to be solved nd on the In this process the pilot s role is to led ll the distributed ctivities in order to mke the project fesible. In wy, his/here role cn be itemized in 4 points: - To support current sttes nd design evolution: the pilot provides the control nd the led of the design, towrds the evolution of the solution, in order to mintin coherence in the building under design. - To integrte the ctors points of view: the pilot provides with double trnsltion. A trnsltion of the ctor knowledge in order to mke it vilble nd exploitble in the project, nd physicl trnsltion of its objectives nd its constrints on the building under design. - To set up coopertion: the pilot directs the ctivity of ech ctor in order to led them to converge towrds common witings. It ims to set up "concurrent" definition of single building in order to nswer ech ctor expecttions. - To come up with decision by tking into ccount project constrints nd surroundings. These decisions re tken during ction, nd re closely relted to the evolutions of the building nd the configurtion of the process. These decisions remin hrd to schedule ccording to well defined rodmp. With this intention we propose to develop n ssistnce tool for design process steering bsed on our mcro model of design process steering. 4 INSTRUMENTATION OF STEERING DISTRIB- UTED DESIGN PROCESSES IN ARCHITECTURE 4.1 Description of the principles Wht mkes the modeliztion prcticl is the fct tht it llows to determine the principles necessry to the steering of distributed design processes. The principles selected to ssist the steering of design processes re under implementtion in softwre ppliction tht bers the concepts of the proposed model. - Principle 1: effective steering requires to define the relevnt problem (to solve) nd stte it in n dequte fshion. In order to chieve this, file tht structures the definition of concern sitution helps formlizing the consequences of the problem tht thretens the design in progress. It lso llows to estimte the risks tht these consequences mke the project fce. The pi- 298

lot therefore hs relevnt bsis of nlysis in order to decide which problems re relevnt for solving nd how they will be solved (by phone, in meeting session, ccording to given procedure, etc.) (figure 6). A file describing the imed sitution then llows to clerly stte the problem by requiring definition of the objectives nd the implementtion frmework necessry to chieve them (figure7). - Principle 2: the evlution of solutions relies on n evlution file tht llows negocition between the pilot nd the concerned ctor. This mkes it possible to suggest modifictions nd vlidte them (Figure 8). - Principle 3: being informed of the progress of the design project requires the follow up of the sttus of the distributed processes. A dshbord llows the pilot to monitor the evolution of work nd to remin informed bout the concern situtions. He therefore monitors on one hnd which situtions hve been solved, re in process of being solved, or hve been dropped nd on the other hnd the progress sttus of the solving of imed situtions. Figure 8. Evlution screen. 4.2 A softwre rchitecture driven services for the design processes in rchitecture steering The softwre we propose to develop strting from our modeling ims to run nd to steer the design processes in rchitecture. With this intention we propose to bse our tool on Services Oriented Architecture (SOA) structured in three modules (Figure 9). - Modelling module: it is module bsed on grphic tool tht is esy to hndle by the pilot. It llows him to input the business processes of the different ctors (e.g. tsks nd their sequences, events, constrints, etc.) ccording to the mcro model. The modelled business processes will then be coordinted by the pilot. In order to ssist the pilot in this modelling, we propose business processes librry tht integrtes the experience of the ctors. These processes cn be customized (e.g. customized trnsition rules, missions, roles, events, tsks, etc.). Thus the pilot could drw from the processes librries in order to customize the ongoing process. - Processes execution module: it is module llowing the trnsformtion of the processes towrds n executble model, like BPEL (Business Process Lnguge Execution) (Andrews et l. 2003) or XML. This is chieved with the implementtion of n execution engine nd extension mechnisms of this engine by using Aspects-Oriented Progrmming (AOP) (Bchmendo nd Unlnd 2001). Thus, we propose the instlltion of dedicted engine bsed on lowerlyer-of-events oriented integrtion (e.g. Event Driven Architecture EDA). This will llow collbortion mong vrious ctors who cn be initilly humn nd in the utlimtely resources. - Services development module: it is qulity nd performnce supervising service of the design process in rchitecture (e.g. dshbord, lrm, dt hrvest services, etc.). It is therefore question of instlling the tools for collbortive services genertion. These tools for utomtic genertion will be bsed on expertise nd lredy existing tools like mnufcture softwre. (Prigot et l. 2002). This system ims to be used minly by the pilot. However some screens cn be used by ll the design tem members in order to declre concern situtions, submit solutions, or trck solving ctivities stte. In this wy ccess rights cn be ssigned ccording to the ctors profile. Figure 6. Concern sitution nlysis screen. Figure 7. Aimed sitution definition screen. 299

Figure 9. A softwre rchitecture to steer design processes in rchitecture. 5 CONCLUSION Through our pproch, we hve presented model for steering distributed design processes in rchitecture. The pplictive objective of our reserch is to llow the pilot of the design processes to hve globl view of the entire distributed design processes, while reporting to him on its dynmics (concept of dshbord). The pilot therefore hs tool tht llows him to visulise the stte of the processes nd sub-processes in ny moment of the design process. Thnks to the proposed softwre ppliction, the pilot will be ble to mke the dequte decisions in order to rech the desired performnce. Moreover, this reserch will contribute to knowledge cpitliztion through the project informtion system. This will be chieved by compiling into experience librries ll the dynmics produced during the design processes in order to use them for future problem solving in similr situtions. REFERENCES Alexnder, C. (1971). De l synthèse à l forme, Essi. Ed Dunod, collection Asoect de l urbnisme. Pris Andrews et l. (2003). Business Process Execution Lnguge for Web Services version 1.1. Technicl report, BEA, IBM, Microsoft, SAP, Siebel Systems. Bchmendo nd Unlnd (2001). Aspect-Bsed Workflow Evolution. In Tutoril nd Workshop on Aspect-Oriented Progrmming nd Seprtion of Concerns. Lncster, UK. Drses & Flzon (1996). P. 1996. L conception collective: une pproche de l ergonomie cognitive. In Coopértion et conception. Sous l direction de G. de Terssc et E. Freidberg Octrès (eds). Toulouse. Hnser, D. 2003. Proposition d un modèle d uto coordintion en sitution de conception, ppliction u domine du bâtiment. Thèse de doctort en sciences de l rchitecture. INPL. Nncy Nidmrthi, S (1997). The significnce of coevolving requirements nd solutions in the design process, proceedings of ICED 97, Tmpere Prigot et l. (2002). Aspect nd xml-oriented Semntic Frmework Genertor: Smrt Tools. In M. vn den Brnd nd R. Lâmmel, editors, ETAPS 2002, LDTA workshop, volume 65 of Electronic Notes in Theoreticl Comuter Science (ENTCS), Grenoble, Frnce. Elsevier Science. Peñ, W. (1977). Problem Seeking. An Architcurl Progrmming Primer, CBI Publishing Brton Rynud, 2002. Cinq essis sur l rchitecture : études sur l conception de projets de l telier Zô, Scrp, Le Corbusier, Pei, Pris : L Hrmttn, 2002. 240p Schon, D.A. (1983/ 1994). Le prticien réflexif. A l recherche du svoir cché dns l gir professionnel. Les éditions logiques Montrél (Québec) Simon, H.A. (1992). De l rtionlité Subbstntive à l rtionlité procédurle. In Revue PISTES. Numéro 3. Trduction d un rticle pru dns un ouvrge collectif de S.F. Ltsis publié pr Cmbridge University Press in 1976 Turk, Z. Ktrnuschkov, R. Amor, R. Hnnus, M. Scherer R.J. (1997). Conceptul Modeling of Concurrent Engineering Environment. Collection Concurrent Engineering in Construction. Institution of Civil Engineers. London. Visser, W. (2002). A tribute to SIMON, nd some too ltequestions by Cognitive Ergonimist, proceeding of Interntionl Conference Les sciences de l Conception Lyon (Frnce) 300