De veranderingen in software-ontwikkeling van de afgelopen jaren gaan in sneltreinvaart door. Klanten, en met name degene die al enige tijd niet meer met ontwikkelpartijen te maken hebben gehad, worden verrast met volstrekt nieuwe terminologie en werkwijzen. En niet alleen klanten van ontwikkelpartijen worden daarmee geconfronteerd. Ook de service-providers moeten mee in deze veranderende wereld.
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 zes 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 continuos 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 (roi).
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.
Snelheid en flexibiliteit
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 kunnen uitproberen. 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.
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.
‘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.
Elimineren van fouten
‘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.’
‘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
‘Om mee te gaan in de ontwikkeling van software ontwikkeling moeten alle betrokken disciplines drastisch veranderen. We zullen meer dan ooit moeten samenwerken. 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 geslecht 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.
@Marcel: dit ben ik niet helemaal met je eens. Om hier een goede uitspraak over te kunnen doen moet je mijns inziens het totaalplaatje van deze klant kennen.
Als de webshop zijn, zoals bij een Bol.com, core business is heb je absoluut gelijk.
Maar stel dat deze klant zich in een niche-markt bevindt met zijn product, waarbij de webshop “slechts” ter ondersteuning / aanvulling op zijn winkel is, dan is de toegevoegde waarde van het continu veranderen / aanpassen vele malen kleiner. Je kunt je dan zelfs afvragen of de IT kosten van een continuous delivery benadering wel opwegen tegen de baten.
Marcel, technicus schrijft niet dat je geen continuous delivery moet doen, maar dat het vooral handig is dat je de taal van de klant spreekt. En zoals PaVaKe zegt, als je in de basis eenmalig iets nodig hebt, dan hoef je niet alles in te richten alsof je doorlopend gaat ontwikkelen.
Beste artikel over software ontwikkelen dat ik sinds jaren heb gelezen! Zeer positief over software testen ook! Super Robèr!!! Heb je een Twitter of Facebook account wat we kunnen volgen? Echt top top top!
Prima artikel, hooguit wat lang. En wat mij betreft is er naast ‘Automatisering van de automatisering’ en ‘Cultuur en multidisciplinair samenwerken’ nog een derde niet te onderschatten aspect aan de DevOps beweging, nl. ‘Leren uit productie en continu verbeteren’. Daarmee bedoel ik dat we bij vernieuwing/ontwikkeling doelbewust vertrekken vanuit de huidige stand van zaken (dat weet Beheer nl als geen ander) en dat we de veranderingen continu (op productie!) monitoren om te beoordelen of het ook daadwerkelijk verbeteringen zijn geworden. En als daar dan aanleiding toe is dat we deze nieuwe informatie verwerken bij volgende ontwikkelingen. Zodat het product steeds beter wordt.
Dat gezichtspunt mis ik in dit artikel.