Kennisdeling op het gebied van softwarearchitectuur

architectuur

t

Kennisdeling op het gebied van softwarearchitectuur

Kennisdelings problematiek bij Océ

In softwareontwikkeling is vaak sprake van een spanning tussen een top-down, door architectuur gedreven aanpak en een bottomup aanpak waarin de ontwikkeling van nieuwe producten onder druk van de markt prevaleert. De documentatie is minimaal, maar een zekere hoeveelheid is toch nodig om mensen effectief aan te sturen: de juiste kennis moet op het juiste moment wel bij de juiste mensen aanwezig zijn. Binnen Océ Technologies wordt onderzoek gedaan naar deze problematiek rond kennisdeling.

informatie / november 2010

Sybren Deelstra, John Kesseler, Antony Tang en Hans van Vliet

48

Architecten moeten veel kennis delen, met elkaar, maar ook met ontwikkelaars, testers, configuratiemanagers en dergelijke. Deze mensen echter willen eigenlijk een architectuur maken en software ontwikkelen en testen en zijn niet snel bereid hun kennis vast te leggen. Veel van die kennis blijft daardoor impliciet. Dit geldt temeer in agile omgevingen. Daar treedt een inherente spanning op tussen top-down sturing via voorschriften en architectuurspecificaties en bottom-up oplevering van nieuwe features. Met name in een multi-siteomgeving kan het gebrek aan expliciete documentatie gemakkelijk tot misverstanden leiden. In dit artikel wordt beschreven hoe binnen Océ Technologies wordt omgegaan met de problematiek rond kennisdeling op het gebied van architectuur.

Spanning tussen top-down en bottom-up aanpak In de meer klassieke ontwikkelaanpakken wordt softwarearchitectuur als heel belangrijk gezien. In pure agile benaderingen worden architec-

tuur en dikke documenten als overbodige ballast gezien, want alles zal uiteindelijk toch anders worden. Zoals zo vaak ligt de waarheid ergens in het midden en dus ontstaan er pogingen deze twee ogenschijnlijke tegenpolen met elkaar te verenigen (IEEE Software, 2010). Ook binnen Océ speelt deze problematiek. Ook hier is de druk van de markt erg aanwezig en is er de neiging om nieuwe producten te ontwikkelen via aanpassing van een reeds bestaand product. Océ opereert in een sterk door technologie gedomineerde markt, waar ingenieurs gedreven zijn om steeds nieuwe technische snufjes aan te bieden. Ontwikkelaars zullen dan moeite hebben een architectuurgedreven masterplan te volgen. Dit wordt nog eens versterkt door de gehanteerde agile ontwikkelmethode (Scrum), waarin kwaliteits- en ontwikkeldoelen voor de korte termijn het denken domineren. Er ontstaat dan een spanning tussen een nette top-down, door architectuur gedreven aanpak en een bottom-up benadering waarin de ontwikkeling van nieuwe producten onder druk van de

Samenvatting In een dynamische omgeving zoals die van Océ is kennisdeling op het gebied van softwarearchitectuur zelf ook dynamisch. Welke kennis wanneer en met wie gedeeld moet worden, kan verschillen per project, per vestiging en per punt in de tijd. Om optimaal in te spelen op veranderingen is een dynamische terugkoppeling nodig van informatie over wat gedeeld wordt en welke effecten dit heeft op productiviteit en kwaliteit.

In een snel veranderende omgeving als die bij Océ ligt het niet voor de hand dat de oplossing voor dit soort vraagstukken eenduidig en statisch is. Kennis over de architectuur, fouten en hun oorzaken, kosten en baten van beslissingen dient verzameld en gedeeld te worden in een feedback loop die betrokkenen in staat stelt continu te monitoren en waar nodig bij te sturen. In het vervolg van dit artikel zullen we enkele voorbeelden van dit soort feedback loop geven.

Agile ontwikkelen bij Océ Océ produceert onder meer een breed scala aan printers voor de zakelijke markt. Software speelt in deze printers een belangrijke rol. Deze software zorgt voor het weergeven van beelden en stuurt de print-engine aan. Océ opereert in een zeer competitieve markt waar het tijdig leveren van

nieuwe diensten een belangrijke succesfactor is. Om dit te bewerkstelligen wordt een agile ontwikkelproces gevolgd (Scrum), aangestuurd door een architectuurorgaan. Softwareontwikkelaars opereren veelal in teams van drie tot acht mensen. Aan de ontwikkeling van een nieuw product neemt een flink aantal teams deel, plus architecten, integrators en testers. Een ontwikkelcyclus duurt vrij kort. Elke acht weken is er een nieuwe versie van een product, met sprints van twee weken. Ontwikkelaars zijn zeer gemotiveerd en hebben veel domeinkennis. De documentatie is minimaal. Er heerst een op innovatie gerichte cultuur, waarbij de meest geschikte mensen aan taken worden toegewezen. Mensen rouleren regelmatig tussen projecten.

Wat levert hergebruik op? De vraag hier is wanneer een door architectuur gedreven ontwikkeling van gelijksoortige producten (een zogenoemde productlijn) de aangewezen weg is en wanneer men beter snel een nieuw product kan ontwikkelen door een bestaand product aan te passen. Ter illustratie van de hier optredende spanning gebruiken we een component van de besturingssoftware van printers. De betreffende component (Printer Controller Component, PCC) beheert de printopdrachten die naar een printer zijn verstuurd. Hoewel PCC specifiek gedrag vertoont per product, moet deze component ook consis tent gedrag vertonen richting de print-engine en de operator. Twee belangrijke onderdelen hierin zijn het behandelen van runtime tegenstellingen (RTC) en het behandelen van fouten zoals het vastlopen van papier. Een RTC treedt op als de printer tijdelijk stopt met printen omdat bepaalde resources op zijn. Voorbeelden hiervan zijn: een bepaalde invoerpapierlade is leeg, de uitvoerlade is vol, de nietjes zijn op. De besturingssoftware moet de RTC ontdekken en doorgeven en handelen naargelang de mogelijkheden van de betreffende printer.


markt prevaleert. De documentatie is minimaal, maar een zekere hoeveelheid is toch nodig om mensen effectief aan te sturen: de juiste kennis moet op het juiste moment wel bij de juiste mensen aanwezig zijn. In het kader van de regeling Kenniswerkers (zie www.senternovem.nl/kenniswerkers) onderzoekt een dertigtal medewerkers van Océ deze kennisdelingsproblematiek in samenwerking met onderzoekers van de Vrije Universiteit. In een aantal kleinere deelprojecten komt een breed scala aan onderwerpen aan de orde, zoals: • Hoe te bepalen of, en wanneer, een architectuurgedreven aanpak de voorkeur geniet boven het klonen van een bestaand product? • Wat moet een architect allemaal vastleggen en wat kan hij overlaten aan ontwikkelaars? • Welke kennis moet er gedeeld worden tussen vestigingen in verschillende landen? • Hoe te zorgen dat de informatie uit steeds veranderende eisen en architectuurdocumenten traceerbaar blijft? • Hoe te zorgen dat strategische informatie bij de juiste betrokkenen bekend is?

49

architectuur informatie / november 2010

50

t

In de afgelopen vier jaar zijn vier versies van PCC ontwikkeld. PCC-1 is van de grond af opnieuw ontwikkeld. PCC-2 werd min of meer tegelijk met PCC-1 ontwikkeld ten behoeve van een nieuwe reeks producten en hierin werd waar mogelijk de codebase van PCC-1 hergebruikt. Hetzelfde geldt voor PCC-3. PCC-2 en PCC-3 zijn dus klonen van PCC-1. Een belangrijke reden om te kiezen voor klonen was de verwachting dat de ontwikkeling van een gemeenschappelijke architectuur voor al deze producten te veel tijd zou kosten. Vrij snel nadat het werk aan PCC-3 was begonnen, deed zich een verschuiving voor in de prioriteiten van de business. Tevens werd duidelijk dat de gehanteerde aanpak de zaak steeds complexer maakte, en minder onderhoudbaar. Daarom werd besloten via een productlijnaanpak de ontwikkeling van PCC-4 te starten. Deze beslissing werd lokaal genomen, door een enkel productteam, met steun van het management. De vraag is nu of de architectuurgedreven aanpak (PCC-4) de voorkeur moet genieten boven de door klonen gedreven manier van werken als in PCC-1, PCC-2 en PCC-3. Er kunnen verschillende redenen zijn waarom men aarzelt over te gaan op een door een productlijnarchitectuur gedreven aanpak. Maar uiteindelijk is geld natuurlijk een belangrijke factor. Het is dan ook nodig om als organisatie te weten wat de financiële voordelen zijn. In een simpel model (Clements, McGregor & Cohen, 2005) bestaan de kosten uit: • Core Asset Base (CAB), de kosten voor het eenmalig ontwikkelen van de herbruikbare core assets; • specifieke kosten voor het ontwikkelen van specifieke features boven op de CAB; • kosten voor het hergebruiken van CAB voor elk nieuw product (extra tests die nodig zijn, eventueel lokale aanpassingen aan CAB enzovoort). Voor PCC-1 en PCC-4 zijn deze drie soorten kosten (in fictieve eenheden, waarbij de totale kosten voor PCC-1 op 100 zijn gesteld) op een rijtje gezet in figuur 1. Hieruit blijkt dat investeren in een productlijnarchitectuur de moeite waard kan zijn.

PCC-1 PCC-4

CAB

specifieke kosten

hergebruikkosten

41.5 23

26.5 10.5

32 2.5

totale kosten 100 36

Figuur 1. Relatieve kosten voor ontwikkelen met en zonder productlijnarchitectuur In de figuur zijn twee effecten zichtbaar. De lagere (initiële) CAB-kosten voor PCC-4 ten opzichte van PCC-1 zijn voor een belangrijk deel te verklaren uit het leereffect omdat dezelfde functionaliteit voor de tweede keer werd gebouwd. Overigens is de ontwikkelinspanning van PCC-2 en PCC-3 niet geadministreerd, vandaar dat deze niet in de figuur te vinden is. Het andere effect is nog groter: de winst als gevolg van de productlijnaanpak zit vooral in de lagere hergebruikkosten, in dit geval vooral de lagere kosten voor benodigde tests. Om te kunnen bepalen of het de moeite waard is van de ene vorm van softwareontwikkeling over te stappen naar de andere is kennis nodig, en deze kennis moet gedeeld worden met de juiste partijen. Op technisch niveau moeten architecten en ontwikkelaars weten wat de principes van productlijnarchitectuur zijn en of die toepasbaar zijn in hun specifieke omstandigheden. Kosten en opbrengsten moeten gemeten worden om het besluitvormingsproces op zowel technisch niveau als managementniveau te ondersteunen. De terugkoppeling van deze kennis, zoals ontwikkeld in het lopende kenniswerkersproject binnen Océ, wordt geschetst in figuur 2. Het op het juiste moment delen van kennis tussen betrokkenen kan veel van de spanning tussen een wel of niet architectuurgedreven aanpak wegnemen. Dit is een iteratief proces. Eenmaal genomen beslissingen kunnen immers onder invloed van marktwerking, nieuwe technologie of andere mensen veranderen.

Hoeveel moet de architect vastleggen? De specificaties die een architect maakt, kunnen verschillen qua detailleringsniveau. Waarom sommige details in de ene specificatie wel worden opgenomen en in de andere niet, is niet altijd duidelijk. Of het nodig is die details op te nemen, is eveneens niet altijd duidelijk. Het gevolg hiervan kan zijn dat ontwikkelaars beslissingen nemen die leiden tot fouten. Deze komen vervolgens als een soort boemerang terug bij de architect in de vorm van probleemrapporten waarop de architect

een reactie moet geven. Deze komen bij de architect terecht omdat de ontwikkelaar bijvoorbeeld geen eigenaarschap voelt voor een oplossing die de architect in zijn ogen vergeten is te specificeren, of omdat de oplossing voor de problematiek meerdere onderdelen van de software betreft. De architect kan om verschillende redenen besluiten bepaalde beslissingen niet expliciet vast te leggen: • Het kan hem niet schelen: elke oplossing voor een bepaald issue is wat hem betreft even goed. • Het is (in zijn ogen) vanzelfsprekend welke optie(s) de ontwikkelaars hebben, bijvoorbeeld omdat iets soortgelijks al in een eerder product voorkomt. • Hij heeft geen tijd om alle details vast te leggen. • Het is de persoonlijke voorkeur van de architect. Als een architect bij herhaling werkt met hetzelfde team van ontwikkelaars, zal er na verloop van tijd een vorm van samenwerking ontstaan die goed werkt: de architect legt vast wat belangrijk is en weet wat hij veilig aan de ontwikkelaars kan overlaten. Kennisdeling treedt op waar dat nodig is en wordt achterwege gelaten waar het niet zinvol is. De situatie binnen Océ is echter niet statisch. Ontwikkelaars rouleren tussen projecten. Nieuwe producten en nieuwe technologieën vragen om nieuwe oplossingen. Wat vandaag vanzelfsprekend is, is dat morgen niet meer. Wat bij het ene project probleemloos loopt, gaat bij een ander project veel minder vlekkeloos. Ook hier ligt een feedback loop

voor de hand, bijvoorbeeld door tijdens ontwerp bij te houden welke beslissingen aan de ontwikkelaars worden overgelaten en een root-cause-analyse uit te voeren op gevonden fouten tijdens ontwikkeling en na release. Zo wordt niet alleen de werkwijze verbeterd, maar leert de architect ook waar hij meer kennisdeling nodig heeft.

Kennisdeling tussen vestigingen De software van Océ wordt bij verschillende vestigingen ontwikkeld. De hoofdvestiging is in Venlo en daarnaast wordt een deel van de software ontwikkeld in onder meer Roemenië en Frankrijk. De vestiging in Venlo is beduidend groter dan die in Roemenië en Frankrijk. De vraag is of de mate van kennisdeling tussen de hoofdvestiging in Venlo en de vestigingen in Roemenië en Frankrijk van invloed is op de kwaliteit (gemeten in termen van productiviteit, aantal gevonden fouten en dergelijke). Het onderzoek door medewerkers van de VU en Océ brengt aan het licht dat dit niet het geval is. De interviews en data-analyse laten duidelijk zien dat Océ de afstandsbarrière succesvol overbrugd heeft, via diverse wegen: • Betrokkenen kennen elkaar goed. Er zijn veel persoonlijke contacten. Er is zowel gestructureerde communicatie in de vorm van regelmatige bijeenkomsten als ongestructureerde communicatie via bijvoorbeeld de telefoon. • Men deelt kennis vrijelijk. De platte organisatiestructuur bevordert de communicatie tussen vestigingen.

software management strategy

technical and product roadmaps

software refactoring cost

+ve

-ve

+ve

software maintenance cost

architectural level decisions

-ve

product line architecture

+ve

time-to-market

neu

+ve

neu

software quality

Figuur 2. Kennisfeedback-loop bij productlijnontwikkeling

-ve new investment


-ve

LOPXMFEHF GFFECBDLMPPQ

development methodology

NJHSBUJPO

legacy architecture

software management level decisions

51

architectuur

t

Wel valt op dat veel kennis in de hoofden van mensen zit. Door de veel langere historie van de vestiging in Venlo en het feit dat die vestiging veel groter is, is daar de meeste kennis, en veel van die kennis is voor de betrokkenen aldaar vanzelfsprekend. Die kennis hoeft dus niet expliciet gedeeld te worden. Zodra die kennis belangrijk wordt voor een andere vestiging, is aandacht geboden. Naarmate de tijd voortschrijdt, neemt de kennis bij de andere vestigingen toe en treden er minder issues op die te wijten zijn aan het ontbreken van deze zogenaamd ‘vanzelfsprekende’ kennis. Maar dit kan ook tot gemakzucht leiden, waarbij bijvoorbeeld essentiële kennis over nieuwe technologieën niet gedeeld wordt waar dat nu juist wel van belang is. Een feedback loop om dit soort problemen te verminderen kan klein beginnen. Een concrete invulling is om resultaten van technologieonderzoeken op te nemen in het maandelijks afdelingsverslag en dit verslag ook met de andere vestigingen te delen. Andere voorbeelden zijn kennis over besluitvorming een vast onderdeel te maken van de reguliere retrospectives of planningen ook rond te sturen naar de teams waar niet direct in hetzelfde project mee wordt samengewerkt.


Kennisdeling via een semantische wiki

52

Eisen- en architectuurdocumenten kunnen gemakkelijk conflicterend en inconsistent zijn of dat in de loop der tijd worden. Hiervoor zijn ten minste drie redenen te noemen. Ten eerste is kennis verspreid. Er zijn veel belanghebbenden betrokken bij systeemontwikkeling en elk van die belanghebbenden weet slechts een deel. Marketingmensen weten wellicht wat ze willen, maar niet hoe dat gerealiseerd kan worden. En voor architecten geldt vaak het omgekeerde. Er zijn nogal wat mensen betrokken bij het specificeren van de eisen: marketingmensen, businessmanagers, technologiespecialisten enzovoort. De architectuur wordt bepaald door onder anderen architecten, netwerkspecialisten en security specialisten. Een dreigend gevaar hiervan is dat de specificaties die door beide groepen mensen worden opgesteld, conflicterend en inconsistent kunnen zijn.

Ten tweede is de informatie niet volledig. Niet alle informatie wordt expliciet vastgelegd en is vindbaar. Sommige kennis blijft alleen in de hoofden van direct betrokkenen. Conflicten tussen eisen en architectuur kunnen zo lang verborgen blijven. Ten derde zullen eisen en architectuur vaak tegelijkertijd evolueren. Door onderhandelingen, beslissingen en het zoeken naar oplossingen evolueren de eisen en ook het inzicht in hoe deze kunnen worden gerealiseerd. Businessmanagers bijvoorbeeld kunnen prestatie-eisen formuleren waarvan pas na analyse door een architect blijkt dat ze niet haalbaar zijn. Het gevolg is dat ze moeten worden aangepast. Als gevolg van dit alles zullen de ontwikkeling van eisendocumenten en de ontwikkeling van architectuurdocumenten elkaar in tijd overlappen. Om belanghebbenden in staat te stellen te communiceren over relaties en conflicten tussen deze twee typen documenten, is het dus nodig dat eisen en de bijbehorende architectuuronderdelen wederzijds traceerbaar zijn. Hier zijn al de nodige oplossingen voor bedacht, maar die leveren steeds statische verbindingen tussen eisen en architectuur. Dat leidt natuurlijk tot problemen als beide typen documenten blijven veranderen. Bij Océ experimenteren we daarom met een semantische wiki om traceerbaarheid tussen veranderende eisen- en architectuurdocumenten te ondersteunen. We gaan hierbij uit van een algemeen metamodel dat vijf sleutelconcepten kent: • identificatie van een document gebruikmakend van de Dublin Core-standaard (Powell e.a., 2007); • eisen, zowel functioneel als niet-functioneel; • belanghebbenden, klassen van mensen die (mede) de eisen bepalen; • beslissingen die genomen zijn met betrekking tot de realisatie van eisen; • architectuur, zijnde de resultaten van genomen beslissingen. Met behulp van dit model kunnen eisen- en architectuurdocumenten worden geïndexeerd en geannoteerd. Architecten en analisten kunnen met behulp hiervan deze documenten bevragen. Verdere details zijn te vinden in Tang e.a. (2011).

Wie vertel ik over roadmaps? De architectuur wordt beïnvloed door toekomstige eisen en technologieën. Deze worden vastgelegd

in zogenoemde roadmaps. Een roadmap beschrijft voorziene ontwikkelingen op een bepaald terrein, bijvoorbeeld verwachte nieuwe technologiestandaarden of productfeatures die de markt verwacht. Op elk moment in de tijd zijn er binnen Océ Technologies zo’n vijftien of meer roadmaps die relevant zijn voor de ontwikkeling van nieuwe producten. Zij komen voort uit verschillende afdelingen van het bedrijf. Enerzijds dient een flink aantal mensen, zoals architecten, integratietesters en managers op verschillende niveaus, op de hoogte te zijn van bepaalde roadmaps om hun werk naar behoren te kunnen doen. Anderzijds dient verspreiding van deze roadmaps zo veel mogelijk beperkt te worden. Ze bevatten immers strategische informatie, die van cruciaal belang kan zijn voor de concurrentiepositie van het bedrijf. Wij hebben onderzocht hoeveel kennis verschillende betrokkenen hebben van de aanwezige roadmaps en hoeveel ze eigenlijk zouden moeten weten. Het blijkt dat geen van de betrokkenen alle roadmaps kent en dat veel betrokkenen minder roadmaps kennen dan ze zouden moeten kennen. Dit leidt tot enkele interessante vragen die momenteel onderzocht worden: • Hoe kunnen we een kennisterugkoppelingsmechanisme introduceren dat ervoor zorgt dat de juiste mensen op de hoogte worden gesteld van updates in de roadmaps die hun werk beïnvloeden? • Wat is de juiste granulariteit voor dit soort informatie, zodat eenieder genoeg informatie heeft om zijn werk te doen, maar tegelijkertijd om veiligheidsredenen strategische informatie wordt onthouden aan hen die de informatie niet echt nodig hebben.

Conclusie Kennisdeling op het gebied van softwarearchitectuur beslaat een breed terrein. In een dynamische omgeving als die binnen Océ Technologies is kennisdeling zelf ook dynamisch. Welke kennis wanneer en met wie precies gedeeld moet worden, kan per project, per vestiging en per punt in de tijd verschillen. Een dynamische terugkoppeling van informatie over wat gedeeld wordt en welke effecten dit heeft op productiviteit en kwaliteit, is dan ook nodig om optimaal op veranderingen in te spelen. Reviewer Paul Teeuwen

Literatuur Clements, P.C., J.D. McGregor & S.G. Cohen (2005). The structured intuitive model for product line economics (SIMPLE). CMU/SEI-2005-TR-003. IEEE Software 27.2 (2010). Special issue on Agility and Architecture. Powell, A. e.a. (2007). Dublin Core Metadata Initiative – abstract model, http://dublincore.org/documents/abstractmodel. Tang, A. e.a. (2011). Supporting Co-evolving Architectural Requirements and Design through Traceability and Reasoning. In P. Avgeriou e.a. (red.), Relating Software Requirements and Architectures. Springer Verlag. Link www.senternovem.nl/kenniswerkers Sybren Deelstra is software project manager bij Océ. E-mail: sybren.deelstra@ oce.com. John Kesseler is hoofd R&D Software Engineering bij Océ. E-mail: john. [email protected]. Antony Tang is senior onderzoeker aan de Vrije Universiteit. E-mail: [email protected]. Hans van Vliet is hoogleraar software engineering aan de Vrije Universiteit. E-mail: [email protected].

informatie over wat gedeeld wordt en welke effecten dit heeft op productiviteit en kwaliteit, is nodig om optimaal op veranderingen in te spelen

«


»Een dynamische terugkoppeling van

53

Kennisdeling op het gebied van softwarearchitectuur

Recommend Documents