“Ze hebben het over agile en lean…“

Toen ik onlangs bij één van mijn relaties op bezoek was, stelde hij de opmerkelijke vraag of ik in mijn netwerk nog wat ouderwetse website ontwikkelaars had zitten. Ik moest er om lachen en stelde uiteraard de wedervraag waar hij op doelde. Hij vertelde dat zijn 6 jaar oude webshop nodig aan vernieuwing toe was en dat hij een viertal partijen had uitgenodigd om te horen of zij hem konden helpen.

“Ik wist niet wat ik hoorde” sprak hij met verontwaardigde toon. “Ze hebben het maar over ‘agile‘ en ‘lean‘! Iedereen is aan het ‘scrummen‘. Het gaat over ‘sprints‘ en over ‘user story’s‘. Het old-school planbord heeft plaats gemaakt voor een Kanban board. En oh ja, iedereen heeft de mond vol over ‘continues improvement‘…”

Zijn verontwaardiging en onbekendheid met de materie hadden geleid tot een zekere mate van irritatie. En die was kennelijk zo hoog opgelopen dat geen van de partijen nog in staat was geweest om tot hem door te dringen toen men de voordelen ging benoemen. In alle rust mocht ik een poging wagen. En dus hadden we het al snel over het verkorten van de ‘time-to-market‘, over de mogelijkheid om tussentijds invloed uit te oefenen op het resultaat, over het inzicht tijdens en op het proces, en over een optimale ‘Return On Investment‘.

Ik legde hem uit dat het conventionele ontwikkelproces niet meer past in deze tijd. Hij had namelijk verwacht dat er allereerst een functioneel ontwerp zou worden gepresenteerd. En dat ontwerp zou, na zijn goedkeuring, aan de basis hebben gelegen van de feitelijke ontwikkeling. Waarschijnlijk had er tussen het eerste contact en de feitelijke oplevering een periode van enkele maanden gezeten. En dan was het nog maar de vraag of hetgeen hij voor ogen had ook daadwerkelijk werd geleverd.

“U ser experience en customer journey werd met regelmaat genoemd”

“Vandaag de dag doen we dat anders” mocht ik hem uitleggen. Iedere ontwikkelpartij weet dat zijn klanten meer dan ooit om snelheid en flexibiliteit vragen. ‘Business rules‘ en naar het zich laat aan zien gaat dat ook nooit meer veranderen. Als marketing vandaag iets bedenkt wil men dat bij voorkeur morgen al live hebben. En daar houdt het niet mee op. Men wil uit kunnen proberen. Men wil kunnen testen wat bijvoorbeeld de impact is van het veranderen van een kleur van een button, om maar iets basaals te noemen. Mijn gesprekspartner onderbrak mij: “O ja, daar hadden ze het ook allemaal over… ‘user experience‘ en ‘customer journey‘ werd met regelmaat genoemd”. Ik deed een poging om hem uit te leggen wat dat dan behelst. “Bottom line is dat je je gebruikers en bezoekers zoveel als mogelijk de hoogste kwaliteit wilt leveren. En die kwaliteit moet er uiteindelijk toe leiden dat ze, zoals bij jou het geval is, meer gaan bestellen, als ambassadeur op gaan treden, terug komen, enzovoort”.

Langzaamaan zag ik hem ontdooien. Hij begon de voordelen er van te zien en zou het allemaal nog even laten bezinken. Ik vroeg mij af of hij het allemaal wel had begrepen. De vraag die hij vervolgens stelde maakte echter in één keer duidelijk dat hij weldegelijk in zag wat dit alles behelsde. Hij zei namelijk dat deze ontwikkelingen ook bij ons (ik werk voor een gerenommeerde Managed Services Provider) het nodige teweeg zou brengen. En daarmee sloeg hij de spijker op zijn kop.

“Alles moet sneller dan snel”

De beweging die in gang is gezet leid er toe dat ook Managed Service Providers moeten veranderen. En liever vandaag dan morgen. Vanuit een conventioneel perspectief gezien faciliteren zij Ontwikkel, Test, Acceptatie en Productie omgevingen (voor de kenners: de befaamde OTAP straat). Deze straat wordt gebruikt om op een gestructureerde wijze nieuwe releases uit te rollen. Geheel in lijn met ITIL processen . Het op deze wijze implementeren van nieuwe applicaties draagt bij aan een hoge mate van kwaliteit en een doorgaans voorspelbaar resultaat. Maar uiteraard zijn er ook nadelen. Zeker als we die afzetten tegen het al eerder genoemde ‘continues improvement‘. Eén van de belangrijkste is misschien wel de doorlooptijd. Want hoe flexibel je als organisatie ook bent, het doorlopen van een OTAP proces kost nu eenmaal tijd. En tijd dat is vandaag de dag zo’n beetje het sleutelwoord. Alles moet immers sneller dan snel.

Mijn gesprekspartner was uiteraard benieuwd hoe onze branche daar dan op inspeelt. Ik liep naar een whiteboard en schreef daar twee woorden op: automatiseren en cultuur. Dat was de kapstok van de rest van mijn betoog.

“Faciliteren van continuous delivery encontinuous integration”

“Als een ontwikkelaar allerlei tools en werkwijzen omarmt die moeten leiden tot een versnelde implementatie van nieuwe software (of dat nu een applicatie of een website is) dan zal de partij die de infrastructuur faciliteert en het beheer voor rekening neemt daar ook zijn voorzieningen voor moeten treffen. En dus verwacht men dat ook zij daar in mee gaan. Dat automatisering van processen daarbij van cruciaal belang is spreekt voor zich. Feitelijk hebben we het dan over het faciliteren van ‘continuous delivery‘ en ‘continuous integration‘. Niet zo simpel om dat in een paar woorden uit te leggen, maar het komt er op neer dat we het proces van ontwikkeling naar test, naar acceptatie en naar productie zo veel als mogelijk automatiseren. Zaken die we gewend waren om ‘handmatig’ te doen, doen we nu via allerlei tooling. Puppet, OpenStack, Chef en Jenkins zijn wat voorbeelden, maar daar houd het zeker niet mee op”. De niets verhullende blik tegenover mij, zei mij dat ik in moest binden. Ik was namelijk met iets te veel enthousiamse begonnen aan de onderwerpen containerization en micro services en haalde ‘en passant‘ ook nog even container management, orchestration en workflow management aan. En dan was ik nog niet eens toegekomen aan AWS, Azure, Digital Ocean en alle andere public cloud providers waar we ‘iets’ mee moeten.

“Automatisering zorgt voor versnelling van processen, maar draagt tevens bij aan het elimineren van fouten.” vervolgde ik mijn betoog. “De kwaliteit neemt dus toe, niet alleen van de code, maar ook van de onderliggende service. Maar er zijn nog meer voordelen. Juist vanwege de enorme versnelling van processen is het nu mogelijk om relatief kleine wijzigingen uit te rollen en desgewenst op een beperkt publiek te testen.” Ik haalde de al eerder genoemde kleur van een button aan. “Er zijn allerlei mechanismen om een wijziging niet direct voor iedereen beschikbaar te maken, maar om dat batch gewijs te doen. Valt het resultaat tegen? Dan draai je het terug. Doet het wat je verwachtte dan geef je iedereen die nieuwe functie. We passen daarvoor ‘canary releasing‘ en ‘A/B testing‘ toe. Facebook doet niet anders. Er zijn over de gehele wereld diverse releases in omloop. Alles wordt nauw gezet gemonitord en geanalyseerd, maar tegelijkertijd is de beschikbaarheid gegarandeerd.”

[alert type=”info” title=”Wilt u weten welke managementopleiding bij u past? “] Klik hier en u weet het direct

“En wat doet dat allemaal met jullie beheerders?” hoorde ik van de andere kant van de tafel. “Die moeten dan toch ook veranderen?” Dat bleek een prima bruggetje te zijn naar het volgende onderwerp: cultuur.

DevOps: Development en Operations kruipen als het ware tegen elkaar aan

“Om mee te gaan in de ontwikkeling van software ontwikkeling moeten alle betrokken disciplines drastisch veranderen. We zullen meer dan ooit moeten samen werken. Een beheerder moet weten wat een ontwikkelaar drijft en vice versa. Er zal sprake moeten zijn van een gezamenlijk project, een gezamenlijk doel en een gezamenlijke inspanning. Tooling, processen en beloning zullen op elkaar afgestemd moeten worden. Geen eilandjes meer en geen ‘dit is niet mijn probleem‘-mentaliteit. Kortom, een gedeelde verantwoordelijkheid. En zo komen we op dat andere fenomeen uit deze tijd: DevOps. Development en Operations kruipen als het ware tegen elkaar aan. De van oudsher aanwezige scheidslijn moet beslecht worden, maar je kunt je voorstellen dat dat verder gaat dan sec het faciliteren van automatisering. Het is een complete cultuurverandering die zowel bij de gemiddelde softwareontwikkelaar als bij een managed service provider nog flink wat voeten in aarde zal hebben, maar er wordt aan gewerkt!” 

Lekker ouderwets

Het ‘luisterend oor’ stond op en vroeg of ik nog een kop koffie wilde. Ik liep met hem mee naar de keuken en was blij verrast te zien dat hij nog filterkoffie zette. “Of duurt dat je te lang?” vroeg hij. Ik schudde nee. Sommige dingen moet je lekker ouderwets laten.

Auteur: Robèr van den Brink, momenteel werkzaam als Business Unit Manager bij CloudMerge B.V. Robèr is een ervaren sales executive met een grote affiniteit voor IT/ICT. Hij is gespecialiseerd in het creëren van waarde voor klanten, met de wensen van de klant als absolute uitgangspunt. Zijn passie voor technologie, sales en waardecreatie is hetgeen wat hem zo gedreven maakt om het beste advies te geven.

 

Mogelijk ook interessant

In het verlengde van de inhoud van de artikelen op onze website, biedt Utrecht Business de mogelijkheid op het onderwerp/vakgebied een opleiding te volgen. Hiertoe worden verschillende varianten aangeboden.