ArchitectureImprovementMethod
MethodicalImprovementofSoftwareSystemsand–Architectures
Dr.GernotStarke
http://aim42.org
Thispaperoutlinesaim42,thesystematicandpragmaticapproachtoimprovesoftwaresystems
andarchitectures.aim42worksiterativelyinthreephases(analyze,evaluate,improve)
supportedbycrosscuttingactivities.Foreachphase,aim42proposesprovenandestablished
practicesandpatterns.Themethodaddressesbothbusinessandtechnicalstakeholdersof
softwaresystems.aim42reliesonveryfewcoreconcepts,makingthemethodeasyto
understandandimplementinpractice.aim42doesnotrequirespecifictoolsupportandis
thereforecompletelyvendor-agnostic.
aim42isdevelopedbyanactivecommunityinopen-sourcestyle,backedbyextensiveindustrial
experienceandscientificresearch.Ithasproventoworkundertimeandbudgetconstraintsin
variousindustries.
V 2.0 – June 2017
1Introduction
Real-worldsoftwaresystemsregularlyneedtobemaintainedforvariousreasons,oftenunder
severebudgetandtimeconstraints.Softwareownersandotherstakeholdersoftenprioritize
newbusinessrequirementshigherthanimprovementofinternalsoftwarequality.Overtime,
thisleadstoreducedmaintainability,coined“softwareerosion”or“softwareentropy”.
Especiallyincompetitivemarkets,investmentinexistingsoftwareisoftendrivenbyshorttermbusinessgoals.Long-termgoals,likemaintainabilityorunderstandabilityareneglected.
Improvementsofsoftwarearchitecturesseemtoconflictwiththeseshort-termbusinessand
budgetrequirements,asbreak-evenisexpectedwithinshorttimespans.
Keepingsoftwaremaintainableovertimerequiressubstantialinvestmentininternalqualities,
likeconceptualintegrity,architecturalstructuresandcrosscuttingconcepts,propercoupling
andcohesion.
Thesystematicapproachofaim42supportsevolutionandimprovementofsoftware
architecturesandinternalquality.aim42helpstechnicalandmanagementdecisionmakersto
properlycompromiseshort-termbudgetrequirementswithlong-terminternalarchitecture
quality.
aim42 – systematic software evolution and improvement - Whitepaper
1.2ConceptualIntegrityRequiresAttentionandBudget
Solvingsimilarproblemsshouldbehandledinsimilar,preferablystandardizedwayswithina
softwarearchitecture.Thisconceptualintegrityforthingslikepersistence,transactionhandling,
encryptionorgraphicaluserinterfaceconstructionprovidesasolidfoundationfor
maintainability,understandabilityandlongevityofsoftwaresystems.
Conceptualintegritycaneasilybeviolatedwhensoftwareischangedundertimeandbudget
constraints.Especiallyinmediumorlargeteams,communicatingtheappropriateconcepts
requireseffortinformofdocumentationoreducation.Commercialprojectsoftenneglector
abandonthiscommunication–resultinginviolationsofconceptualintegrity,risky
technologicaldiversionandinconsistentimplementation(calledsoftwareentropyor
detoriation)–resultinginseverelossofmaintainabilityandcorrespondingincreasein
maintenanceandoperationalcostaswellasaprolongedtimetomarket.
Withaim42youbalanceimprovementand„dailybusiness“:Youwillbeabletocontinously
delivernewbusinessfunctionality(„features“)–yetsystematicallyanditerativelyimprove
yoursystem.
1.3OrganizeImprovementsinPhasesandIterations
aim42 takes a phased-iterative approach and differentiates
between problem identification during the analysis phase,
problem evaluation and problem resolution during
improvement. Solution approaches or improvements are
identifiedcontinouslythroughoutthephases(seeFig.1).You’ll
findadditionaldetailsonthesephasesinsection2.
Beforeanyimprovementactivityisundertaken,therelated
issuesandimprovementapproachesareevaluatedwithrespect
totheirestimatedcost,benefitandrisk–activelyenablingnon- Fig. 1. Iterative and Phased Model of
42
technicalstakeholderstoargueaboutprioritiesandbusiness
aim
value.
1.4RelyonEstablishedPracticesandPatterns
V 2.0 – June 2014
aim42reliesonseveralestablishedpracticesandpatternswhichhavebeenusedthroughout
softwareindustryforseveralyears.Arrangingthoseintheiterativephasedmodelisthe
innovativeideaoftheaim42method.
Inthispaper,practiceorpatternnamesaresetincapitals,likeQUALITATIVEANALYSIS.
Software Architecture Improvement - Whitepaper
2AnOverviewofMethodicalImprovement
V 2.0 – June 2014
Tosuccessfullyapplyaim42youshouldtaketoheartafewfundamentalprinciples:
• Explicitelydistinguishbetween“problems”(issues)and“solutions”(improvementoptions)
• Onlyfixproblemsifyoucanidentifyfinancialorbusinessreasonsforthisimprovement.
Neverchange„justbecauseyoucan“(evenrefactoringsshouldbeperformedwithaclear
andexplicitpurpose).
• Verifytheoutcomeofeverychange:Ensureeverychangeachievedthedesiredresults.
• Striveforfastfeedbackonallchanges.
The aim42 approach to architecture and system improvement (roughly) consists of the
followingsteps(whichwe’lllatermaptothethreecorephasesofaim42:
1. Collect all issues you can identify in a predefined time-box within the system, its
operation or development environment and the associated organization. Practices like
QUALITATIVEANALYSIS,SOFTWARE-ARCHEOLOGYorSTAKEHOLDER-INTERVIEWsupportthisstep.
ARCHITECTURALUNDERSTANDINGisanimportantside-effectoftheseactivities.
2. EvaluatethoseissuesusingESTIMATE-ISSUE-COSTwithrespecttoitsone-offorrecurring
cost.
3. Someproblemshidetheirrealcauses–useROOT-CAUSE-ANALYSIStoidentifythose.
4. Togetherwithtechnicallyknowledgeablestakeholders,e.g.softwarearchitects,COLLECTOPPORTUNITIES-FOR-IMPROVEMENT, which resolve the problems or causes. Note the
potential m:n relationships between issues and improvements: One issue might need
morethanoneimprovement,oneimprovementmightsolvemorethanoneissue.
5. Improvements also need to be evaluated or estimated with respect to their costs,
ESTIMATE-IMPROVEMENT-COST.Thebenefit(akabusinessvalue)ofanyimprovementisthe
costoftheassociatedproblemorproblems.
6. The comparison of issue-cost (== benefit) and improvement-cost provides valuable
decision support for technical and business stakeholders about which parts of the
softwarearchitectureorrelatedprocessesshallbeimproved.
aim42 works in iterative manner: The evaluation of issues respectively improvements might
changeovertime–reflectingmoderndevelopmentpractices.RegularchecksofISSUE-LISTand
IMPROVEMENT-BACKLOG ensure their up-to-dateness. The three phases (analyze, evaluate,
improve)areaccompaniedbythecrosscuttingplaningandmanagementactivities.
YoufindanoverviewofthedetailedactivitiesofeachphaseinFigure2.
Software Architecture Improvement - Whitepaper
V 2.0 – June 2014
Figure2.ThreePhases
Software Architecture Improvement - Whitepaper
3AnInformalDomainModelforArchitectureImprovement
Whendiscussingmethodical
improvement,acommon
terminologyfosters
understanding.
Youfindtherequiredtermsinthe
adjacenddiagramasasimple
domainmodel–showingthe
mostimportantconceptsand
theirrelations.
Pleasenotethem:nrelation
betweenIssueandImprovement:
Fig.2.SoftwareArchitectureImprovementDomainModel
Asingleissuemighthavemorethanoneopportunitiesforimprovement(orsolution),andone
improvementmightsolveoneorseveralissues.
Issue
Mightbeproblem,issueorfaultwithinsystemorprocessesrelatedtosystem
(e.g.management,development,administrativeororganizationalprocess)
Cause
Fundamentalreasonforoneorseveralproblems.
Improvement
Solutionorcureforoneorseveralproblemsorcauses.
Cost(ofissue)
Thecost(inmonetaryunits,e.g.Euroor$)oftheproblem,relatedtoa
frequencyorperiodoftime.Forexample–costofeveryoccurrenceof
problem,orrecurringcostperweek.
Cost(ofimprovement) Thecost(inmonetaryunits)oftheimprovement,tacticorstrategy.
Risk
Potentialproblemorissue.Remediescanhaveassociatedrisks.
4IterativeandPhasedModel
Improvementshouldbeacontinuousprocess,whereidentification,evaluationandresolution
of problems should be repeated as long as appropriate business value can be created by the
improvement.aim42supportsthisiterativeapproach–seefig.1.
4.1Analyze:IdentifyIssuesandCreateArchitecturalUnderstanding
Theanalyzephaseconsistsofthecollectionofissues,problems,risks,deficienciesand
technicaldebtwithinthesystemanditsassociatedprocesses–pluscreatingARCHITECTURALUNDERSTANDING.Focuswithinthisphaseliesonfindingissues.Inaddition,oneshalldevelopand
documentanunderstandingofinternalstructures,concepts,architecturalapproachesand
importantdecisionsofthesystem.
V 2.0 – June 2014
4.2Evaluate:EstimateCostandBenefit
Duringtheevaluatephase,thevalueofissuesandimprovementsinbusiness-relatedterms,like
costoreffortshallbeestimated.Suchestimationresultsincomparabilityofbothissuesand
improvements,leadingtotransparentprioritization.
Software Architecture Improvement - Whitepaper
Fromourexperiencewithinvariousindustries,domainsandtechnologies,thispartofaim42is
mostoftenneglectedwithinsoftwaremaintenanceactivities–asitrequiresacombinationof
technicalandbusinessskills.EstimationneedsEXPLICIT-ASSUMPTIONSabouttherelationbetween
technicalproblemsorremedieswith(business-related)effects,mainlycostandeffort.
Developmentteamsandtechnicalmanagementoftendisliketophraseappropriate
assumptions.
4.3Improve:MoreThanJustRefactoring
Withintheimprovephase,improvementsareappliedtothesystemorassociatedprocesses.
Rigorousfeedbackneedstobegatheredtocollectresultsoftheseimprovements–dueto
potentialsideeffectsonotherissuesandimprovements.
Duringimprovementofsystems,architecturaldecisionsneedtobemodifiedoradjusted–
resultingforexampleinchangestodatastructures,technicalinfrastructure,required
middleware,frameworksorthird-partyproducts.Thosemodificationssometimesrequire
fundamentalchanges,morethenjustrefactoring.
4.4CrosscuttingActivities:KeepISSUE-LISTandIMPROVEMENT-BACKLOG
Althoughaim42requiresnoformalismorformaldocumentation,twodeliverablesshallbe
maintained,theISSUE-LISTandIMPROVEMENTBACKLOG(seeFig.3).Inthesenseofleanandagile,
thoseshouldbekeptintheleastformalmanneracceptableforthegivencontext:
1. ISSUE-LISt: contains all currently identified issues, together with their evaluation and
linkstoappropriateopportunitiesforimprovement.
2. IMPROVEMENT-BACKLOG: contains a list of currently known opportunities for
improvement,togetherwiththeircost-andeffortestimates,potentialrisksandlinks
totheissuestheyhelptoresolve.
Fig. 3. Iteratively Collect and Evaluate Issues and Improvements
V 2.0 – June 2014
5ExamplesofPracticesandPatterns
aim42currentlycomprisesabout80practicesandpatterns.Ahandfulofthemshallbeapplied
crosscutting,therestassociatedwithoneofthephases.Theaim42methodguide[1],describing
the complete set of practices and patterns, is currently under active development [2]. The
followingisjustabriefexcerpttoshowthekindandnatureofthesepracticesandpatterns.
Software Architecture Improvement - Whitepaper
5.1PatternsandPracticesfromAnalysisPhase
BesidescreatingARCHITECTURAL-UNDERSTANDING,themainfocusoftheanalysisphaseliesin
identificationofissues,technicaldebtorriskswithinthesystem,itstechnicalenvironment,
relatedprocessesandorganizations.Tobeabletoidentifysuchproblems,oneneedsan
appropriateamountofunderstandingofthearchitecturalstructures,technicalconceptsand
sourcecodeofthesystemunderconsideration,gainedbySTAKEHOLDER-INTERVIEW,VIEW-BASEDUNDERSTANDINGorDOCUMENTATION-ANALYSIS.
• QUALITATIVE ANALYSIS: Determine risks of architectural approaches with respect to
requiredqualitygoals.Describedin[5],widelyusedinpractice.
• QUANTATIVE ANALYSIS: systematic analysis of source code metrics, e.g. size, coupling,
cohesion,andcomplexity.
• RUNTIME-ANALYSIS, DATA-ANALYSIS, ISSUE-TRACKER-ANALYSIS and DEVELOPMENT-PROCESSANALYSIS.
• PROFILING:measureresourceconsumptionofasystemduringitsoperation.
• DEBUGGING: Identify the source of an error or misbehavior by observing the flow of
executionofaprogramindetail.Oftenhelpsinunderstandingthestaticanddynamic
structureofsourcecode.
• SOFTWARE-ARCHEOLOGY: understand software by examining source code and code
history.
• ROOT-CAUSE-ANALYSIS: Some problems are only symptoms for underlying causes. In
systematic improvement it is often useful to tackle the root cause and the symptom
independently.
Fig. 4. Overview of the Analyze-Phase
V 2.0 – June 2014
5.2PracticesandPatternsfromEvaluationPhase
Themainfocusoftheevaluationphaseistomaketheproblemsandremediescomparableby
estimatingtheirvalueintermsofbusiness-orientedunits–mostoftenmoneyoreffort.
Software Architecture Improvement - Whitepaper
•
•
•
•
ESTIMATE-IN-INTERVAL:Givealowerandupperboundofyourestimate.Thedifference
betweenthetwoshowsconfidenceintheestimate.Ifthisdifferenceisrelativelysmall,
itshowshighconfidence
ESTIMATE-ISSUE-COST:Whatone-timeorrecurringcostdoesthisissuegenerate,either
witheveryoccurrenceorperiodically.
ESTIMATE-IMPROVEMENT-COST:Whatcostand/oreffortwilltheimprovementrequire?
IMPACT-ANALYSIS: What additional impact might an improvement or issue have, e.g.
after-effects or side-effects? This is especially important in case of architectural
compromisesincontextofconflictingqualitygoals.
Fig. 5. Overview of the Evaluate-Phase
V 2.0 – June 2014
5.3PatternsandPracticesforImprovement
Planandcoordinateremediestoeliminateorresolveissuesfound.Applyoneorseveral
improvementstocleanupcode,conceptsorprocesses,reducecostoroptimizequality
attributes.
• ANTICORRUPTION-LAYER: Isolate clients from internal changes of sub-systems or
modules.
• ASSERTIONS: Verify preconditions to make a program fail when something goes
fundamentallywrong.
• AUTOMATED-TESTS: Introduce automated tests (unit-, integration- or smoke-tests) to
verify correct runtime behavior. Such tests can assure that improvements or
refactoringdidnotmodify(break)desiredbehavior.
• BRANCH-FOR-IMPROVEMENT: Introduce distinct branches in version control system to
reflectimprovements.
• FRONTEND-SWITCH: Route front-end requests to either new or old backend systems,
dependingontheirnature.
• INTRODUCE BOY SCOUT RULE: Establish a policy to perform certain structural
improvements each time an artifact (source code, configuration, documents etc.) is
changed.
• ISOLATE-CHANGES: Introduce interfaces and intra-system borders, so that changes
cannotpropagatetootherareas.
• REFACTORING source code: Apply source code transformation that does not change
functionalityofsystem,butleavesthesourceinbetter,moreunderstandableormore
Software Architecture Improvement - Whitepaper
•
•
•
efficientstate.
REMOVE-NESTED-CONTROL-STRUCTURES: Re-structure code so that deeply nested or
complicatedcontrolstructuresarereplacedbysemanticallyidenticalversions
SAMPLE-FOR-IMPROVEMENT: Provide concrete code example for typical improvement
situations,sothatdeveloperscanimproveexistingcodeeasily.
UNTANGLE-CODE: Remove unnecessary complications in code, e.g. nested structures,
dependencies,dead-code,duplicate-codeetc.
5.4CrosscuttingPatternsandPractices
Insoftwareimprovementprojects,participantsshouldconstantlywatchoutforpotential
improvementsfortheissuesidentified.Ontheotherhand,evenwhenactiveinthe
improvementphase,previouslyunknownissuesmightoccur–whichneedtobecollected.
• COLLECTISSUES:Maintain a central list or overview of known problems, together with
their cost/effort evaluation. Collect in breadth-first manner, estimates will be
performedseparately.
• COLLECT OPPORTUNITIES FOR IMPROVEMENT: In all aim42 phases, one should identify
remediesforthecurrentlyknownproblemsortheircauses.
• IMPROVEMENT BACKLOG: A list or collection of remedies and their cost/effort/risk
estimation.
• Following the concepts of lean and agile, teams shall try to favor FASTFEEDBACK: The
later a lack of quality is identified the higher are the costs to fix it. Teams shall
continuously evaluate the quality of work artifacts and immediately take
countermeasuresorescalateasearlyaspossible.
Fig. 6. Overview of Crosscutting Activities and Artifacts
V 2.0 – June 2014
Software Architecture Improvement - Whitepaper
6IndustryExperience
Phasedandcost-benefitorientedimprovement,asdescribedabove,hasbeensuccessfully
appliedforseveralsoftwareandsoftware-intensivesystemsinvariousindustries.Duetonondisclosurerestrictions,concretetechnicalandbusinessdetailshavetobeomittedfor
publication.Neverthelessthemainfeaturesoftheaim42methodcanberecognizedandthe
specificpatternsandpracticesappliedwithinthecasestudiescanbenamed.
6.1FacilitateCommunicationBetweenITandBusinessStakeholders
Asaim42effectivelymapstechnicalissues(likeinternalquality,appropriatelevelofcoupling,
cohesion,applicabilityoftechnicalconcepts,adherencetoconceptualintegrity)tobusinessrelatedentities,especiallycost,effortandrisk,itaddressesbothbusinessandtechnical
stakeholders.
Thereforeaim42reducesterminologicalfrictionbetweenthoseparties,enablingtechnical
stakeholderstoexplaintheneedforarchitecturalimprovementtonon-technicalstakeholders,
especiallythoseresponsibleforbudget-relateddecisions.Thispositiveeffectmainlyresults
fromthecommonbusinessterms–likecostoreffort,whichbothtechnicalandbusiness
stakeholderscaneasilyunderstandbutrequiresasolidsharedfoundationofunderlying
assumptionsandtrust.
6.2MultimediaFrameworkforAutomotiveIndustry
Foraninternationalhard-andsoftwareproviderinautomotive,weconductedtheaim42
analysisandevaluationphases.QUALITATIVEANALYSIS,pairedwithSTAKEHOLDERINTERVIEWSwas
combinedwithPROCESSANALYSIS.Investingapproximately15person-daysinanalysisplus3
daysinevaluationleadtoadetailedISSUE-LISTandIMPROVEMENTBACKLOG.
Managementstakeholdersperceivedthesephasesashighlysuccessful,astheimprovement
backlogcontainedseveral“lowhangingfruit”:improvementswithrelativelylargepositive
impactforaminorinvestment.Examplesincludedtheeliminationofredundantdocumentation
withinthedistributeddevelopmentteams,theunificationofdomainterminology,sharpening
theteams’ubiquitouslanguageandsomeminor,purelytechnicalimprovementsinthe
technicalframeworks.
6.3TelecommunicationBilling
ForalargeEuropeantelecommunicationprovider,weinitiallyconductedtheanalysisand
evaluationphasesofaim42,laterincludedimprovementactivities.ASTRUCTURALANALYSISpaired
withSTAKEHOLDERINTERVIEWShelpeddiscoveraseverestructuralproblem.Conducting
SOFTWARE-ARCHEOLOGYandVIEW-BASEDUNDERSTANDINGleadtothefirstimprovementiteration,
especiallyimproveddocumentation.
Aftertheinitialaim42analysis,theimprovementbacklogplusnewdocumentationwashanded
overtoadevelopmentteamthatreplacedpartsofthesystemwithmoderntechnology.Most
issuesfoundduringaim42analysiscouldthereforeberesolved.
6.4Safety-CriticalInfrastructureSoftwareforFoodProduction
V 2.0 – June 2014
Aninternationalhard-andsoftwaremanufacturerinfoodindustryneededtodecrease
softwaredevelopmentandmaintenancecostwithinitssafetycriticalinfrastructuresoftware
(e.g.forproductionmachinehygienesupervision,production-lotreportingetc.).
AfterdetailedSTATICANALYSIS,RUNTIME-ANALYSISandQUALITATIVEANALYSIS,DEVELOPMENTPROCESS
ANALYSISplusinitialESTIMATE-ISSUECOST,weperformedVIEW-BASEDUNDERSTANDINGtogetherwith
thedevelopmentteam.SomeREFACTORINGleadtominorimprovementsincode.
ROOT-CAUSEANALYSISprovedthatamajorproblemresultedfromaseverelackofarchitecture
Software Architecture Improvement - Whitepaper
governance.SHEPARDINGTHEARCHITECTUREledtosignificantimprovementswithinthewhole
organizationandtheanalyzedsystemsrespectively.
Acknowledgements
ThankstoMichaelMahlbergandOliverTiggesfortheirhelpfulreviews.
ContactInformation
Email:[email protected]
Twitter:@arc_improve42
SupportedbyinnoQDeutschlandGmbH,
Krischerstr.100,D-40789Monheim
Web:
• aim42.org
• innoq.com–ourfriendlysupporter
ReferencesandFurtherInformation
1. aim42 MethodGuide:http://aim42.github.io
2. aim42 – optionsforcontribution: http://aim42.org/contribute/
3. ResourcesforSoftwareArchitects–http://arc42.org
V 2.0 – June 2014
Software Architecture Improvement - Whitepaper