Als infrastructuurarchitect bij Yacht krijgt Eric Kuik vaak te maken met opdrachtgevers die al sterk richting een bepaalde technische oplossing denken. "Vaak heeft men iets bij een andere organisatie gezien dat erg bruikbaar lijkt. Alleen neemt een stuk technologie niet zomaar iemands probleem weg. Wat ik dan eerst doe, is teruggaan naar wat het probleem is. De waarom-vraag. Wat is de functionele behoefte van de opdrachtgever? Van daaruit onderzoeken we samen mogelijke oplossingsrichtingen."

Doorgaans wordt er volgens Eric weinig rekening gehouden met essentiële aspecten van bijvoorbeeld beheer en beveiliging. "Het is mijn taak om ook deze zaken te belichten en ervoor te zorgen dat ze in de technische oplossing terugkomen." Daarbij is het bekend dat IT-projecten vaak niet opleveren wat er is beloofd of verwacht wordt. Volgens Eric is één van de grootste pijnpunten dat er voor infrastructuur nog gebruik wordt gemaakt van de watervalmethode, terwijl bij de ontwikkeling van software allang volgens Scrum gewerkt wordt. Deze twee methoden botsen.

Sneeuwbaleffect

De Scrummethodiek heeft grote voordelen. Dankzij een kort cyclische manier van werken is er veel flexibiliteit en wendbaarheid binnen een project. Er zijn kleine werkpakketten die vast omlijnde producten opleveren. Veranderingen in de requirements kunnen gaandeweg het project nog worden meegenomen. Voor een producteigenaar of opdrachtgever is het tastbaar wat er gebeurt en hij ziet wat hij straks krijgt. Infrastructuurprojecten worden volgens Eric echter gezien als een soort olietankers, die langzaam op gang komen en moeilijk zijn bij te sturen. "Dat dachten wij vroeger ook van softwareprojecten", zegt hij daarover. "Maar de ervaring leert dat ook bij infrastructuur in brokken functionaliteit gedacht kan worden, die niet per definitie van elkaar afhankelijk zijn. Zo kun je er wel degelijk wendbaarder mee omgaan als de behoefte verandert."

Bij de watervalmethode zijn veranderingen in de requirements ongewenst, omdat ze de loop van het project te veel verstoren. "En dat botst", zegt Eric, "want infrastructuur is een randvoorwaarde voor het succes van de software-oplossing." Er ontstaat dan een sneeuwbaleffect. "In de loop van de tijd gaan de twee oplossingen steeds verder uit elkaar lopen. Uiteindelijk past de infrastructuur niet meer bij de softwareoplossing. De opdrachtgever heeft mooie dingen gezien tijdens de demo's van de Scrumsessies, maar dat wordt niet waargemaakt."

Verstoring van het proces

Als voorbeeld noemt Eric een infrastructuurproject waarin een nieuw concept voor werkplekbeheer werd geïntroduceerd. Tegelijkertijd vonden er ontwikkelingen plaats aan het primaire informatiesysteem van de organisatie. De twee projecten waren sterk verweven, het informatiesysteem leunde sterk op het infrastructurele project. "Doordat het informatiesysteem zich sneller en dynamischer ontwikkelde, liep het aan tegen afhankelijkheidsproblemen met de werkplekomgeving. Vanuit het Scrumproject werd actief informatie gedeeld en de eisen naar het infrastructuurproject werden bijgesteld. Maar de programmamanager van infrastructuur zag dat als een change die pas in het na-traject kon worden opgelost, omdat het proces anders te veel werd verstoord. Alleen bleek het informatiesysteem bij de in-productie-name niet te werken op de nieuwe werkplek. De uitrol van werkplekken moest worden stopgezet, om alsnog een herstelactie uit te voeren. Met als gevolg dat er veel tijd en geld verloren ging."

Feedbackloop

Dit had voorkomen kunnen worden door aan de infrastructuurkant ook kort cyclisch volgens Scrum te werken. Daarnaast moeten de juiste stakeholders, de product owners, geïdentificeerd worden. Dan was er volgens Eric een wisselwerking geweest en waren de noodzakelijke wijzigingen wel gewoon meegenomen in het project. "Binnen de architectuur kennen wij hier een aantal mooie technieken voor. Zo wordt dit probleem heel goed onderkend door TOGAF, een van de grotere architectuur-ontwikkelmethodieken. Er is zelfs een mooi iteratief proces voor ingericht."

De drie-eenheid businessarchitect, informatiesysteemarchitect en infrastructuurarchitect komen hierbij in een soort cyclus tot bepaalde conclusies voor de architectuur, legt Eric uit. "Er ontstaat een soort feedbackloop. Beslissingen die ergens in de iteratie worden genomen, worden telkens getoetst aan het originele idee en de impact op de overige twee aandachtsgebieden. Dat zorgt ervoor dat de uiteindelijke oplossing veel dichter bij het verwachte en gecommuniceerde plaatje ligt dan momenteel het geval is."

Cultuuromslag

Waarom wordt Scrum zo weinig toegepast op infrastructuur? Volgens Eric is het niet alleen onbekendheid met de methodiek. Er is vooral een cultuuromslag nodig. "Ik heb inmiddels een aantal infrastructurele projecten volgens de Scrum-methode uitgevoerd en dat wordt als erg plezierig ervaren door het projectteam. Scrum heeft voor infrastructuur dezelfde voordelen als bij softwareontwikkeling en heeft ook nog een plezierige spin-off. Voor de organisatie wordt het project ineens heel zichtbaar en voorspelbaar. Beheerders worden minder snel nerveus, ze weten precies wat ze kunnen verwachten. Ze zien zich meer als onderdeel van het project en stellen zich minder strikt op als het gaat om processen en procedures. Je bouwt vertrouwen op en creëert sneller draagvlak voor het nieuwe platform en de projectmethodiek."

Toch blijkt er een addertje onder het gras te zitten. "Ondanks dat een project succesvol is afgerond en de doelen gerealiseerd zijn, wordt voor een volgende project al snel weer teruggegrepen naar de ouderwetse watervaltechniek. Oude gewoontes blijken moeilijk te veranderen. Er is echt een cultuuromslag nodig. Je hebt een aantal pioniers nodig binnen je organisatie die hiermee van start gaan en die doorzetten."

Spreekt het artikel je aan? Yacht is op zoek naar nieuwe pioniers die klaar zijn voor een mooie nieuwe uitdaging. Klik hier om te ontdekken welke uitdaging er voor jou klaarstaat.