Sharing IT Best Practices with youSharing IT Best Practices with you
Al jarenlang is een trend waar te nemen van een stijgende behoefte van kortere time-to-market en een betere voorspelbaarheid. Steeds meer is de ICT daar een succes of een blokkerende factor in. Met de komst van business DevOps worden steeds meer bedrijven hier succesvol in en weten de concurrentie te verslaan. Maar wat is er nu precies de factor die het verschil maakt bij business DevOps? Dit artikel geeft daar een antwoord op in de vorm van het concept Continuous Everything.
Het basisprobleem dat bedrijven moeten oplossen is gelegen in het verhogen van de doorloopsnelheid van requirement naar nieuwe aangepaste ICT-services die outcome verhogend zijn alsmede de resulterende kwaliteit van de gepubliceerde ICT-services. De oorzaak van het niet kunnen verkorten van de leadtime en het kunnen verhogen van het percentage van ICT-services dat complete en accuraat is blijkt te liggen in twee oorzaken. De eerste oorzaak is technical debt. Dit vaak door kortetermijnoplossingen die bedacht zijn om aan de behoefte van de business te kunnen voldoen, terwijl de gedegen oplossing nooit wordt aangebracht. De tweede oorzaak is gelegen in het feit dat door een cumulatie van technical debt in zowel het voortbrengingsproces als in de ICT-services die in productie zijn genomen er een fragiliteit is ontstaan. Bij de minste of geringste aanpassingen ontstaan grote incidenten die moeilijk op te lossen zijn. Daardoor worden wederom snel noodoplossingen bedacht die alleen meer de situatie vereisen. Het bedrijf is in een neerwaartse spiraal gekomen.
Om tot een opwaartse spiraal te komen moet de technical debt op een 18-tal gebieden worden bestreden om tenslotte te komen tot het oplossen van de fragiliteit. De meest probate manier om dit te doen is middels een quick-scan uit te voeren op de business DevOps capabilities voor zowel People, Process als Technology (PPT) die dekkend zijn voor deze probleemstelling van technical debt en fragiliteit. Op basis van de grootste control gebreken kan dan een tegenmaatregel worden gezocht teneinde die technical debt en de fragiliteit te elimineren.
Een knelpunt hierbij is het feit dat business DevOps niet is gedefinieerd. Daarom wordt binnen het concept van CE gebruikt gemaakt van de DevOps lemniscaat, zoals weergegeven in figuur 1. De linkerkant van de lemiscaat is de Development kant van DevOps en de rechterkant de Operations kant van DevOps. Hiermee ontstaat een totaal plaatje van de stadia die binnen DevOps te doorlopen zijn.
Figuur 1, Business DevOps Lemniscaat.
De fasen zijn rudimentair en op de compleetheid en volgordelijkheid er valt zeker op af te dingen. Toch geeft dit lemniscaat een kapstok om de quick-scan uit te voeren. De fasen duiden op begrippen die niet nieuw zijn. Daarom is het belangrijk om de inhoud van de fase en de wijze waarop de fase doorlopen dient te worden te duiden. Dit wordt gedaan door de fasen te vertalen naar capabilities die een holistische en continue control bieden.
De termen holistisch en continue hebben we vertaald naar Continuous. De verschillende Continuous aspecten van business DevOps hebben we vertaald naar Everything. Zo is de term Continuous Everything ontstaan die dus duidt op het gegeven dat het hele voortbrengingsproces van een ICT Services en de resulterende ICT-services in de productieomgeving Continuous in control is voor Everything (alle fasen). Tabel 1 geeft aan hoe de fasen vertaald zijn naar CE-aspecten.
| Development | Operations | ||
| 1 | Continuous Planning (Plan) | 6 | Continuous Deployment (Release) |
| 2 | Continuous Documentation (Design) | 7 | Continuous Monitoring (Monitor) |
| 3 | Continuous Testing (Test) | 8 | Continuous Learning (Learning) |
| 4 | Continuous Integration (Code) | 9 | Continuous Auditing (Alle fasen) |
| 5 | Continuous Deployment (Deploy) |
Tabel 1‑1, Continuous Everything aspecten.
Binnen Scrum (een agile softwareontwikkelmethode) wordt vaak veronderstelt dat er alleen per sprint een planning wordt gemaakt en dat niet verder dan de horizon van een sprint kan worden gekeken. Voor de time-to-market is dit echter wel noodzakelijk. Continuous Planning borgt die op basis van het concept ‘Roadmap to Value’ van Mark C. Layton. Dit concept stelt dat de sprint planning volgt op een vision statement, product roadmap en release planning. Daarmee wordt de business de mogelijkheid gegeven om hun marketingstrategie te ontwikkelen. De planning wordt uiteraard vastgelegd in de product backlog maar deze wordt niet alleen gebruikt voor een sprintplanning maar ook voor een minimal viable product (MVP) planning die per kwartaal wordt bijgehouden om invulling te geven aan de roadmap. Verder wordt er niet alleen gepland op basis van business behoefte maar ook op basis van de technical debt backlog (Technology & Processes). Deze omvat ook op de ontwikkelkant van de competenties van de mensen (People). DevOps medewerkers moeten afhankelijk van de situatie een percentage van de tijd besteden aan deze technical debt backlog om de fragility te elimineren.
Bij veel systemen is er niet veel gedocumenteerd en als het al zo is dan is op velerlei wijze en is de informatie verouderd. Bij Continuous Documentation wordt er vanuit gegaan dat alle informatie die nodig is om een ICT-service te bouwen of te beheren wordt gedaan vanuit één centrale repository die versiebeheer doet van alle objecten. Een onderdeel van deze objecten zijn de requirements. De documentatie moet niet geschreven worden maar gegenereerd worden op basis van de requirements die onder versiebeheer ontwikkeld en beheerd worden. Dit kunnen objecten zijn als value streams, use case diagrams, use cases, BDD-requirements, mark-up language in sourcecode etc zijn. Wat factor continuous betekent hier dat de documentatie altijd up-to-date is en gekoppeld is aan de voortgebracht sourcecode en de planning van de realisatie van de ICT-services. De PPT factor betekent dat niet alleen de ICT-service wordt gedocumenteerd maar ook het voortbrengingsproces en de kennis en de kunde om die uit te voeren.
In de context van kortere time-to-market en een betere voorspelbaarheid is de borging van de kwaliteit één van de belangrijkste onderwerpen. Waarbij testen in verleden vaak enkel werd gebruikt om te bekijken of functionaliteit voldeed aan de eisen zien we nu testen meer als design en validatie. Door vooraf goed te beschrijven wat de verwachtingen zijn en deze vervolgens automatisch te valideren wordt de time-to-market verkort en de voorspelbaarheid verhoogt. Het continuous testing geeft invulling aan de concepten van Behaviour Driven Development (BDD) en Test Driven Development (TDD). Hierdoor ontstaat een continuïteit in het schrijven van software terwijl de testcases al klaar staan. Continuous Testen houdt ook in dat niet alleen de software wordt getest maar ook de processen en de kennis en kunde van de betrokken medewerkers.
Dit aspectgebied van CE betreft het samenwerken met meer ontwikkelaars aan dezelfde oplossing waarbij hoog frequent wordt vastgesteld dat de oplossing als geheel goed functioneert. Dit betekent in de praktijk dat een ontwikkelaar meer keren per dag zijn gedeelte van de sourcecode pushed naar de repository waarna de code automatisch wordt gebouwd, getest, gechecked op vulnerabilities en dependencies en op een artifact repository wordt gezet. Er is maar één plek waar de code staat (de repository) en één systeem wat zorgt voor de integratie, testen en bouw van de software zonder manuele foutgevoelige handelingen. Een groot voordeel hiervan is dat er nu automatisch is vast te stellen dat deze wijziging geen andere delen van de oplossing verstoort en voldoet aan de requirements.
Met continuous deployment wordt beoogd om zonder manuele stap rechtstreeks software die goedgekeurd is in de ontwikkelomgeving automatisch te testen en door te voeren in de productieomgeving. Als er wel een manuele stap nodig is na de ontwikkelomgeving dan is er spraken van Continuous Delivery. Door de automatisering is veel tijdwinst te bereiken maar veel eer stabiliteit en continuïteit door het uitsluiten van manuele fouten en het borgen van de kennis in scripting.
Jarenlang is de nadruk van monitoring beperkte gebleven tot de productie omgeving en vooral gericht op het beschikbaar zijn. Bij Continuous monitoring wordt dit veel breder getrokken. Zo worden alle omgeving betrokken en tevens veel meer verschillende aspecten variërend van technische beveiliging tot business monitoring van value streams. Tevens worden processen en people gemonitord om te komen tot een holistische PPT monitoring. Vooral het door de programmeurs inregelen van de monitorvoorziening in de ontwikkelomgeving is winst.
Waar in het verleden budgetten golden voor developers en operators is het binnen Continuous Learning vooral een tijdbudget. Minimaal 10% van de tijd moet besteed worden aan leren. Dit wordt dan in de vorm van validated learning gedaan hetgeen inhoudt dat het geleerde getoetst wordt in de eerst volgende retrospective meeting. Het leren is ook gericht op experimenteren. Het uitvoeren van verbeteringen zonder dat zeker is dat het gaat werken is hiervan een voorbeeld. Door fast feedback wordt de schade beperkt.
De wereld van informatievoorziening verandert zo snel dat de audit periode van een jaar achteruit kijken wellicht onvoldoende vertrouwen geeft in de veiligheid van deze informatievoorziening. Continuous Auditing geeft een antwoord op deze vraag door de frequentie van de audit te verhogen middels automatisering van de control in zowel het voortbrengingsproces (CI/CD secure pipeline) als die van de productieomgeving.
Elke aspect van CE geeft invulling aan het continue leveren van controls om te bewaken dat zo veel mogelijk waste voorkomen wordt. Dit levert een besparing in tijd en hersteltijd hetgeen een shift left organisatie oplevert omdat de fout bij de bron (links van het voortbrengingsproces) wordt voorkomen in plaats van rechts als defect of erger incident wordt ervaren. Daarmee wordt technical debt voorkomen en kan fragiliteit stap voor stap geëlimineerd worden. De CE aspecten geven tevens de mogelijkheid om de business DevOps capabilities te definiëren en te meten zodat de gebreken in PPT op de technical debtbacklog kunnen worden gezet.
Continuous Everything (CE) is empowered door Jan-Willem Hordijk, CTO van Plint AB, een Zweedse localisatie-organisatie. Deze publicatie is mogelijk gemaakt door Bart de Best (www.dbmetrics.nl), Dennis Boersen (Argis IT Consultants – www.argisit.nl), Freek de Cloet (smartdocuments), Jan-Willem Hordijk (Plint AB), Louis van Hemmen (www.bitall.nl) Niels Talens – www.nielstalens.nl en Willem Kok (Argis IT Consultants – www.argisit.nl).
Discussieer mee op LinkedIn. 
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.