Improving the software architecture design processby reusing technology-specific experience Glib Kutepov InformationSystems Development FraunhoferIESE Fraunhofer-Platz 1 67663Kaiserslautern [email protected] Abstract: Experience with particular technologies such as SOA, Cloud Computing, or Mobile Apps plays acrucial role when designing thearchitectureof asoftwaresystem. Beingaware of thechallenges usuallyencountered when using atechnologyand knowinginadvance how to resolvethese challenges can dramatically increase thequality of thesoftwaresystemarchitectureand decrease thedesigneffort. However, it is not always astraightforwardprocesstocollect the necessaryarchitectural experience,persist it on theorganizational level,and reuse it in theright way, especiallyifthe technologyis new. This paper describes how architecturedesignprocesses can be improved by supplementing them with architectural experience relatedtoaparticular technology.The wayarchitectural experience canbedescribed usingarchitectural scenarios andsolutionpatterns is explained andpersistedinthe architecturedesignprocess. Theefficiencyof the approach is validated with thehelpofacasestudy. 1. Introduction Consider a modern software development organizationthat develops its products with a strong focusonthe architecture. During the software architecture designprocess, the architect identifies keychallengesthat influencethe current system architecture and findsappropriate solutions.Thistaskiscarried out successfully because the architect bases hissystemonfamiliar,wide-spread IT technologies whose caveatsare well known to himorher.Fortunately, theworld of technology does notstandstill: Everyday,some newtechnology appears on the IT scene, which opens up newopportunities: maybe an alternative or an improvement to an existing technology,oracompletelynew technological paradigm,suchas SOA,Cloud Computing, or Mobile Applications.The organizationmay have to incorporate the newtechnology in its architectural practices in ordertostay competitive.Initially, the identificationofchallenges andsolutions will be less effective than before due to a lack of knowledge on the architect’s part regarding the newtechnology.Thismay increase thetime needed forarchitecture design anddecrease quality. However, with time the processwill become more effective andthe qualityof the product will improve. This will be mostly due to the tacit experience of the software 83 architect. Havingone person as the only source of this specific knowledge may jeopardize all the benefits of adoptingthe newtechnology.Thus,awaytosystematically collect andpersist the architect’sexperience in an organization has to be found. Hofmeister et al. [HN99] suggest performing similar activities before designingevery architectural view andrefer to these activities as “Global Analysis”. The core of “Global Analysis” is the identificationoffactor-strategy pairs, which are then applied in the actual view design phase. “Factors” represent the challengesorproblemsthat may influencearchitecture design and“strategies” representsolutions to them.Weseesuch pairsasaneffective tool fordescribingand persisting technology-specific experience. In this paper, we propose an approach forsystematicallycollecting, describing, and reusing such pairsinthe context of the architecture design process. The pairsare collected with the help of project post-mortems, while thefactors are described in the form of architectural scenariosand strategieswithsolutionpatterns.Furthermore,several scenariosare provided forusing such pairsinthe architecture designphase, thus operationalizingthe experience. The paperisstructuredas follows: After an introductory part, the pros andconsofwell- known techniques forpersistingarchitectural experience are described in section2.In section3,the details of the approach are given. Ourexplanationisbased on Fraunhofer ACES -the architecture designprocess [KK11] used forsoftware architecture designat FraunhoferIESE. Section4showshow we instantiated ourideafor the activelyevolving technology of mobile “apps” andparticularly its applicationinthe business domain.The “Initial Validation” chapter features a case studythat was performedinorder to take first stepstowards the validationofthe approach.The section“Conclusion” concludes the paper. 2. Related Work The aim of this paperistoshowthe reader hownew technology canbe efficiently adopted in the architectural practices of software engineeringcompanies.The main challenge in adoptinganew technology is the lackofstructuredorganization-wide architectural experience that canbe reused in an operationalmanner. Thus,our goal is to find a waytocollect andpersist this experience inside the architecture designprocess. Well-knownprocessessuchas ADD [BK01] or BAPO/CAFCR[Sm03] provide solid guidancefor architecture designbut, unfortunately, do not offerany facilities for collectingand persisting architectural experience forfurther reuse.Thismeans that such facilities have to be either invented or created by combiningprior works. We examined relatedworkonexistingsolutions to the following challenges: ways to collect architectural experience andwaystopersist it within thearchitecture design process. One of the prominent techniques forcollectingexperience is “Project Postmortems” [Ti90].How this technique was used forour purpose will be explainedinsection3.2.A popular approach forpersistingarchitectural experience are domain-specific software architectures [Tr95].Researchershave developedabodyofvarious methodologies for 84 approachingsucharchitectures, rangingfromguidelinesand recommendations for creatingdomain-specific architectures [AA07] to proposals of ready-to-use reference architectures [ZL00],[DN08].Unfortunately,the applicabilityofthese approaches is limited to particular well-scopedbusinessdomains,which is not ourcase. Ourtarget is a technology that canhavemultiple applicationareas; therefore it wouldbe tooeffort- consumingand inflexible to model it with a set of software components. Alternative approach fortechnology-specific experience persistenceare pattern languages, such as [BM00],[GH94],orthe factor-strategy pairsof[HN99].Although patternlanguages are a very effective approach,we feel that they lackprecision in describingarchitectural problems: In [HN99],the descriptionofthe factor (problem)is rather unstructured, andinthe “Gang of Four” work [GH94],the problemsare described in terms of object-oriented programming rather than architecture.Inthispaper,these drawbacksare mitigated with the help of architectural scenarios[KB94], [DF99]. It is always a challenge to find the right detail level fordescribingthe solutionpart of a pattern. Forexample, the detail level of [GH94] patterns differs from ours: Unlike the implementationlevel used by [GH94],we describe patterns on the architectural level, whichismore abstract andcan lead to multiple implementations; hence, it is a complex task to describe a patterninsuchawaythat it givesthe architect solid guidance without prescribingany particular implementation. Therefore we propose ourown generic template forsolutiondescriptions. The next sectiondescribes howthese approaches were combined in ordertomitigate the drawbacksofeachone anddevelopthe needed technique. 3. Approach This sectioncontains a step-by-step descriptionofour approach forpersisting technology-specific architectural experience in the architecture designprocess. 3.1Baseline Architecture Method As a basis forthe technology-specific architecture designprocess,we take Fraunhofer ACES [KK11] – the architecture design processactivelyusedbyFraunhofer IESE. The inputtothe processare system requirements obtainedinprevious phases of the software system engineering process, andthe output is,among others,aset of documented architectural viewsofthe system.ACES is a comprehensive processthat guides architects in all theiractivities, startingfromthe identificationofstakeholdersand the understanding of architectural driversvia architecture realizationall the waytothe documentationand validationofthe system architecture produced. The approach consists of twoparts: core competence – the main part, whichincludesdomain- independent sub-processes forarchitecture design, and domaincompetencies – an optional part, whichcontainsdomain-specific static experience artifacts relatedtothe architecture design. The structure of Fraunhofer ACES is showninFigure 1. 85 The “domaincompetencies” (inour case rather “technology competencies”) part of FraunhoferACES foresees threecrucial experience collectionareas - challenges, solutions,and technologies,which represent a similar concept as the factors andstrategy pairsofthe “Global Analysis” of [HN99].Challengescorrespondtofactors and solutions correspondtostrategies. The technologies area is used forpersisting informationabout COTS solutionsthat arerelevant forthe considered domain. Solutions canaddress technologies in their description. This paperfocuses on challengesand solutions in architecture design; therefore the technology part of ACES is not addressed here.ACES provides experience areas, but gives no concrete guidelines on howto collect this experience or howtorepresent it. Figure 1: Fraunhofer ACES In ordertoreuse architectural experience during the architecture designprocess, we examined twosub-processesofthe FraunhoferACES core competencies: ASR[KK11] (ArchitecturallySignificant Requirements) – the processanalyzing stakeholders and elicitingrequirementsspecificallyrelated to the architecture,and DMM [KK11] (Design, Modeling, Migration)