E1Ͳ1
PatternsforProductLineEngineering
ChristaSchwanninger,MichaelKircher,SiemensAG
Introduction
SoftwareProductLineEngineering(PLE)hasbecomeanimportantwayofbuildingandreusing software.InPLE,thefocusisshiftedfrombuildingisolatedproductstobuildingfamiliesofrelated products,whilereuseisdiscussednotatanindividualobjectlevel,e.g.librariesorcomponents,but asawhole:organizational,processͲwise,andalsolifecyclewiseendͲtoͲendfromrequirementsto actuallydeployedvariabilityatthecustomer.WeconsideronlythoseplatformsPLEeffortsthatare plannedandprescribedtobereusedinadedicatedproductportfolioortobuildsolutionsina specificmarketsegment,hencetypicalgeneralpurposetechnologyplatforms,suchasEclipse,JBoss, or.NET,donotfallintothiscategory.
WhilealotofliteratureonPLEexists,thereisstillnoconsistentcollectionofeasytouseand practicalpatterns.Thepatternsdescribedinthispaperbuildontheexistingliterature,likethebook ofClementsandNorthrop[3]orKlausSchmid’sPhDThesis[8].Withthisinitialcollectionofpatterns wehopetomotivatemorepatternsonPLE.Thepatternsdescribehowtocentralizeandobjectify decisionmaking,howtopartitionthedomainintoseveralsubͲdomains,howtosetupyourreleases, andhowtoavoiddangerouscomplexity.
Thispaperisintendedforanyleadershipstaffconcernedwiththeproductportfoliocontent, organization,process,technology,architecture,oractualprojectexecutionofaPLEinitiative.We assumesomebackgroundinPLE.Referto[1]or[2]foramoredetailedintroduction.
PLEhastobeadaptedtothespecificorganizationathandtobesuccessful.Manyfactorsinfluence howPLEisexecutedinaspecificorganization.Theoneswiththelargestimpactare:sizeofthe organization,kindofbusiness,numberofproductlines,maturityofthedomain,andprocess discipline.WhilethosefactorsinfluencePLE,theywillinreturngetinfluencedbyintroducingPLE.
ThepatternsinthispaperapplylargelytomidͲandlargeͲscaleorganizations,astheytypicallyhave severalproductlineswithseveralinvolvedsubͲorganizationswithvaryingbusinessgoals,which makesdecisionmakingamultiͲdimensionaloptimizationproblem.Organizationswithonlyadozen involvedstaffdonothavesuchissues;insteadmostofthechallengebecomesatechnicalissueof howtodealwithvariability–whichisnotthefocusofthispaper.
Thepatternsdealwithsettinguptheorganization,theprocessandmethodologicalbestpractices.
ThispaperdoesnotprovideanyanalysisadvicewhentouseaPLEeffortornot,insteaditassumes thatareturnoninvest(ROI)analysishasbeendoneinadvanceandthataPLEapproachproved superioroverclassicaloneͲoffdevelopment.
ForreaderswhoarenotfamiliarwithPLEterminology,pleasereadtheglossaryattheendofthe patterncollection.
E1Ͳ2
Copyrightretainbyauthors.PermissiongrantedtoHillsideEuropeforinclusionintheCEURarchive ofconferenceproceedingsandforHillsideEuropewebsite.
ScopingPatterns
CentralDecisionMaking
Context
Anorganizationisadoptingproductlineengineering.Uptonowitdevelopedproductsorsolutionsin parallel,withcopy&pastereuse,technologicalplatformusage,orusingastandardizedinfrastructure.
Everyproductdevelopmentgroupwasresponsiblefordecidingonthescopeandreleaseplanofits product,ataskcalledproductmanagement.Theorganizationwantstoincreasethebenefitfrom reuseamongproducts/solutions.Thedevelopmentofasetofreusablecoreassetsisstarted.Ithas tobedecidedwhatthesecoreassetsshouldbe:thescopeofthereuseinfrastructure.Thereasonfor startingtheproductlineistomaximizethereturnoninvestment(ROI)forbuildingreusableassets forthewholeorganization.Figure1showsthedesiredstate,onedomainengineeringactivitythat producesreusableassetsandseveralapplicationengineeringactivitiesthatreusetheseassets.
Figure1:Relationshipbetweendomainandapplicationengineering
Problem
Whodecideswhatassetsshouldbedevelopedasreusablecoreassetsandwhatassetsshouldbe keptproductspecific?
x Everyproductmanagertypicallypusheshisownproducts.Reuseisonlyinterestingifitsaves effortorotherwisebenefitshisproducts.Supportinghisownproductsiswhatheistrained todo.
x Withoutmoderationeitherthestrongestinagroupofproductmanagersdictateswhatwill beimplementedasreusablecoreassetortheproductmanagersagreeonsome
compromise,e.g.everybodygetstheirmostimportantfeaturesin.Thisselectionislikelynot maximizingtheprofitofthewholeorganization.
x Coreassetdevelopmentisconfrontedwithallproductmanagersandtheircorresponding priorities.Fordecidingaboutaproductportfoliostrategydeepmarketknowledgeis required,whichtypicallyisnotavailableindevelopment.Developmentisinclinedeitherto
E1Ͳ3
giveinonthepressureofthestrongestordecidebythemselveswhathasthehighest priority,oftenaccordingtopurelytechnicalcriteria.
Solution
Centralizedecisionmakingregardingscopeandpriorities.Thebestwaytodothisisintroduceanew roleintheorganization,theproductlineproductmanager.Hisgoalistooptimizetheproduct portfolio,thesolutionscope,whichshallbesupportedbythesharedcoreassets.Forbigger organizationstheproductlineproductmanagementcanalsobestaffedwithseveralindividuals.
Figure2:TheProductLineProductManagerisresponsibleforthewholeproductline.
Coreassetdevelopmentshouldnotdecideaboutfeaturepriorities.However,coreasset
developmentestimatestheeffortforfeaturesandanalyzesdependenciesamongfeatures,whichis essentialinputfordecidingonwhatshouldbeimplementedascoreasset.Beawarethatproduct managementaloneisnotsufficienttofindtheoveralloptimizedscopeforabusiness,because constraintslikequality,time,andcostmightnotberepresentedsufficiently;seethepatterns BalanceConstraintsandCollaborationbetweenProblemandSolutionExperts.
TheProductLineProductManagerisresponsiblefortheoverallproductportfolio,thereforeis neitherpartofanyproductdevelopmentteam,norofthecoreassetdevelopmentteam.There mightbeconditionsthatrenderadedicated,independentrolenotpossible,e.g.iftheorganizations areseparateprofitcenterswiththeirownbusinesstargetsandnooperationalresponsibilitiesareat acommonmanagementlevel.TheProductLineProductManagerwouldinthiscasebepartofthe coreassetdevelopingorganization,whichmakeshispositionintheoverallorganizationweaker.It requiresadditionalprocesssupporttodealwiththissituation.ThissubͲpatternlanguageisyettobe mined.
Rationale
Foreffectivecoreassetdevelopmentasingleresponsibilityforprioritizationandscopingisrequired.
Inordertoprioritizefeaturesandscopetheproductlinetomaximizetheeconomicbenefitofthe
E1Ͳ4
E1Ͳ5
wholeorganization,knowledgeaboutthemarket(s),competition,andcustomersisimportantfor thatrole.Developmenttypicallylacksthefullunderstandingofcustomerandbusinessvalue.
Thispatternworksbestifthecoreassetsactuallyimplementdomainspecific–customervisible–
coreassets.Suchassetstypicallyheavilyinfluencetheactualproductportfolio.Incontrast,ifthe coreassetsaremainlytechnicalinfrastructureassets,theproductportfolioisonlymarginally influencedbythecoreassetscope.Insuchcasestheproductlinearchitectroleinsteadofthe productmanager,mayperformthescoping,becausehecanadequatelyjudgethescopeofthe mainlyinfrastructurecoreassets.TheProductLineArchitectthenfulfillstheroleoftheProductLine ProductManageraswell.
TheProductLineProductManagerroleresolvestheconflictamongstproductmanagersand betweenproductmanagementandcoreassetdevelopment.Wesaworganizationsthatsuffered fromthisconflict.Intheend,theproductlinesbrokeapartandthewholeeffortofdoingPLEwas seenasafailure.
TheRoleProductLineProductManagerhastoknowhowtomanagetheconflictinginterests betweenhisroleandtheproductmanagers.ThisconflictcanberesolvedwithComprehensible DecisionMaking.
ReferencesandKnownUses
ThispatternisappliedataSiemensHealthcaregroupdevelopinganimagingplatform.Theplatform customersaredifferentimagingproductlines,whichwereheavilyinvolvedindefiningthescopeof thenewplatformfromthebeginning.However,therewasnodedicatedproductmanagerforthe platform.Hence,fartoomanyfeatureswereassignedtotheplatform.Therewasnoclear
prioritization,anddespiteworkinghard,theplatformcustomerswereneversatisfiedwiththescope oftheplatform.Twoyearslatertheorganizationinstalledaplatformproductmanagement.The platformproductmanagerisnowresponsibletodefineacommonvocabularyandtodrivescopingof coreassetsincollaborationwiththeproductmanagersofthedifferentproducts.Hemoderates scopingsessionsandmakesthescopeandtherationalforthescopetransparenttoproduct developments.Theorganizationmanagedtoregaintrustfromtheproductgroups.Installinga productlineproductmanagerimprovedthesituationconsiderablyforboth,domainandapplication engineering.
AseparategroupatSiemenspostalautomationstartedafirstplatformabout10yearsagotobenefit fromreuseamongtheircustomerprojects.Therewasnoplatformproductmanager,evennoexplicit scopingprocess.Theplatformuserswerenothappywiththeplatform,quicklystartedtocloneand ownpartsoftheplatformandtheplatformteamwasturnedintoaprojectteamforonespecific customerafterthreeyears.Today,theorganizationhasaverystrongproductmanagementthat knowsaboutthevalueofreusableassetsandactivelysupportsscopingandmarketingofreusable assets.Allbiddinginvitationsgothroughtheproductlinemanagementgroup,thatisateamof productlineproductmanagersandproductlinearchitects.Thescopingisdoneinseveralsteps:
decidingwhichexistingcoreassetswillbeofferedtothecustomer,whichcoreassetsshouldbe adaptedandwhichshouldbebuiltanewincasethecustomerprojectactuallyiswon.Basedonthis theofferismadetothecustomer.Whenthecustomeraccepts,theproductlinemanagementteam includestheeffortforbuildingtheassetsintotheoverallproductlinedevelopmentplan.
E1Ͳ6
ComprehensibleDecisionCriteria
Context
ThepatternProductLineProductManagerwasapplied.Aconflictpotentialisremainingbetween individualproductmanagersandtheProductLineProductManagerresponsibleforthewhole productlineportfolio.
Problem
Theproductmanagersresponsibleforsingleproduct/solutionareagroupofpeerswhohaveall conflictinggoals,whichispromotingthespecificproductstheyareresponsiblefor.Agreeingona scopeforthereusablebaseassetsmeansresolvingconflictsthatarisefromthesedifferentgoals.
x Everyproductmanagertypicallypushesonlyhisownproducts.Reuseisonlyinterestingifit saveseffortorotherwisebenefitshisproducts.Supportinghisownproductsiswhatheis trainedtodo.
x Coreassetsoftengetspecialfunding.Thecostissharedbetweenallproducts/solutions.
Oftenproductmanagerswanttounburdentheirproduct/solutionspecificbudgetandputas muchdevelopmenteffortaspossibletothecoreassetdevelopment.Thiswaymorebudget isavailableformakingownproductsbetter,cheaperorearlieronthemarket..
x WhentheselectionofwhatshallbeacoreassetandwhatshallbeproductͲspecificseems notcredible,developmentwillnotrespectthescopingdecisions.Developmentwilldecideon itsownpriorities.
Solution
Defineandcommunicateclearcriteriaforevaluatingthevalueoffeatures.Thecriteriashouldbe derivedfromtheorganization’smission,vision,andstrategy,becauseonlythenthedecisionsarein linewiththebusinesstargets.Evaluatethecostandbenefitforeveryfeatureandforeveryproduct accordingtothesecommoncriteria.Decisionmakingboilsdowntocalculatingthesevaluesand decidingaccordingtoobjectivenumbers.
Thebestwaytodothisistodefinecriteriaforthebenefitandthecostofeachfeature.Benefit criteriacouldbehowmuchdoesthemarketrequestthisfeatureorhowwelldoesitsupportthe specificportfoliostrategy.Thecostsideneednotbeanestimationofthedevelopmentcostforthe feature,sincethismaybehardtobecalculatedearlyintheprocess,butamixtureofestimated complexity,novelty,andeffectonthecurrentproductlinearchitecture.
Startwithsimplebenefit/costevaluationformulasandimprovethemovertime.Theproduct managersandarchitectsthatdeliverthedatafortheformulatypicallydifferintheiraccuracyand reliabilityofthedatatheyprovide.Installmetricscomparingestimationswiththelaterfacts,e.g.
estimatedsalesfiguresandactualsalesfiguresforaproduct.Theresultsareusedascorrection factors.
E1Ͳ7
Rationale
Mostofthepotentialconflictcanbemitigatedwheneverystakeholdersharestheirbusinessvalue dataandtheresultismerelycalculated.Theproductlineproductmanagerdrivestheprocessand controlshowfairlyfeaturesareratedandimprovestheevaluationcriteriaandformulas.
ReferencesandKnownUses
TheplatformorganizationforimagingsystemswithinSiemensHealthcaredevelopedaformulafor prioritizingfeaturesandcalculatingthecostofeveryfeature.Itisfilledwithinformationfrom
productmanagementanddevelopmenttodeterminebenefitandcostofeveryfeature.Measuresfor afeature’sbenefitareforexamplewhetheritisinnovativeorjusta“metoo”featureandhowoften itwouldbereused,measuresforitscostareforexamplethecomplexityandhowcrosscuttingitisin thesolutionspace.Theresultsaretakentodecidewhetherafeatureshouldbeimplementedinthe platformatallandwhatpriorityitshouldhave.
KlausSchmidsuggestsasimilarprocedurein[2].Inthiscontextitwastestedwithtwoproductlines ofMARKETMAKERSoftwareAGandwithoneproductlineinBosch.
E1Ͳ8
SeparateSubǦdomains
Context
Theorganizationhastodecidewhatwillbedevelopedascoreassetandwhatwillremainproduct specific–atypicalscopingdecision.Actually,theorganizationwillalsohavetodecideonaproduct portfoliothatallowsmaximizingthebenefitfromreuse.
Problem
Budgetandtimeforsettingupacoreassetbaseislimited.Iffindingoutwhichassetsareworthtobe developedascoreassettakestoomanyresources,theproductlinemightdiebeforeitevenstarts.
x Notallareasinadomainareequallystableandthereforesuitableforreuse.
x Scopingisapureplanningactivity.Itisnotproductiveandaccountsasnegativeiteminthe returnoninvestmentcalculationforaproductline.
x OftenamarketevaluationisanimportantpreͲconditionforscoping.Thescopingactivityhas tobeperformedinatimeframethattogetherwithimplementingthescopeisshortenough tocatchthemarketwindowthatwaslookedatintheevaluation.
x Thefeaturesinthecoreassetbasehavetobeselectedinawaysuchthatitispossibleto formaconsistentreferencearchitecture.Theycannotresultincompletelyindependent piecesoffunctionalityinsolutionspace.Itmustbepossibletoarchitectandimplementa coherentchunkoffunctionality.
Solution
DividetheapplicationdomaininsubͲdomainsthatcanbehandledseparately.Theeasiestwayto identifysubͲdomainsistolookatexistingsystems/products.Theirdivisioninsubsystemsisagood firstsubdivisionoftheoveralldomain.FirstestimatethereusepotentialforeverysubͲdomainbased onpastexperience.ThencontinuecloserinvestigationswithoneortwopromisingsubͲdomains.Find outwhatcanbereusedforthesesubͲdomainsandimplementtheseassets.
ThesubͲdomainsmightbeapplicationdomainspecificliketelephony,shortmessageserviceand dataservicesinamobilephone,ortechnical,likememoryorpowermanagement.
Figure3:ConsistentsubͲdomainsmaybevertical,horizontal,orscatteredacrossthearchitecture.
Rationale
ImplementingonlycoreassetsforoneortwosubͲdomainsgivesearlyfeedbacktoallstakeholders whethertheorganizationandprocesschangesforPLEweretherightoneswithoutbearingtoohigh riskforthewholeorganization.Withsuchpotentialquickwinstheorganizationismotivatedto extendtheproductlinealsotoothersubͲdomains.
ReferencesandKnownUses
CarmanufacturerstypicallydividetheircarsinsubͲdomainslikechassis,engine,electricalsystem,or safetysystems.Thisdivisionistypicallyalsomirroredintheorganizationalsetup;similarlythe configurationoptionsforthecustomersaregroupedinthesesubͲdomains.
ThefeaturesoftheimagingplatforminSiemensHealthcarearegroupedintoabout10subͲdomains thatstructuretheproblemaswellasthesolutionspace.
KlausSchmidintroducesanewapproachforevaluatingsubͲdomains,thedomainpotential assessmentin[2].
E1Ͳ9
E1Ͳ10
StartwithProductFeatureMap
Context
Anorganizationwantstobenefitfromreuse.Theorganizationalreadyimplementedsystemsinthe domainforawhile.Existingproductsorsolutionsareavailable.
Problem
Tobenefitfromreuseincurrentand/orfutureproductportfoliotheorganizationneedstofindout whichartifactsshouldbeimplementedforreuse.
x Takingalreadyavailableassetsandturnthemintoreusableassetsbyincreasingthequality andaddingvariationpointsisalowriskoptiontogetasetofcoreassets.Howeveritis unclearwhichvariantsshouldbesupported.
x Developmentknowswhatittakestobuildcertainfunctionalityandwhatshouldbereusable.
Butstillthisisatmostaprojectionfromthepastproductportfolio.
x DomainanalysislooksatsubͲdomainsthatpresumablyhavereusepotential,identifiesthe commonalitiesandvariantsineachsubͲdomainandgivesafeelingforreusepotential.
However,ifallvariantspossibleinasubͲdomainareconsidered,thiswillnotsupportthe businessoftheorganizationoptimally.
Solution
Beforethescopingofcoreassetsstarts,theproductsorsolutionsthatshallbesupportedbythese coreassetshavetobeclear.Thus,thefirststepistoidentifytheproductsandmarketsegmentsthat shallbeaddressedbytheproductline.Next,thecharacteristicsorfeaturesthatareincludedineach oftheproductsarelistedtoseethecommonalitiesandvariabilitybetweentheproductsormarket segments.Thisisthestartingpositionforfurthercommonality/variabilityanalysis.Theenvisioned productportfoliorestrictsthelistofpossiblefeaturesineachsubͲdomain.Atthesametimeproducts getbettershapedbydecidingforeachadditionalfeatureifitshouldorshouldnotbeintheproduct.
Rationale
Iftheproductportfolioormarketsegmentsofinterestarenotthestartingpointforcoreasset scoping,theassetswilltypicallybemoregenericthannecessary.Theadvantageofproductline engineeringoversimplereuseaspropagatedinthe1990sisthatonlythevariabilityelementary necessarytosupportaspecificbusinessisbuiltintothecoreassetsandnotmore–seeFavor PlatformSimplicity.Coreassetshavetobebuildconsideringvariabilitythatistobeexpectedfor futureportfolios,butthevariantsshouldbeclearlyidentifiableandevidentlymotivated.
ReferencesandKnownUses
Product/Featuremapsarequitecommoninportfoliodevelopment.CarmanufacturerslikeAudiand BMWpresenttheirportfolioinsuchlists.
Similarly,SiemensIndustryDriveTechnologiesscopetheirproductportfolioswiththehelpof product/featuremapsundusethecustomervisibleparttopresenttheirproductportfolioto customers,Figure4showsanexamplefromhttp://www.automation.siemens.com/.
Figure4:ExampleofSiemensAutomationandDrivesPortfolio
KlausSchmidsuggeststhisprocedurein[2].Inthiscontextitwastestedwithtwoproductlinesof MARKETMAKERSoftwareAGandwithoneproductlineinBosch.
In[3]PaulClementsandLindaNorthropsuggest“Developinganattribute/productmatrix”,whichis onepatternintheircollectionofPLEpatterns.Thepatternsin[3]wereminedfromexperiencewith consultingcompaniesthatintroducedorimprovedaPLEapproach.
E1Ͳ11
E1Ͳ12
CollaborationbetweenProblemandSolutionExperts
Context
Anorganizationdecidestobuildacoreassetbase.Ittriestooptimizethereturnoninvestment.
Problem
Neitherproductmanagement,nordevelopmentaloneissupposedtoknowalldetailsaround commonalityandvariability.
x Productmanagementknowsallfactsaroundmarket,marketablefeatures,valueoffeatures, andproducts.Further,itknowswhichfeaturesarecommonbetweenproductsonahigh levelofabstraction.However,withmoredetailedanalysisvariabilityquicklyincreases, especiallyifnonͲfunctionalrequirementsvary.Suchvariabilitycannotbespottedonahigh levelofabstraction.Hence,thecomplexityandcostforfeaturescannotbedeterminedto thefullextentbyproductmanagement.
x Developmentknowsthecostfordevelopingassets,bothforproductͲspecificandcoreassets.
Developmenthasthe‘solutionspace’knowledgefordeterminingtheactualvariabilityand dependenciesbetweenvariationpoints.However,developmentlackstheknowledgeabout thevalueoffeaturesforcustomers.
Solution
Letscopingbeleadbyproductmanagement,butmakeitaniterativeandcollaborativeeffort betweenproductmanagementanddevelopment.Productmanagementinitiallysetsuptheproduct mapwithfeatureassignmentstoproducts.Developmentanalysesthefeatureindepthbydrafting designsandidentifyingtechnicaldependenciesbetweenvariants.Itmightforexamplebenecessary toincludecertainfeaturesintothecoreassetbasethatwouldnothavebeenselected,ifitwereonly basedontheirbusinessvalueforthecustomer,butbecausetheyarenecessarytodevelophigher prioritizedfeaturesefficiently.Theadditionaldependenciesandcostarefedbacktoproduct managementthatreͲestimatesthecost/benefitratioforfeaturesandproducts.Bothpartiesiterate overtheproductportfoliocommonlyandalternately.
Rationale
Whileproductmanagementisresponsibleforsettingupaproductportfoliothatoptimizesthe businessofanorganization,developmentisresponsibleforminimizingthecostofaproduct portfolio,potentiallyoptimizingreuseandtodecidewhetherafeaturesetcanbeimplementedina consistentplatformarchitectureatall.Neithercanproductmanagementestimateeffortsreliably,be itforproductͲspecificorcoreassets,norcandevelopmentdecideonprioritiesofproductsor
features.Thefeedbackfromdevelopmentofteninfluencestheproductportfoliodirectly.Product managementismadeawareofexistingknowledgeorassetsthatcanbemarketedbychangingthe portfolio.
ReferencesandKnownUses
FordecidingwhichfeaturesgointotheimagingplatformatSiemensHealthcare,datafromproduct managementisusedtocalculatethevalueofafeatureandfromarchitectstogetthecostof features.
E1Ͳ13
TheSiemenspostalautomationgroupandpartofthehotrollingmillautomationhaveproductline teamsinstalledthatconsistofproductmanagement(orsales)andarchitects.Togethertheydecide whetherafeatureisdevelopedintheplatformoronlyforonespecificsolution.
In[3]therisksofscopinginclude“scopeincludesthewrongproducts”.Further,theauthorsdescribe thatthereasontypicallyisthemissingcollaborationbetweenproductmanagementand
development.
E1Ͳ14
GeneralPatterns
RegularPlatformReleases
Context
Onlyalimitednumberofknowledgeablepeopleexistpercoreassetthatcanchangeorextenda specificcoreasset.Coreassetsfacehighdemandofchangeandextensionbytheproductsthatare reusingthem.Howdoyoumitigatethepressure?
Problem
Acceptingthehighpressure,specificallyregardingtime,canresultinseveralshortsightedsolutions.
x Severalbranchesofthesamecodepartsfordifferentproductsinparallel.Theconsequence ishighmergeeffortsbetweenthebranchesandoverheadofswitchingbetweenthe
branchesforindividualdevelopers.
x Highflexibilityofthecodepartstoacceptanyvariant,e.g.overly‘strategized’designor creatinga#ifdefhell.
x Inurgentcasesapplicationdevelopersareinclinedtofallbacktocopy&pastereuse,oreven reͲwritethefunctionalityproductspecific.
Solution
Therefore,prioritizeyourtotalfeaturebacklogconsideringwhenreusablecomponentshavetobe availableforwhichproductsandprovidehighqualityreleasesregularly,e.g.every3months.Ifa platformuserurgentlyneedsanychangeorextension,thefeaturebacklogcanbereprioritized accordingly.
Rationale
Regularreleasesalleviatethehighpressurethattypicallyleadstomultiplebranches;hencebranches cantypicallybeavoidedoratleastminimizedintheirnumber.Inordertobeacceptedbythe
platformusersthequalityoftheregularreleasesmustbesufficientlyhigh.Fullyautomated
regressiontestsuitesthatareexecutedoneverychange,uptotheextentofContinuousIntegration, securethequalitywhileminimizingextraefforts.
However,providingregularreleaseschallengestheorganizationtodefineaproperversioning strategythatregulateswhichreleasesarecompatible,e.g.allminorreleases,andwhichreleases containincompatibleAPIchanges,e.g.majorreleases.
E1Ͳ15
FavorPlatformSimplicity
Context
Sourcecodeofreusableassetsgetscomplexveryeasy.OftenitisthewellͲintendedflexibility designedandimplementedbydevelopersthatincreasesthecomplexity.
Problem
Platformsareintendedforlongevity,butthehighcomplexityletsthemdiethetooͲcomplexͲandͲnotͲ maintainableͲanyͲmoredeadfasterthanexpected.Howdobuildthesimplestpossibleplatform?
x Platformdevelopmentisoftendefinedasprovidingthesoftwarewithenoughvariability mechanisms,suchasheavilyapplyingtheStrategypatternandallowingfordeclarative programmingviaconfigurationfiles.
x Hardwiringonlytheverycurrentrequirementsmightleadtomonolithicdesign,hencebadly maintainableandevolvablesoftware,too.
Solution
Therefore,establishthemindsetofthebeautyofsimplicity.Favorsimplicityinsteadofflexibility.
Firstly,differentiatebetweentheinherentcomplexityofaproblemandtheaccidentalcomplexity.At alltimesbeawareoftheinherentcomplexityofaproblem.
Forexample,thedemandedvariabilityofanapplicationdomainisinherentcomplexity,whilethe solutionapproach,e.g.flexibility,dynamicity,orgenericityaretypicallysourcesofaccidental complexity.InmanyregardsthisalsomeansthattheuseoftheclassicalGoFdesignpatternshasto belimitedtothebareminimum.Basicallyitis“Dothesimplestthingthatcouldpossiblywork”[9], whilenotobstructingfuturepotentialextension.
Reducingtheinherentcomplexityisonlypossiblebyreducingtherequiredvariability,whichinturn meansreducingthescopeoftheproductline.Accidentalcomplexitycanbeavoidedbydemanding thatallflexibilityintheplatformhastobejustifiedbyvariabilityinthechosenscopeoftheproblem space.
Rationale
Whilethesolutionmightsoundtrivial,itisnot.Withalltheintrinsicmotivationandcreativityofa typicalsoftwaredeveloper,onlylotsofdisciplineandexperiencewillallowhimtoactuallyfocuson theessentials.Simplicityshouldguideitselfontheactuallydemandedvariability,thescope,ofthe productline,notthegeneralinterestintechnology,preparingforallpotentialvariationsorthe applicationofthemostpatterns.Soinsomesensethispatternismeantasreminderofadheringto bestpracticeandpragmatism.Inhardwaredevelopmentcreatingflexibilityismuchmoreexpensive comparedtosoftware,henceoverlyͲflexibledesigninhardwareislessofanissue.
Theroleofthesoftwarearchitect,oftenalsocalledtechnicallead,iscrucialinthisaspect.Heguides theorganizationbyestablishingtherightmindset.Continuousreviewofdesigndecisionsby
developmentteamsallowshimgiveinputandpotentiallycorrectmisguideddesigndecisions.
E1Ͳ16
ReferencesandKnownUses
AttheimagingplatformdevelopmenteffortinSiemensHealthcarethispatternisappliedtoensure thelongevityoftheplatformaswellasthedevelopmentefficiencyoftheapplicationsontop.The groupintroducedthetrackingandtracingofdependenciesbetweensolutionandproblemspace variability.Duetotheregulatoryrequirements,whichalreadyrequiresomeextentoftracing,this stepwasnottoodifficult.Theadditionaltracingcausessomeoverheadinmaintaining,butonthe positivesideforcesdeveloperstodesignforsimplicity.
E1Ͳ17
BalanceConstraints
Context
Strategicandoperationaldecisionsneedtobemade.Everyprojectfollowstheconstraintsofthe projectmanagementtriangle[4].Mappedtotheareaofsoftwaredevelopmenttheyaredefinedas:
x Scope–thefunctionalityespeciallytheuniquesellingpointsofferedbyaproduct
x Quality–thedevelopmentalaswellasoperationalqualities,bothdeterminingthetotalͲcostͲ ofͲownership
x Time–thedurationittakestodeveloptheproduct,hencethetimeͲtoͲmarket
x Cost–thecostofpersonnel,mostlywages,andcostsfortheinfrastructure,likePCs,servers, building.Typicallythelargestpartofthecostisdirectlyrelatedtothedevelopmenttimeand involvedstaff.
Problem
Individualrolesinasoftwaredevelopmentorganizationtypicallyspannotallfourcategories,hence decisionscaneasilybeconcentratedonscope,quality,time,orcostonly.Theclassicalseparationis asfollows.
x Projectmanagementtypicallyfeelsmostresponsibleforthetripleconstrainttime,cost,and developmentalquality,suchasregulatorycomplianceandavailabilityofalldocumentation artifacts.
x Productmanagementtypicallyfeelsmostresponsibleforscope,time,andcustomervisible quality,likeperformanceandusability.
x Technicalleadership(architects)typicallyfeelsmostresponsibleforscopeand developmentalaswellasoperationalquality.
Lettingonlyoneortwooftherolesdecideonastrategyleadstopotentiallyunbalanceddecisions.
Solution
Witheverydecisionmakesureyouhaveabalancebetweenthefourconstraintsthroughthe involvedroles.Atypicalsteeringcommitteeshouldconsistofrepresentativesfromallstreamsof leadership(projectmanagement,productmanagement,technicalleadership).Onlythiswayyoucan makesurethatsounddecisionswithproperriskassessmentarebeingmade.
Rationale
Thepartitioningbetweenprojectmanagement,productmanagement,andtechnicalleadershipisthe classicalseparation.Agilemethodologyapproachesprovideaslightlydifferentpartitioning,e.g.
Scrumproductownersaretypicallybroadersetupandcareabouttime,scope,andquality.The Toyotaapproach[10]wouldevengosofartointegrateallconstraintsintoasingleperson:thechief engineer.Ofcourseinthiscasethereisnoneedanymoretobalancetheconstraints,besidesmaking sureyoupickthe‘right’chiefengineerforyourbusinesssuccess.
E1Ͳ18
ReferencesandKnownUses
ManygroupsinSiemens,amongthemthepostalautomationgroupandthehotrollingmill automationgroup,intensivelyapplythispatterntotheiradvantage.Theyarewellawareofthe differentforcesofaprojectandusetherespectiveperspectivestotheadvantageofcreating innovativeandexcellentproducts.
Acknowledgements
WethankourshepherdJasonYipforhiselaboratecommentsandhispatience.Specialthanksalsoto ourWriter’sWorkshopgroupatEuroPLoP2009:ReneBredlau,EduardoFernandez,ClaudiusLink, KlausMarquart,DietmarSchütz,MarkusVölter,andAlainͲG.VouffoFeudjio.Inthispaperwebase onthefoundationslaidbyauthorslikeKlausSchmid,LindaNorthrop,andPaulClements.Our learningcontinuedoutoftheirproductlineengineeringexperiences.
Terminology
Coreasset–Asetofreusableartifacts,i.e.requirements,domainmodels,architecture,patterns, concepts,documentation,testcases,budgetplans,workplans,process,tools,workflowsandcode assets.
Platform–Thesumofallcoreassetsistypicallycalledtheproductlineplatform.However,theterm platformissometimesalsousedforabaseoftechnologiesonwhichothertechnologiesorprocesses arebuilt[1],e.g.anoperatingsystem,middlewareorcomponentcontainer.Inthispaperwereferto thefirstinterpretation.
Mission,Vision,Strategy–Mission=whydoIexist?Vision=wherewouldIliketobe?Strategy=
howwouldIliketogetthere?
TotalͲcostͲofͲownership(TCO)–Thesumofallcostsrelatedtodeveloping,maintaining,supporting, installing,servicing,andowningacertainproductoftheprovidingaswellasreceivingparty.
TimeͲtoͲmarket(TTM)–Thetimeittakestodeliveraproductfrominitialconceptiontoactual availabilityonthemarkettobeboughtbycustomers.Thelongerthedelaythehigherthechancesfor thecompetitionbringtheirproductsintothemarketandendangerthepotentialmarketsharefor theownproduct.
Projectmanagementtriangle–Thetriangledescribestheconstrainingrelationshipbetweenscope, time,andcostassumingthequalitytobefixed.Allareinterrelated;youcannotchangeanyofthem withoutadoptingtheothers[4].
Scoping–Scoping[1][3][5]isanactivitytofindtheboundariesofaproductlinethatcanbedivided intothreesubͲsteps[6][7]:productlinescoping,scopingthedomain,andscopingthereusableassets (platform).Theobjectiveofproductlinescopingcomprisesdefiningthesetofproductsandthemain featurestobeincludedintheproductline.Domainscopingrepresentstheprocessofidentifying appropriateboundariesforthesubͲdomainsoftheoverallproductline.Scopingtheassetsresultsin thedecisionwhichoftherequiredfunctionalityadevelopmentorganizationshouldimplementas reusablebaseassetsandwhichitshouldconsiderproductspecific.Forsimplicitywecansticktothe
E1Ͳ19
E1Ͳ20
followingdefinition:Scopingmeanssettingthefocusofreuseonthefunctionalitythatpromisesan optimalreturnoninvestment[8].
ApplicationandDomainEngineering–DomainEngineering(DE)isthesubͲprocessofPLEthatis responsibleforbuildingandmanagingreusablebaseassets,whileApplicationEngineering(AE)is aboutbuildingproductsorsolutionsfromthesebaseassets.Variationinorganizationforms–PLE organizationsmaybesplitinaDomainEngineeringpartthatisresponsibleforimplementingthecore assetsandseveralApplicationEngineeringpartsthatbuildproducts/solutionsbasedthecoreassets andaddingproductspecificfeatures.
Alternatively,PLEorganizationsmayaswellbedividedalongsubͲdomainsthatdoboth,
developmentofcoreassetsandproduct/solutiondevelopment.ThissetupiscommoninmaturePLE organizations,mostlyforsolutiondevelopment.Suchadivisionisveryefficientsincenohandover betweenthetwodisciplinesisnecessary.Howtosetupthebestorganizationforaproductline wouldbeapatternlanguageonitsown.
Proactiveevolution–Coreassetsareidentifiedupfrontanddevelopedforreuse.
Reactiveevolution–Creationofcoreassetsbasedonexisting,previouslyproductͲspecificassets.
E1Ͳ21
References
[1]Pohl,Böckle,vanderLinden,SoftwareProductLineEngineering,Springer,2005
[2]KlausSchmid,PlanningSoftwareReuse–ADisciplinedScopingApproachforSoftwareProduct Lines,Dissertation,FraunhoferIRBVerlag,2003
[3]Clements,P.&Northrop,L.SoftwareProductLines:PracticesandPatterns,AddisonͲWesley,2002 [4]http://en.wikipedia.org/wiki/Project_triangle
[5]K.CzarneckiandU.W.Eisenecker,GenerativeProgramming.Methods,Tools,andApplications.
Amsterdam:AddisonͲWesleyLongman,2000.
[6]JanBosch,DesignandUseofSoftwareArchitectures:AdoptingandEvolvingaProductͲLine Approach,AddisonͲWesleyReading,2000.
[7]KlausSchmid,SteffenThiel,JanBosch,SusanneJohnsson,MichelJaring,BernhardThomé, SiegfriedTrosch,Scoping,EASPSconsortiumwidedeliverableCWD1.2.4,2001.
[8]KlausSchmid,AComprehensiveproductLineScopingApproachandItsValidation,InProceedings ofthe24thInternationalConferenceonSoftwareEngineering(ICSE2002),ACMPress,2002,pp.593Ͳ 603
[9]XPguidance“Dothesimplestthingthatcouldpossiblywork”
[10]http://www.poppendieck.com/leadership.htm