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) – the processfor designingthe actual system architecture based on the elicited requirements.Insections 3.2 – 3.5, we describe howone canfill out the “domaincompetencies” part of ACES with the necessaryexperience andthenreuse it in ASRand DMM processes.

3.2Eliciting Challenges andSolutions

The idea of collectingexperiences by identifyingchallenges of a particular area is not newand hasalready been proposed by [DF99].However,the problem is that [DF99] did not specifywhere to get these challenges from andhow to describethem. Knowledge about challengesregarding a particular technology comesfromexperience; therefore, an

86 experience source is required.Weconsiderthe best experience source to be pilot projects implemented with the current technology.Therefore,several initial projects have to be performedduringwhich theexperience base is filled.After each project, a project postmortem[DD05],[Ti90]has to be performedinorder to elicit tacit architectural experience residinginthe mind of the architect, or in the artifactsofthe project, such as documentation, code etc. Postmortemsare techniques that allowfor systematically examiningthe completed project forthe purpose of elicitingpitfalls to avoidinthe future,and best practices to be reused. We use postmortems forelicitingchallenges that recurwhenapplyingaspecific technology.We performproject postmortemsinthe form of interviewswitharchitects. These interviewsconsist of the following steps:

1. Find out challenging architectural scenarios.Our experience in designing software architecture showsthat most of the challenges are usuallyrelatedto the quality(non-functional) requirements of the architecture. In Fraunhofer ACES [KK11], qualityrequirementsare described in the form of architecture scenarios[DF99].Thus,all that architectsneedtododuringthe post-mortem meetingistopoint out architectural scenariosthat in their mindsdonot only represent a unique challenge met in one project, but that reflect the crosscutting challenge of the current technology. More details on describingchallenges with architectural scenarioscan be foundinsection 3.3.

2. Check forduplicates.Check if this architecturalscenarioalready exists in the experience base. If not, addit; then checkifthe relatedsolutionhas been refinedorimprovedinthe current project. If yes, supplement the existing solutionwiththe newdetails.

3. Elicit and describe the solution.Anarchitect needstoelicit the solutionfor the identified challenge from the project documentationand describe it accordingto the solutionpatterntemplate giveninsection 3.4. Asolutiondescribed with the solutionpatterntemplate is then addedtothe experience base.

4. Retain traceability.We tracerelationshipbetween architectural scenariosand solutionpatterns with the help of a traceabilitymatrix; therefore this matrix has to be updated everytime a change is made to the experience base.

The artifacts elicited in this phase are: aset of architectural challenges described using the architectural scenario template presented in section3.3,aset of solutionpatterns described usingthe template presented in section3.4,and a traceabilitymatrix,which establishes the relationshipbetween both.

3.3Describing the Challenges with Architectural Scenarios

Qualityrequirementsfor software architectures are described in ACES with architectural scenarios[KB94].According to [RW05] - “An architectural scenario is acrisp, concise descriptionof asituationthat the system is likely to face,along with adefinitionof the response required of the system”. Initially, architectural scenarioswere used as a tool for software architecture evaluation [KB94],but later this approach has also turned out to be

87 suitable fordescribingquality requirements forsoftwarearchitectures [DF99].The template showninFigure2canbe used fordescribingarchitectural scenarios. In orderto clarifythisissue better,anexample of an architectural scenario is giveninsection4.

Figure 2: Architectural scenario template

3.4Describing Solutions

Following the idea of patternlanguages [BM00],[GH94],weuse “Solution Patterns” for the descriptionofour solutions.The crucial point in describingsolutionpatterns is the level of detail. On theone hand, the more details thesolutioncontains, thebetter.Onthe otherhand, each additional detail inducesacertain assumptionregarding the context in whichthe system is developed, whichmakes the solutionless applicable. Developers of patternlanguages usetemplates fortheir descriptions [GH94].It is good to use strict templates when thecontext of an applicationiswell known, as in thecase of pattern languages forspecific domains.Inour case,we consider a whole technology that canbe applied in various ways.The template fordescribingthe solutionmust therefore be sufficiently detailed to be understandable andimplementable, andat the same time remain applicable when used in different contexts.Therefore we keep oursolution patterntemplate simple andrather base it on examples than on principles, resulting in more freedomduringdescription andsubsequent application. The template consists of the following parts:

1. Textual description. Aclear descriptionofthe waythe current patternresolves the challenge described in the architectural scenario.The descriptionmust include pros,cons, restrictions,and knownuses of the solution. Should the challenge be resolved by employingCOTS components (frameworks, platforms etc.), a linktothiscomponenthas to be specified.

2. Structural Diagram.Astructural view of the system that supports the current architectural scenario.

3. Behavioral Diagram.Aninstance(s)ofinteractionamong thecomponents of the system,which supports the current architectural scenario(s).

3.5Enrichingthe Process

Once the static experience artifacts(challenges andsolutions)have been collected and described appropriately, they must be included in the architecture designprocess and

88 provide the usersofthe processwithusage guide. How artifacts are included into FraunhoferACES andthenreusedissketchedinFigure 3.

Figure 3: Technology-specific Fraunhofer ACES We guide userswiththe help of reuse scenariosthatdescribe howexperience artifacts shall be applied.Three keyreuse scenarios(the numbers of reuse scenarioscan be matchedtothe numbersinFigure 3) that mayoccur when designing a software architecture with the technology-specific FraunhoferACES are:

1. Using architectural scenariosfor finding missing requirements. Thereare certain qualityrequirementsthat are very likely to appear in the context of a particular technology.The customer might first overlook these requirements andcome back to them only in a later phase of the project when anychange is costly.Therefore,the architect will find it handytouse typical architectural scenariosofthe technology as a checklist forfinding missing requirements.

2. Using architectural scenariosasinput for the architecture design process. Architectural scenariosaccuratelydescribe the challenge that needstobe resolved by thearchitecture of aparticular software product. Ideally, the architecture scenario will be linkeddirectlytothe solutionpattern(seepoint 3) that resolves it; otherwise, itsprecise descriptionwill help the architect to significantly narrow the solution searchdomainand will later on serve as a basis forassessing the selectedsolution.

3. Applying solution patternsfor quality driven design. Based on the architectural scenariostobe satisfied,anarchitect selects solutionpatterns to be implemented.Using proven solutionpatterns will make thearchitecture design processmore efficient andwill increase the qualityofthe resulting product.

89 4. Application Example

In ordertocollect initial evidence regarding the effectivenessofour approach,we apply it to one of the technologies currently under research at Fraunhofer IESE. Due to the current trendtowards ubiquitous computingand the growingneedfor mobile support for enterprises, we decidedtochoose mobile apps as ourtarget technology andscope it to the business domain of the application(excluding, e.g.,the gaming domain).

The challengesencountered here are mostly relatedtothe fact that business-oriented mobile applications have the same qualityrequirementsas commondesktop applications,but runinatotallydifferent environment. These applications sufferfrom Internet connectivity problems, high powerdependency, andother challenges brought on,for example, by the specifics of the operatingsystemorbyaparticular application store.Therefore it is absolutely necessary to be aware of the typical challenges of this technology andmake sure they are coveredwiththe system architecture.

4.1Identified Challenges

After conducting severalpilot projects at Fraunhofer IESEand performingtheir post- mortems(section3.2), we identifiedasetofchallenges relatedtomobile business applications.Some of these challenges are presented in the table in Figure 4. The second andthird columnsofthe table represent thename of thechallenge andarchitectural scenario that describes it. The first column classifies the challengesintochallenge areas.

Figure 4: Challenges of Mobile BusinessApplications Oneprominent challenge formobile apps is deployment. In contrast to desktoporweb applications,the standard facilityfor deployingappsisan“appstore”. An “appstore” is completely proprietaryentityand lies beyond the developers’ control: There is no guarantee that the application will pass the internalapproval processand that deployment will be allowed. Furthermore, the durationofthe approval processcannot be foreseen anddeployment time cantherefore not be guaranteed to the customer. Controlled deployment is clearlyacrucial requirementfor the mobile application developmentorganization, which is legally obliged to guarantee software defect removal within a certaintimeframe.The architectural scenario “Rapid ApplicationDeployment” in Figure 5describes aconcrete instance of acontrolled deployment challenge.Having such precise descriptionallows an architect to easily evaluate the suitabilityofthe proposed solutionbysimplyplaying the scenario.

90 Figure 5: Example of an Architectural Scenario (“RapidApplication Deployment”)

4.2Identified Solutions

Based on theexperienceobtained during thepilot projects,wewere also able to find appropriate solutionpatterns forthe identified challenges. In Figure 6, thereadercan find a traceabilitymatrix that establishesthe relationshipbetween solution patterns and the architectural scenariostheyresolve. It canbe clearlyseenthat one patterncan resolve various scenariosand one scenario canbe resolved by multiple patterns.

Figure 6: Identified Solution Patterns In Figure 7, Figure 8, andFigure 9, an example of a solutionpatterndescribed according to thetemplate giveninsection3.4 is given. This patternisnamed “Deployment bypassingappstore” andresolves the architectural scenario giveninFigure 5.

Figure 7: Textual Description ("Deployment bypassingappstore")

91 Figure 8: Structural Diagram (“Deployment bypassingappstore”)

Figure 9: Behavioral Diagram (Architectural Scenario: "Rapid ApplicationDeployment")

4.3Initial Validation

This sectionfeaturesaninitial validationofour assumption regarding theimproved efficiency of the architecture designprocess andbetter qualityofthe endproduct due to the reuse of technology-specific experience during the architecture designprocess. Both pointsare hard to assess without a real project setting. However, a coarse validationof the efficiencyaspect canbe carried out with the help of a case study.

The case studywas designed as follows: We took an architecture document of one of the mobile business applications developedat ourinstitute, designedachange request forit, andasked threeFraunhoferIESE employeeswithdifferent levelsofknowledge in software engineeringand onlygeneral knowledge in mobile systemstoperform several tasksrelatedtothischange request with the help of themobile technology experience persisted in FraunhoferACES. The experience base includedacatalogwith21 architectural scenariosand 22 solutionpatterns (partiallyshown in Figure 6) identified at FraunhoferIESE usingthe approach described in section3.The participants hadto

92 imaginehavingtoimplement the change request andthushad to redesignsome of the system structures accordingly. They were askedtorecordthe time they spent on:

1. Finding the relevant architectural scenario andsolutionpattern in the catalog;

2. Readingthe pattern, understanding howtheywould applyit forthe given system architecture, andsketching modified structural andbehavioral viewsof the system.

Accordingtothe results, the participants reusingexperience artifactsneededfive minutesonaverage to find thematching architectural scenario andsolutionpatterninthe catalog. In ordertounderstandthe applicationofthe chosen patterntothe current system architecture andsketch modified views, the participants needed 18 minutes on average.

The participants were asked to compare their experiencesusing the extendedACES approach with usingthe original approach.Their assessment was that givenFraunhofer ACES without technology-specific experience artifacts, they wouldrequire 2.5hours on average to come up with their ownsolutionfor the givenproblem.The use of the extendedapproachthusreduced the time spent to lessthan20%.

However, these results are basedonlyonone case andonthe subjective judgment of the case studyparticipants.Obviously,amore thorough validationneeds to be done regarding the proposed approach in ordertoenable drawingmore concrete conclusions about its efficiency.It will be necessarytoperform similar case studies or full-size experimentswhile varyingfactors such as number of participants,level of participants’ experience,size of the catalog, experiment context, andtypeoftasksfor the participants. Also,waystovalidate the qualityaspect of the resulting product have to be found.

5. Conclusion

In this paper, we have shownawaytocollect andpersist technology-specific architectural experience in an organization. Reuse of this experience during follow-up projects is supposed to increase the efficiencyofthe software architecture design process andthe quality of the resultingsoftware product. Furthermore, storedexperience will loweranorganization’sdependenceonhuman resources.

We described howtechnology-specific experience canbe persisted andreused beneficiallywithinthe architecture design process. Forexperience persistencewe used challenge-solutionpairs. We described a method forcollectingthese pairsusing project postmortems andgave templates fortheir precise descriptionwitharchitectural scenarios andsolutionpatterns.Finally, we gave an example of atypical challenge-solution pair forthe technology of mobile apps anddescribed it usinggiven templates. Acase study served as coarse validationand allowedustodrawfirst conclusions regarding the efficiency of a software architecture design processsupplemented with technology- specific experience artifacts.Althoughthiscase studyshowedanoticeable increase in

93 efficiency,it is tooearlytodrawfinal conclusionsinthisregard. A more thorough validationofthe approach hastobe performed.

References

[AA07] EduardoSantanadeAlmeida,AlexandreAlvaro, Vinicius CardosoGarcia, Leandro Nascimento,SilvioLemos Meira, Daniel Lucredio: Designing Domain-Specific Software Architecture(DSSA): Towards a NewApproach.WICSA'07 (2007) [BK01] LenBass, Mark Klein,and FelixBachmann, "Quality Attribute DesignPrimitives and theAttribute Driven DesignMethod,"the 4thInternational Workshop on Product Family Engineering. Bilbao, Spain, 3-5October,2001. [DD05] KevinC.Desouza, Torgeir Dingsøyr, Yukika Awazu: Experiences with Conducting Project Postmortems: Reports vs. Stories andPractitioner Perspective. Proceedings of the38thHawaiiInternational Conference on SystemSciences (2005) [DF99] Jean-MarcDeBaud, Oliver Flege, Peter Knauber: PULSE-DSSA-AMethodfor the Development of Software ReferenceArchitectures. Internal publication: Fraunhofer Institute for Experimental Software Engineering(IESE); 1999 [DN08] Serhan Dagtas,Yuri Natchetoi,HuaiguWu, Louenas Hamdi: An Integrated Lightweight Software Architecturefor Mobile BusinessApplications. SeventhWorking IEEE/IFIP Conference on Software Architecture (2008) [GH94] E. Gamma, R. Helm,R.Johnson,and J. Vlissides. DesignPatterns: Elements of Reusable Object-Oriented Software.AddisonWesley, Massachusetts, 1994. [HN99] Christine Hofmeister ,Robert Nord ,Dilip Soni.AppliedSoftware Architecture1999, ISBN-10: 0-201-32571-3 [KB94] Kazman,R.;Bass,L.;Abowd, G. ; Webb, M. SAAM: amethodfor analyzingthe properties of software architectures. Software Engineering, 1994.Proceedings. ICSE- 16.,16thInternational Conference on. [KK11] ThorstenKeuler, Jens Knodel, Matthias Naab; Architecture-CentricSoftware and Systems Engineering; 2011; WhitePaper;Fraunhofer Publica [Mi11] MobileIronVirtual Smartphone Management Platform; http://www.mobileiron.com/en/smartphone-management-products/smartphone- management-for-enterprise-mobility [RW05] N. Rozanski, E. Woods. Software Systems Architecture: WorkingWithStakeholders UsingViewpoints andPerspectives. 1995. ISBN: 978-0-3217-1833-4 [Sm03] Jürgen K. Smith “The Building BlockMethod”, Philips Research Laboratories, Eindhoven.ISBN 90-74445-58-6; 2003 [Ti90] Mark J. Tiedeman: Post-Mortems-Methodologyand Experiences;IEEE journalon selected areas in communications, vol. 8. no. 2.February 1990 [Tr95] W. Tracz, Domain-Specific Software Architecture(DSSA) Pedagogical Example, ACM SIGSOFT Software EngineeringNotes,Vol.20, No.03, July,1995, pp.49-62. [ZL00] Deming Zhong,Bin Liu, Lian Ruan: TheDomain-Specific Software Architectureof Avionics TestingSystem. 24thDigital Avionics Systems Conference (2000)

94