Architectural knowledge has played a role in discussions on design, reuse, and evolution for over a decade. Over the past few years, the term has significantly increased in popularity and attempts are being made to properly define what constitutes ‘architectural knowledge’.

1. KnowledgeManagementinSoftwareArchitecture:State of the Art
Architectural knowledgehasplayedarole indiscussionsondesign,reuse,
and evolutionforoveradecade.Overthe pastfew years,the termhas significantly
increasedinpopularityand attemptsare beingmade toproperlydefinewhatconstitutes
‘architectural knowledge’.
1 Introduction
Overthe past fewyears,the conceptof ‘architectural knowledge’hasbecome more
prominentinliteratureandattemptsare beingmade toarrive at a properdefinition
for thisconcept.Inthischapter we presentthe state-of-the-artinarchitectural
knowledge management.Tothisend,we lookatwhatpreciselyentailsarchitectural
knowledge andwhatpredominantphilosophiesexistformanagingsuchknowledge.
In answertothe question‘whatisarchitectural knowledge?’,inSection2we
describe fourmainviewsonarchitectural knowledge thatemergedfromasystematic
literature review,andexplore theircommonalitiesanddifferences.Usingtwo
orthogonal architectural knowledge dimensions,we definefourcategoriesof architectural
knowledge.The potential knowledge conversionsbetweenthesecategories,
whichwe describe inSection3, togetherforma descriptive frameworkwith
whichdifferentarchitectural knowledgemanagementphilosophiescanbe typified.
Thisframeworkshowsthatthe differencesbetweenthe fourviewsonarchitectural
knowledge are verymuchrelatedtothe differentphilosophiestheyare basedon.
Althoughthere existseveral single-philosophyapproachesthathave boththeir
originandscope on onlyone of the mainphilosophies,inrecentyearsashifttowards
more overarchingapproachescanbe observed.Fourof suchtrendsforarchitectural
knowledge managementare discussedinSection4.
2 What is‘Architectural Knowledge’?
To be able tounderstandwhatarchitectural knowledgeentails,we have conducted

2. a systematicliterature reviewinwhichwe exploredthe ‘roots’architectural knowledge
has indifferentsoftware architecture communities.Detailsonthe protocol
followedinthissystematicliteraturereview canbe foundinSection5.The review
revealedfourprimaryviewsonarchitectural knowledge.InSection2.1we elaborate
uponthese views,andinSection2.2we formulate atheoryon architectural
knowledge bylookingatthe commonalitiesanddifferencesbetweenthese views.
2.1 DifferentViewsonArchitectural Knowledge
Architectural knowledgeisrelatedtosuchvarioustopicsasarchitecture evolution,
service orientedarchitectures,productline engineering,enterprise architecture,and
program understanding,toname buta few.Inthe literature,however,there are four
mainviewsonthe use and importance of architectural knowledge.Those fourviews
– pattern-centric,dynamism-centric,requirements-centric,anddecision-centric–
are introducedinthissection.
2.1.1 Pattern-centricview
In the mid-nineties,patternsbecame popularasa way to capture and reuse design
knowledge.People were disappointedbythe lackof abilityof (object-oriented)
frameworkstocapture the knowledge necessarytoknow whenandhow toapply
those frameworks.Inspiredbythe workof ChristopherAlexanderoncataloging
patternsusedincivil architecture,software engineersstartedtodocumentproven
solutionstorecurringproblems.
Initially,patternsfocusedmainlyonobjectorienteddesignandreuse;the canonical
workin thisarea isthe bookby the ‘Gang of Four’[22]. The aim wasto letthose
designpatternscapture expertanddesignknowledge,necessarytoknow whenand
howto reuse designandcode.Soon,however,the patternscommunityextendedits
horizonbeyondobject-orienteddesign.Nowadays,patternsexistinmanyareas,including
patternsforanalysis(e.g.,[19]), architectural design(e.g.,[20,12]),and the
developmentprocess(e.g.,[16,15]).

3. Patternsinsoftware developmentservetwopurposes.Patternsare reusablesolutions
that can be appliedtorecurringproblems.Theyalsoformavocabularythat
provides acommonframe of reference,whicheasessharingarchitectural knowledge
betweendevelopers.Althoughpatternsare usuallydocumentedaccordingto
certaintemplates,there isnotastandardtemplate usedforall patterns.The wayin
whichpatternsare codifiedmake themverysuitable forhumanconsumption,but
lesssofor automatedtools
2.1.2 Dynamism-centricview
A more formal approachto architectural knowledge canbe foundindiscussionson
dynamicsoftware architectures.Systemsthatexhibitsuchdynamismcandynamically
adapt theirarchitecture duringruntime,andforexample performupgrades
withoutthe needformanual interventionorshuttingdown.Suchsystemsmust
be able to self-reflectand‘reasonoverthe space of architectural knowledge’[23],
whichinvariablymeansthat –unlike patterns –thisarchitectural knowledge must
be codifiedforconsumptionbynon-humanagents.
Since the software itselfmustunderstandthe architecturalknowledge,architecture based
adaptationhasto relyon rather formal waysof codification.A 2004 survey
by Bradburyet al.[9] revealsthatalmostall formal specificationapproachesfor
dynamicsoftware architecturesare basedongraphrepresentationsof the architectural
structure.Purelygraph-basedapproachesuse explicitgraphrepresentationsof
componentsandconnectors.Inthose approaches,architectural reconfigurationis
expressedwithgraphrewritingrules.Otherapproaches,whichuse implicitgraph
representations,relymainlyonprocessalgebraorlogic toexpressdynamicrecon-
figurationof the architecture.
A particularfamilyof formal languagesforrepresentingarchitecturesisformed
by so-called‘architecture descriptionlanguages’(ADLs).Althoughnotall ADLs

4. are suitable foruse inrun-time dynamicsystems,all ADLsare basedon the same
component-connectorgraph-likerepresentationof architectures(cf.[33]).
2.1.3 Requirements-centricview
The architecture isultimatelyrootedinrequirements.Therefore,architectural knowledge
playsa role inenablingtraceabilityinthe transitionfromrequirementstoarchitecture.
But there isan inverse relationtoo,namelythe factthat‘stakeholdersare
quite oftennotable tospecifyinnovative requirementsinthe requireddetailwithout
havingsome knowledge aboutthe intendedsolution’[38].Hence,inordertospecify
sufficientlydetailedrequirements,one needsknowledgeaboutthe (possible)
solutions,whichmeansthatrequirementsandarchitecture needtobe co-developed.
Thisis a subtle,butimportantdifference:the transition-view isabitolderanddenotes
the believe thatproblemisfollowedbysolution,whereasthe more recent
co-developmentviewemphasizesthatbothneedtobe consideredconcurrently.
The relationbetweenrequirementsandarchitecture hasbeenapopularsubject
of discourse since the early2000s. Althoughthe relatedSTRAWworkshopseries
isno longerorganized,manyresearchersstill focusonbridgingthe gapbetween
requirementsandarchitecture.A 2006 surveybyGalsteret al.[21] identifiedand
classifiedthe methodologiesinthisarea,includingJackson’sproblemframes(later
extendedto‘architectural frames’[40]),goal-orientedrequirementsengineering,
and the twinpeaksmodel forweavingarchitectureandrequirements[36].
2.1.4 Decision-centricview
For manyyears,software architecture hasmainlybeenregardedasthe high-level
structure of componentsandconnectors.Manyarchitectural descriptionframeworks,
such as the IEEE-1471 standard[28] therefore have a particularfocuson
documentingthe endresultof the architectingprocess.
Nowadays,the viewonarchitecture seemstobe shiftingfromthe endresult

5. to the rationale behindthatendresult.More andmore researchersagree thatone
shouldconsidernotonlythe resultingarchitecture itself,butalsothe designdecisions
and relatedknowledgethatrepresentthe reasoningbehindthisresult.All such
architectural knowledge needstobe managedtoguide systemevolutionandprevent
knowledge vaporization.[8]
The treatmentof designdecisionsasfirst-classentitiesenablesthe consideration
of a wide range of concernsand issues,includingpure technical issues,butalso
business,political andsocial ones.Architectsneedtobalance all these concernsin
theirdecisionmaking.Tojustifythe architectural designtootherstakeholders,communication
of the architectural designdecisionsplaysakeyrole.Inthat sense,the
decision-centricviewisverymuchrelatedtothe (broader) fieldof designrationale.
2.2 So,what isArchitectural Knowledge?
If there’sanythingclearfromthe fourviewsonarchitectural knowledge,itmustbe
that there isnot a single encompassingdefinitionof whatthisknowledgeentails.
A 2008 surveyof definitionsof architecturalknowledge revealedthatmoststudies
circumstantiallydefine architectural knowledge.Those studiesthatdogive a direct
definitionare of recentdate,andall of themhave roots inthe decision-centric
view[3].
The apparentimportance of the decision-centricview indiscussinganddefining
architectural knowledge maybe explainedwhenwe lookatthe linksbetween
thisviewandthe otherviews;decisionsappeartobe the linkingpinbetweenthe
differentviews
The relationbetweenpatternsand decisionsisdiscussedbyHarrisonetal.Their
conclusionisthatthe two are complementaryconcepts,andthat‘[u]singapatternin

6. systemdesignis,infact,selectingone of the alternativesolutionsandthusmaking
the decisionsassociatedwiththe patterninthe targetsystemsspecificcontext’[26].
Ran and Kuuselaproposedahierarchical orderingof designpatternsinwhatthey
call a ‘designdecisiontree’[39].
The relationbetweendesigndecisionsandrequirementscanbe approachedfrom
twodirections.Boschconceptuallydividesanarchitectural designdecisionintoa
‘solutionpart’anda ‘requirementspart’[8].The requirementspartrepresentsthe
subsetof the system’srequirementstowhichthe solutionpartprovidesasolution.
VanLamsweerde,onthe otherhand,arguesthatfor alternative goal refinementsand
assignments,‘decisionshave tobe made whichinthe endwill produce different
architectures’[32].
Formal graph-basedarchitecture representationsare especiallysuitable forautomated
reasoning.Inotherwords,those representationsenable automatedagents
eithertake designdecisionsthemselves[9],orto informhumanarchitectsabout
potential problemsandpendingdecisions[42].
Decisionsmayindeedbe anumbrellaconceptthatunifypartsof those different
viewsonarchitectural knowledge,becausetheycloselyrelatetovariousmanifestations
of architectural knowledgeconcepts.Of course,there are differencesbetween
the viewstoo:patternsare individual solutionfragments, formal representationsfocus
on the endresultonly,andrequirementsengineeringismore occupiedwith
problemanalysisthansolutionexploration.If we wanttobettercompare the different
manifestationsof architectural knowledge,ithelpstodistinguishbetween
differenttypesof architectural knowledge.Twodistinctionsare particularlyuseful:
tacit vs.explicitknowledge,andapplication-genericvs.application-specificarchitectural
knowledge.
Nonakaand Takeuchi drawthe distinctionbetweentacit andexplicitknowledge

7. [35] (see alsoChapter1).This distinctionisapplicabletoknowledge ingeneral,
and itsapplicationtoarchitectural knowledgeallowsustodistinguishbetween
the (tacit) knowledgethatanarchitectand otherstakeholdersbuiltupfromexperience
and expertise,andthe (explicit) architectural knowledgethatisproducedand
codified –forexample inartifactssuchas architecture descriptions.
The distinctionbetweenapplication-genericandapplication-specificarchitectural
knowledge hasbeenproposedbyLagoandAvgeriou[31].Thisdistinction,
whichisnot necessarilyapplicable tootherknowledgethan‘architectural’knowledge,
allowsusto distinguishbetween(application-generic) knowledge thatis“a
formof libraryknowledge”that“can be appliedinseveral applicationsindependently
of the domain”and(application-specific) knowledge thatinvolves“all the decisions
that were takenduringthe architectingprocessof aparticularsystemandthe
architectural solutionsthatimplementedthe decisions”.Insummary,application
genericknowledge isall knowledge thatisindependentof the applicationdomain,
application-specificknowledge isall knowledge relatedtoaparticularsystem.
Application-generictacitarchitectural knowledge includesthe designknowledge
an architectgainedfromexperience,suchasarchitectural concepts,methodologies,
and internalizedsolutions.
Application-specifictacitarchitectural knowledgeentailscontextual domainknowledge
regardingforces onthe eventual architectural solution;itincludesbusiness
goals,stakeholderconcerns,andthe applicationcontextingeneral.
Application-genericexplicitknowledge isdesignknowledge thathasbeenmade
explicitindiscussions,books,standards,and othertypesof communication.Itincludes
reusable solutionssuchaspatterns,stylesandtactics,butalsoarchitecture
descriptionlanguages,reference architectures,andprocessmodels.

8. Application-specificexplicitarchitectural knowledge isprobably the mosttangible
type of architectural knowledge.Itincludesall externalizedknowledgeof a
particularsystem,suchas architectural viewsandmodels,architecturallysignificant
requirements,andcodifieddesigndecisionsandtheirrationale.
3 Philosophiesof ArchitecturalKnowledge Management
Knowledgefromeachof the four architectural knowledgecategoriescanbe converted
to knowledgeinanother(oreveninthe same) category.Thisconversion
liesatthe basisof differentarchitectural knowledge managementphilosophies.For
some,architectural knowledgemanagementmaybe mainlyintendedtosupportthe
transitionfromapplication-generictoapplication-specificknowledge.Forothers,
the interplaybetweentacitandexplicitknowledge maybe the essence of architectural
knowledge management.
Nonakaand Takeuchi definedfourmodesof conversionbetweentacitandexplicit
knowledge:socialization(tacittotacit),externalisation(tacittoexplicit),
internalisation(explicittotacit),and combination(explicittoexplicit;cf.Chapter
1). Basedon the distinctionbetweenapplication-genericandapplication-specific
knowledge,we candefine fouradditionalmodesof conversion:
• Utilizationisthe conversionfromapplication-generictoapplication-specific
knowledge.Itisa commonoperationinthe architectingprocesswhere background
knowledge andexperience are appliedtothe problemathand.
• Abstractionisthe conversionfromapplication-specifictoapplication-generic
knowledge.Inthisconversion,architectural knowledge isbroughttoa higher
level of abstractionsothatit has value beyondthe originalapplicationdomain.
• Refinementisthe conversionfromapplication-specifictoapplication-specific
knowledge.Here,the architectural knowledge foraparticularapplicationisanalyzed

9. and furtherrefinedandrelated.
• Maturementisthe conversionfromapplication-generictoapplication-generic
knowledge.Itsignifiesthe developmentof the individualarchitectaswell asthe
architecture fieldasawhole;akindof learningwhere new genericknowledgeis
derivedandbecomesavailableforapplicationinsubsequentdesignproblems.
In total,there are sixteenarchitecturalknowledge conversions.Eachconversion
isformedbypairing one of the fourconversionsbetweentacitandexplicitknowledge
withone of the fourconversionsbetweenapplication-genericandapplication specific
knowledge.Together,the sixteenconversionsformadescriptiveframework
withwhichdifferentarchitectural knowledge managementphilosophiescanbe typified.
We sawearlierthatthe four viewsonarchitectural knowledge canall be related
to decisionmaking.Atthe same time,we saw thatthere are alsoobviousdifferences
betweenthose views.Those differencesare verymuchrelatedtothe different
architectural knowledge managementphilosophiestheyare basedon.
The pattern-centricview,forexample,ismainlygearedtowardsthe development
of a sharedvocabularyof reusable,abstractsolutions.Assuch,the development
of a sharedtacit mental model isamajorgoal.This goal isachievedby
sharingapplication-genericpatternsthatare minedfromapplication-specificsolutions.
A secondgoal isthe developmentof librariesof reusablesolutions,which
ismade possiblebymaturementof documentedpatternsbycatalogingthem.The
knowledge managementphilosophyinthisviewisprimarilybasedonthe following
architectural knowledge conversions.
(a) Abstractionandcombination:The mostobviousexample of thisconversion
isthe processof patternmining.Patternsare inherentlyabstractions.Theyare
minedfromexistingarchitectural solutionsanddescribedinaclearand structured

10. wayto improve the reusability.
(b) Utilizationandcombination:One of the waysinwhichpatternscan be reused
innewdesignsisbylookingthemupinbooks,cataloges,orotherrepositories.
Architectswhowishtodesigna systemcomprisedof several independentprograms
that workcooperativelyonacommondata structure couldlookup one of
the many booksavailable onarchitectural patterns(e.g.,[12]) tofindoutthatthe
‘blackboard’patternisjustwhattheyneed.GradyBooch workson the creation
of a Handbookof software architecture,of whichthe primarygoal is “to fill this
voidinsoftware engineeringbycodifyingthe architecture of alarge collection
of interestingsoftware-intensive systems,presentingtheminamannerthat exposes
theiressential patternsandthatpermitscomparisonsacrossdomainsand
architectural styles.”[7].
(c) Maturementand combination:Documentedpatternsmaybe organizedinpattern
catalogs.These catalogspresentacollectionof relativelyindependentsolutions
to commondesignproblems.Asmore experience isgainedusingthese
patterns,developersandauthorswill increasinglyintegrategroupsof relatedpatterns
to formso-calledpatternlanguages[44].Althougheachpatternhasitsmerits
inisolation,the strengthof apatternlanguage isthat itintegratessolutions
to particularproblemsinimportanttechnical areas.Anexampleisprovidedby
SchmidtandBuschmannin the contextof developmentof concurrentnetworked
applications[43].Each designprobleminthisdomain –includingissuesrelated
to connectionmanagement,eventhandling,andservice access –mustbe resolved
coherentlyandconsistentlyandthisiswhere patternlanguagesare particularly
helpful.
(d) Maturementandinternalisation:Experiencedarchitectsknow numerouspatterns
by heart.Sucharchitectshave no trouble discussingdesignsintermsof
proxies,blackboardarchitectures,orthree-tierCORBA-basedclient-serverarchitectures.

11. Theirexposure toandexperience withthosepatternshasledtointernalised
and maturedpatternknowledge.The consequentshared,tacitvocabulary
can be employedatwill,withoutthe needtolookupindividual patternsinorder
to understandwhatthe otherpartymeans.
(e) Utilizationandexternalisation:Whenanarchitecthasinternalizedseveral patterns,
the use of those patternsasa meansforcommunicationordesignisa
combinationof utilization(of the pattern)andexternalisation(of the knowledge
aboutthe patternandits existence).
While the pattern-centricview aimstosupportthe developmentof tacitlyshared
application-genericarchitectural knowledge,the dynamism-centricview ismuch
more focusedonexplicitapplication-specificarchitectural knowledge.Although
some application-genericknowledgeisutilized,the actual reasoningandreconfiguration
usesapplication-specificknowledge.Thisarchitectural knowledgemanagement
philosophyisthereforeprimarilybasedontwoconversions:
(f) Refinementandcombination:correspondstothe formal reasoningovercodi-
fiedarchitectural solutionsintermsof modelsthatare consumable bynon-human
agents.One approachfor automatedreasoningoverapplication-specificarchitectural
knowledge isintroducedbyRobbinsetal.,whointroduce the concept
of ‘critics’[42].Criticsare active agentsthatsupportdecision-makingbycontinuously
and pessimisticallyanalyzingpartial architectures.Eachcriticchecks
for the presence of certainconditionsinthe partial architecture.Criticsdeliver
knowledge tothe architectaboutthe implicationsof,oralternativesto,adesign
decision.Often,criticssimplyadvisethe architectof potential errorsorareas
needingimprovementinthe architecture.One couldtherefore seecriticsasan
automatedformof the backlogthatarchitectsuse in the architectingprocessto
acquire and maintainoverview of the problemandsolutionspace [27].

12. (g) Utilizationandcombination:correspondstoformallyspecifyingthe application’s
componentsandconnectorsingenericlanguagessuchasADLsor other
graph representations.Medvidovicand Taylorpropose acomparisonandclassification
frameworkforADLs,enablingthe identificationof keypropertiesof
ADLs and toshowthe strengthandweaknessesof these languages[33].Intheir
comparison,MedvidovicandTaylorpointoutthat at one end of the spectrum
some ADLs specificallyaimtoaidarchitectsinunderstandingasoftware system
by offeringasimple graphical syntax,some semanticsandbasicanalyses
of architectural descriptions.Atthe otherendof the spectrum, however,ADLs
provide formal syntax andsemantics,powerful analysistools,model checkers,
parsers,compilers,code synthesistoolsandsoon.
For the requirements-centricview,the primarygoal istracingknowledge about
the problemtoknowledge aboutthe solution.Inco-development,anadditional goal
isto connectknowledge aboutproblemandsolutionsothata stakeholder’simage
of the problemandsolutiondomainisrefined.Inthisview,the primaryarchitectural
knowledge conversionsare:
(h) Refinementandsocialization:Especiallyinco-development,architectsand
stakeholderswill interacttoalignsystemgoalsandarchitectural solutions.Such
interactionbetween‘customer’and‘productdeveloper’isaprime exampleof a
situationinwhichtacitknowledgeisshared(cf.[35]).Pohl andSikoradiscuss
the needforco-developmentof requirementsandarchitecture.Theyargue that
such co-designisonlypossibleisthere issufficientknowledge aboutthe (course)
solutionwhendefining(detailed) systemrequirements:“insteadof definingrequirements
basedon implicitassumptionsaboutthe solution,requirementsand
architectural artifactsneedtobe developedconcurrently”[36].
(i) Refinementandcombination:Addingandmaintainingtraceabilityfromrequirements

13. to architecture isa refinementstepthatcombinesexplicitknowledge
aboutelementsfromthe problemandthe solutionspace.Several techniquesexist
to guide the transitionfromrequirementsengineeringtosoftware architecture.In
their2006 survey,Galsteret al.use architectural knowledge asknowledgeabout
(previous) architectural solutionsthatcanbe reusedwhenencounteringsimilar
requirementsinanewproject.Theypresentpatternsasa useful container
for these reusable assets.Anotherapproachforguidingthe transitionbetween
requirementsandarchitecture isthatof feature-solutiongraphs[10].De Bruin
and VanVlietuse architectural knowledge asknowledgeaboutqualityconcerns
(representedasfeatures)andsolutionfragmentsatthe architectural level (represented
as solutions).These are modeledtogetherasFeature-Solutiongraphs
inorder to guide the explicittransition(oralignment)betweenthe problemand
solutionworld.
(k) Refinementandexternalisation:Externalisationof application-specifictacit
knowledge –suchas concerns,goals,andthe like – isan importantpartof the
requirementsprocess.Externalisationof tacitknowledge (problem-relatedaswell
as solution-related)isapreconditionformaintainingtraceability.
(j) Refinementandinternalisation:The interactionbetweenarchitectsandstakeholders
isnot purelya matterof socialization.Inco-development,forexample,
specificationsanddesignartifactsplayamajorrole as well andmaybe an aidto
letthe parties‘re-experience’eachother’sexperiences(cf.[35]).Thisinternalization
of explicitapplication-specificarchitectural knowledge mayconsequently
leadto ‘newideasandinsightsconcerningboththe envisionedsystemusage and
the architectural solution’[38]
Finally,the essentialphilosophyof the decision-centricview isexternalizing
the rationale behindarchitectural solutions(i.e.‘the whyof the architecture’) that

14. can thenbe internalizedandshape otherpeople’smentalmodels,soasto prevent
knowledge vaporization.The architecturalknowledge conversionscentral tothis
philosophyare:
(l) Refinementandcombination:The systemizationandcategorizationof codi-
fieddesignknowledge isamajorpart of rationale management.Overthe past
fewyears,researchershave proposed(web-based) toolstovisualize codifieddesign
decisionsandtheirrelationshipsandimpact.Forexample,Capillaetal.
have proposedaweb-basedtool,ADDSS,forrecordingandmanagingarchitectural
designdecisions[13];Falessi etal.have devisedaspecificdesigndecision
rationale documentationtechnique,whichisdrivenbythe decisiongoalsanddesign
alternativesavailable [17];andArchiumisa tool environmentproposedby
Jansenetal.aimed at establishingandmaintainingtraceabilitybetweendesign
decisionmodelsandthe software architecture design[29].
(m) Utilizationandcombination:Thisconversionamountstothe reuse of codi-
fied,genericknowledge (decisiontemplates,architectural guidelines,patterns,
etc.) ‘to take decisionsforasingle applicationandthusconstructapplication specific
knowledge’[31].
(n) Internalisationandabstraction:Basedonexperience andexpertise,anarchitect
may quicklyjumptoa ‘good’solution foraparticularproblem.Sucha good
solutioncanbe a combinationof severalfinergraineddesigndecisions.This
combinationof designdecisionsmaybecome socommonforthe architectthat
the solutionisnolongerseenasconsistingof individualdecisions.Itmaybe hard
for the architectto reconstructwhya certainsolutionfitsaparticularproblem;
the architect‘justknows’.
(o) Utilizationandexternalisation:Whenasolutionhasbeeninternalized,andthe

15. architect‘justknows’whentoapplyit,itbecomesdifficulttosee whichother
solutionsare possible.Partof the decision-centricphilosophy(e.g.,in[10]) is
therefore toreconstructanddocumentthe constitutingdesigndecisions.
(p) Refinementandinternalisation:This‘consumption’of architecturalknowledge
takesplace whenpeople wantto‘learnfromitor carry out some quality
assessment’[31].
(q) Refinementandexternalisation:The rationalizationof takenarchitectural decisions,
i.e.reconstructionandexplanationof the ‘why’ behindthem,isacrucial
part of the decision-centricphilosophyinwhichtacitknowledge ismade explicit.
In thisrespect,the software architectingcanapplythe bestpracticesknownfrom
the ‘older’andwell-knownfieldof designrationale.Reglietal.presentasurvey
of designrationalesystems,inwhichtheydistinguishbetweenprocess-oriented
and feature-orientedapproaches[41].Process-orienteddesignrationalesystems
emphasize the designrationaleasa ‘history’of the designprocess,whichisdescriptive
and graph-based.A well-knownexample isthe Issue-BasedInformation
System(IBIS) frameworkforargumentation.A feature-orientedapproachstarts
fromthe designspace of an artifact,where the rulesandknowledge inthe specific
domainmustbe consideredindesigndecisionmaking.Oftenthese typeof design
rationale systemsoffersupportforautomatedreasoning.A more recentsurvey
on architecture designrationale byTangetal. providesinformationabouthow
practitionersthinkabout,reasonwith,documentanduse designrationale [46].
It turnsout that althoughpractitionersrecognize the importance of codifyingdesign
rationale,alackof appropriate standardsandtoolsto assisttheminthis
processacts as barrierto documentingdesignrationale.Fortunately,the fieldof
designrationale isworkinghardondevelopingmore mature support.Recentdevelopments
have ledto the creationof mature toolingsuchas Compendiumand
SEURAT [11], and modelssuchas AREL [47]

16. (r) Abstractionand combination:The constructionof high-level structures(templates,
ontologies,models) tocapture andstore architecture designdecisions.
Variousapproachestocodifyarchitectural designdecisionsinsuchasway have
beenreported.Tyree andAkermanpresentatemplate tocodifyarchitectural design
decisionstogetherwiththeirrationale andseveralotherpropertiesrelevant
to that decision,suchasthe associatedconstraints,atimestamp,andashort description
[48]. Kruchten proposesamore formal approachof codifyingdesign
decisionsbyusinganontology[30].Ran andKuuselapresentworkondesign
decisiontrees[39].
4 State-of-the-artinarchitectural knowledge management
Basedon the discussionof the fourphilosophiesonarchitectural knowledge management
and the primaryarchitectural knowledge conversionsof these philosophies,
we can identifyafewsingle-philosophyapproachestoarchitectural knowledge
management:
• Rationale managementsystems.Inordertoachieve refinementandexternalisation
of architectural knowledge,designrationale needstobe managed.Various
toolsand methodshave beenproposedoverthe lastdecade fordoingexactlythis.
• Patternlanguagesandcatalogs.Toallow forutilizationandcombinationof architectural
knowledge architectural knowledgeneedstobe categorizedinpattern
languagesorcatalogs.From these sourcesitcan be quicklyusedinspecificapplications.
In additionitenableslearningandreasoning
• Architecture descriptionlanguages.ADLsenable utilizationandcombinationof
architectural knowledge inaformal way.Varioustypesof ADLsexist,which
range in level of formalityandpurpose,the latterrangingfromaidingunderstanding

17. of software systemstoenablingpowerfulanalyses.
• Designdecisioncodification.Tosupportrefinementandcombinationof architectural
knowledge muchefforthasbeenputinmethods,tools,andtechniques
to codifyarchitectural knowledgeconcepts.Designdecisionsare central tothese
methodsandtools,butalsorelatedconceptssuchas rationale andalternative
solutionsare captured.
We sawearlierhowthe conceptof ‘decisions’seemtobe an umbrellaconcept
for all viewsonarchitectural knowledge.We cannow explainthisbetter: ‘mature’
architectural knowledge managementunifiesconversionsfromall architectural
knowledge managementphilosophies,andisnotmerelylimitedtojustone
philosophy.Thisconcept,whichwe call ‘decision-in-the-large’,isrelatedmore to
the architectingprocessthanto pure rationale management(whichwe couldcall
‘decision-in-the-narrow’),eventhoughcodifyingrationaleandpreventingknowledge
vaporizationhasbeenone of the prime driversforthe decision-centricphilosophy.
A focuson ‘decision-in-the-large’seemsdrivenmore byarchitectural knowledge
use casesthan by anythingelse,oftenunderthe concept‘knowledge sharing’.
A classificationof suchuse casesispresentedbyLagoet al.[31], whichdistinguishes
betweenarchitecting,sharing,assessing,andlearning.
Obviously,some‘decision-in-the-large’approachesevolvedfrom‘decision-inthe-narrow’
approaches.Butthe formerstarts to playa more prominentrole inthe
otherphilosophies,andhence the otherviews,too.Inrecentyears, a shifttowards
more overarchingstate-of-the-artapproachescanbe observed.Fourmaintrendsfor
architectural knowledge managementcanbe identifiedthatmostlyfocusonspecific
use casesfor architectural knowledge management.These trendswillbe elaborated
uponin the nextsubsections.

18. 4.1 Sharingarchitectural knowledge
The trend of sharingarchitectural knowledge isfocusedonprovidingsupportfor
managementof varioustypesof architectural knowledge (bothapplication-generic
and application-specific).De Boeretal.propose a core model of architectural
knowledge thatprovidesfurtherinsightinwhatarchitectingentails(e.g.how design
decisionsare made) andwhichknowledge conceptsare worthfocusingonin
supportfor architectural knowledgemanagement[4].Thisincludesconceptsthat
have theirorigininthe pattern-centric,requirements-centricanddecision-centric
view.
From knowledgemanagementliteratureitisknownthatknowledgesharingcan
be achievedthroughcodificationorpersonalization[25].Farenhorstetal.have come
to the conclusionthata hybridstrategymightworkbest.Theypropose aplatform
for architectural knowledgesharingthatcombinescodificationtechniques(design
decisionrepositories,documentmanagementfacilities)withpersonalizationmechanisms
(yellow pages,discussionforums) inordertoenable Just-In-Time architectural
knowledge:deliveryof andaccessto the right architectural knowledge,tothe
rightpeople,atthe righttime [18].
Anotherplatformthatallowsmanagingdifferenttypesof architecturalknowledge
conceptsisthe Process-basedArchitecture KnowledgeManagementEnvironment
(PAKME) proposedbyAli Babaret al.[1]. Thisenvironmentallowsstoring
application-genericarchitectural knowledge (suchasgeneral scenarios,patterns,
and qualityattributes),andapplication-specificarchitectureknowledge (suchas
concrete scenarios,contextualizedpatterns,andqualityfactors).
4.2 Aligningarchitectingwithrequirementsengineering
We observe atrendinarchitectural knowledgemanagementliteraturetowardsaligning
the architectingprocesswithrequirementsengineering,since the twopractices

19. seemtohave much incommon.Pohl etal. propose COSMOD-RE,a methodfor
co-designingrequirementsandarchitecture [37].Thismethodssupportsthe development
of detailedrequirementsbasedonthe specifiedarchitectureandthe speci-
fiedgoalsandscenarios.Thisco-designfocusisfundamentallydifferentfromthe
focuson traceabilityfromrequirementstoarchitecture,apredominantfocusinthe
requirements-centricview.
Withthe transitionfromtraceabilitytoco-development/co-designthe requirements
engineeringcommunityappearstolookbeyondtheirownphilosophy.Inan
attemptto betterunderstandthe relationshipof requirementsandarchitecture,De
Boerand Van Vlietexploresimilaritiesbetweenthe two[6].Basedontheirstudy
theyargue that there isno fundamental difference betweenarchitecturallysignificant
requirementsandarchitectural decisions,whichalsopleadsforintegratedmethods
and toolsforarchitectural knowledge managementthatoverarchrequirementsengineering
and architecting.
4.3 Intelligentsupportforarchitecting
Thistrendfocusesonspecificarchitectinguse casesrelatedtointelligentand/or
real-time supportforarchitects.One of the state-of-the-artapproachesfocuseson
providingarchitectsorreviewerswithareadingguide whenlookingforspecific
architectural knowledge [5].Tosave time,architectsuse thisintelligentdiscovery
methodtoquicklygetto the importantknowledge while skippinglessrelevantdocumentation.
Otherintelligentsupportapproachesfocusonmodelingarchitectural knowledge
conceptsinsuch a way that learningandreasoningisstimulated.One example
isprovidedbyKruchten,whoproposesanontologyof architectural design
decisions[30].The templateshe proposesallow acquiringinsightsinnotonlyimportant
propertiesof designdecisions(e.g.the status),butalsointhe relationshipsbetween
designdecisions(e.g.‘enables’or‘conflictswith’).Whenpropervisualizationtechniques
are usedthisinformationisveryuseful forarchitectsinthe decisionmaking

20. process,forexample tomodel the backlog[27].
4.4 Towardsa bodyof architectural knowledge
The last trendrelatestoestablishingabodyof architectural knowledge,toenable
bothlearningandreuse.Recently,severalapproachesforsettingupsucha bodyof
knowledge havebeenintroduced.LeninBabuet al.propose ArchVoc,anontology
for software architecture [2].Basedonknowledge frommajortextbooksonsoftware
architecture andby parsingpartsof the web,theyhave constructedasoftware
architecture vocabularyforreuse purposes.Theirontologyof softwarearchitecture
enablesthe architectinunderstandingthe existingbestpracticesandthe relationships
betweenthemandalsoprovide ameanstoapplythemto the new systemsto
be developed.
The needforcatalogingarchitectural knowledge isalsoexpressedbyShaw and
Clements,whoargue thatBooch’Handbook(cf.Section3) “can provide important
exemplars,butengineersalsoneedreference material thatorganizeswhatwe know
aboutarchitecture intoan accessible,operational bodyof knowledge.” [45] This
bodyof knowledgeisthusnotcomprisedof onlypatterns,butalsoothertypesof
explicitapplication-genericarchitectural knowledge thatcanbe utilizedeffectively.
In an attemptto furtherdefinethese typesof architectural knowledge,Clements
et al.have conductedempirical researchtofindoutwhatset of duties,skillsand
knowledge ismostimportantforanarchitect[14]. Codificationof thisarchitectural
knowledge isperceivedas“the beginningsof aroad map fortrainingand mentoring.”
5 Justification
Our state-of-the-artoverview onarchitectural knowledgemanagementisthe result
of an extensive literature reviewconductedbasedonapredefinedprotocol.More

21. detailsonthisprotocol can be foundin[3]. The mainphasesexecuted are discussed
inthe remainderof thissection.
In a systematicliteraturereviewof studiesthatdefineordiscuss‘architectural
knowledge’,we identified115 such studies[3].These 115 studiesformthe basisfor
our discussioninthischapter.Consequentlywe will refertothese studiesasthe set
of core studies(C).
Since we are interestedinthe communitystructuresthatunderlythe topicof
architectural knowledge,we enrichedourdatasetwithbibliographical links.We
assume the communitystructure canbe found,orapproximated,bytakingintoaccount
the bibliographical referencesthatvariousauthorsmake toeach otherswork.
Strongcommunitieswill displaymanyintra-communityreferences,andrelatively
fewreferencestoworkoutside the community.Thereare twotypesof bibliographical
references:referencesfromstudiesinCtootherstudies,andreferencestostudies
inC fromotherstudies.We will use B(for‘bibliography’) todenote studiesthatare
referredtofromstudiesinC,and R (for’referring’) todenote studiesthatreferto
studiesinC.Hence,the mappingR →C→ B summarizesthe enricheddatasetused
throughoutthischapter.1
To determine B,we simplytookall referenceslistedinthe 115 studiesfrom
C. To determine R,however,we hadtodo a ‘reverse search’onthe studiesinC,
since the informationneededisnotpresentinCitself.Forconstructionof R,we
usedthe Google Scholarsearchengine whichprovidessuchareverse searchfacility
throughits‘citedby’feature. While constructingRandB, we alsoobtainedresults
not necessarilyfoundinsourcesfromthe sourceslistidentifiedinoursystematic
review(cf.[3]).We donot see thisasa limitationof ourmethodology.The goal of
the datasetenrichmentisdifferentfromthe initial identificationof primarystudiesin
the systematicreview;inthe enrichmentwe are interestedincommunitystructures,
and the differentcommunitiesneednotbe limitedtostudiespublishedthroughand

22. indexedbythe sourcesusedfor the review.
Together,B,C, and R comprise a‘social network’of scholarlypublicationsand
theirinterconnections.We analyzedthisnetworkusingthe Girvan-Newmanalgorithm
[24]. The Girvan-Newmanalgorithmdiscoverscommunitiesinagraph,based
on the ‘betweenness’of edges,i.e.,the numberof shortestpathsthatrunthrough an
edge.The algorithmiterativelycalculatesthe edge betweennessandremovesthe
edge withthe highestbetweennessvalue,therebyeliminatingedgesthatact as connections
betweendifferentcommunities.Eventually,the algorithmresultsinafully
disconnectedgraphof ‘communities’thatconsistof a single node.
Obviously,adisconnectedgraphisnotthe strongestcommunitystructure possible.
Newmandefinesthe modularity(Q) asameasure of strengthof the community
structure discoveredinanetwork[34].High valuesof Q(0 ≤ Q ≤ 1) indicate networks
witha strong communitystructure.Newman’sempirical evidence showsthat
local maximaof Q correspondto reasonable community divisions,hence itisgood
practice to stop the Girvan-Newmanalgorithmwhena(local orglobal) maximum
Q-value hasbeenobtained.Inourcase,the firstlocal maximumof Q occurredwhen
the graph had beensplitupin52 communities,while the global maximumoccurred
at 59 communities(Q≈ 0,7832), whichisextremelyhigh(accordingtoNewman,
valuesabove 0.7 are rare; typical valuesfall inthe range 0.3−0.7). Because of the
data enrichmentprocesswe followedandthe waythe Girvan-Newmanalgorithm
works,eachof these 59 communitiesconsistsof atleastone studyfromC,pluszero
or more publicationsfromeitherBor R.
In orderto assignmeaningtothe 59 communitiesthatcame outof the algorithm
we examinedthe setof papersforeachof these communitiesinturn,andgave
thema label thatcorrespondedbesttothe papersinthat community.Often,the
non-core papersinthe communitydidhelpinfurthercharacterizingthe community
and helpedinphrasingasuitable label.Whenthiswasmore difficult(forexample

23. whenthe non-core papersvariedtoomuchinsubject),we lookedmore specifically
at the core papersinthat communitysince these actuallytalkaboutarchitectural
knowledge andcantherefore leadtomore fittingforthe communityname. Inthe
endwe endedupwith59 labelsforthe communities,althoughsome of those did
overlaptoa certainextentwitheachother.
In orderto findouthow exactlythe communitieshadbeendiscoveredbythe
GirvanNewmanalgorithmwe examinedthe hierarchical structure of the identified
communities.The hierarchical relationscapture the orderinwhichthe communities
have beenidentified.Basedonthe orderof community-split-upswe couldassign
namesto larger-order(i.e.parent) communitiesaswell.
Accordingto our definitionacommunityshouldconsistof atleasttwocore papers
(thattalk aboutarchitectural knowledge)writtenbydifferentauthors.Basedon
thisrule we furtheranalyzedthe data.We limitedthe numberof maincommunities
by removingthe single-core-paperonesandthe onesconsistingof merelypapers
by the same author(s).Inthe endthisrefinementculminatedintothe fourmain
communitiesdiscussedthroughoutthischapter:pattern-centric,dynamism-centric,
requirements-centric,and decision-centric.
6 Summary
In thischapterwe have analyzedthe state-of-the-artinarchitectural knowledge
management,andhave shownthatthe conceptof ‘architectural knowledge’isbecoming
more prominentinliterature.InSection2.1we have identifiedfourmain
viewsonarchitectural knowledge:apattern-centricview,adynamism-centricview,
a requirements-centricview,andadecision-centricview.The conceptof ‘decision’
was foundtobe an umbrellaconceptthatunifiespartsof these views.

24. To betterunderstandthe conceptof architectural knowledgeinSection2.2we
have definedfourmaincategories(ortypes) of architectural knowledgebasedona
distinctionbetweentacitandexplicitknowledge onthe one hand,andapplicationgeneric
and application-specificarchitecturalknowledge onthe otherhand.Intotal
16 knowledge conversionsare possible betweenthese fourtypesof architectural
knowledge.Toarticulate the commonalitiesanddifferencesbetweenthe fourviews,
inSection3 we statedtheirmainphilosophiesof architectural knowledgemanagement
and elaborateduponthe architectural knowledge conversionsthatare central
for these views.The conversionswere furtherillustratedbyexamplesof related
work.
Basedon the discussion of the mainphilosophieswe identifiedfoursingle philosophy
approachesforarchitectural knowledge management:rationale managementsystems,
patternlanguagesandcatalogs,architectural descriptionlanguages,
and designdecisioncodification.All these approacheshave boththeirorigininand
scope on onlyone of the main philosophies.Inrecentyears,however,ashifttowards
more overarchingapproachescanbe observed.Fourmaintrendsforarchitectural
knowledge managementcanbe identifiedthatmostlyfocusonspecificuse
casesfor architectural knowledge management(e.g.sharing,learning,traceability).
Thisstate of the art inarchitectural knowledge managementindicatesashiftfrom
‘decision-in-the-narrow’to‘decision-in-the-large’.
We expectthe interestinarchitectural knowledge tokeepincreasingoverthe
comingyears.Althoughitisunlikelythatwe will see aunifiedview onarchitectural
knowledge anytime soon,the observedtrendsinarchitectural knowledgemanagement
indicate thatfuture developmentsonmanagingarchitectural knowledge may
furtheralignthe differentviews.We expectthe trendtowards‘decision-in-the-large’
to continue,since bothresearchersandpractitionersaimforabetterunderstanding
of whatarchitectsdo,what theirknowledge needsare,andhow thisarchitectural
knowledge canbestbe managedinthe architectingprocess.

25. Source : springerlink.com
Recommendedby:
JonCohn ,CTO, VP IT Architecture
https://www.linkedin.com/in/jonacohn
joncohn@comcast.net
"JonCohn ExtonPA""JonCohn Exton""JonCohnEvolution"