De veranderingen in de maatschappij en de technologie, lees de ontwikkelingen naar een i-samenleving, stellen ook eisen aan de overheid, die steeds sneller en flexibeler moet reageren. In de ‘Visiebrief digitale overheid 2017’ van minister Plasterk van Binnenlandse Zaken en Koninkrijksrelaties wordt duidelijk gemaakt hoe de dienstverlening van de overheid aan de burger aangepakt wordt. Inzet is een transparante overheid die de digitale mogelijkheden inzet voor betere dienstverlening en gegevensuitwisseling, en een overheid die de burgers centraal stelt in de informatiestromen. Anders gezegd: de digitale transformatie.
Waar een aantal jaren geleden it vooral werd toegepast op de ondersteunende processen zonder dat dit de burger raakte, zien we nu dat it juist wordt ingezet bij de ondersteuning van de primaire processen waarbij de burger de eindgebruiker is van deze it-dienstverlening. Aanvragen voor overheidsdocumenten als vergunningen, diensten en besluiten worden steeds vaker volledig digitaal ingediend en afgehandeld. Dit in lijn met de ‘Digitale overheid 2017’. Het vraagt van de overheid om zich nog meer toe te spitsen op de vraag en niet het aanbod, ketenomkering derhalve. De huidige technologie kan daarbij de gevraagde digitale en hoogwaardige kwalitatieve dienstverlening ondersteunen. Kortom, de overheid zit al in de digitale transformatie waardoor zij flexibel wordt en sneller kan inspelen op al deze ontwikkelingen.
Samenwerking bedrijfsvoering en IT
In de volgende stappen naar de digitale transformatie is het van belang om de bedrijfsvoering (vraag-, gebruikerszijde) en it (aanbodzijde) nog beter op elkaar te laten aansluiten en te laten samenwerken. Bij de ontwikkeling van nieuwe functionaliteit, bijvoorbeeld een digitaal aanvraagsysteem, spreken we in dat kader over ‘agile/scrum’ (wendbaar of flexibel) werken. Hierbij worden in multidisciplinaire teams met vertegenwoordigers van de vraag- en aanbodkant op een interactieve manier (in ‘sprints’ van een paar weken) werkpakketten ontwikkeld, geleverd en beheerd.
Door een continue bijstelling en prioritering van de tussentijdse resultaten in een iteratief proces, wordt ervoor gezorgd dat het op te leveren aanvraagsysteem optimaal aansluit bij de wensen van de gebruikers. Daarmee wordt ook het draagvlak vergroot.
DevOps, afkorting van ‘Development and Operations’, borgt hierbij ook het beheer. Dit omdat DevOps de rol van beheer – bij de overheid veelal afgescheiden en soms zelfs extern uitbesteed – al betrekt in de scrum sprints. Juist deze tijdige inbreng maakt het verschil omdat de werkpakketten daarmee niet alleen aan de hoge kwaliteitseisen van de gebruikers voldoen, maar ook aan de gestelde beheernormen.
DevOps versus traditioneel
Het verschil tussen een traditionele en een op basis van DevOps ingerichte diensten-organisatie is dat bij DevOps alle benodigde disciplines – de gebruikers, de ontwikkelaars en de beheerders – zijn opgenomen in het team. Een ander onderscheid is dat een DevOps-team verantwoordelijk is voor het gehele product of de dienst die zij leveren en dus niet slechts voor een technisch onderdeel dat tot een product of dienst leidt.
Je zou DevOps daarmee kunnen beschouwen als de verdere professionalisering en industrialisering van de it-functie, waardoor er met een hogere productiviteit, een betere stabiliteit nieuwe digitale producten en diensten sneller worden geleverd met als eindresultaat meer klanttevredenheid.
Bij de inzet van DevOps wordt continu, en ook dat is een verschil met de traditionele omgeving, het procesresultaat gemeten met als uitgangspunten:
- of nieuwe functionaliteit daadwerkelijk wordt gebruikt;
- of de gebruiker tevreden is over de geleverde dienst;
- er wordt gewerkt met minimale producten om te toetsen of gebruikers echt geïnteresseerd zijn in nieuwe producten en diensten;
- maar ook wordt continu de productiviteit en kwaliteit door de gehele keten gemeten en waar nodig verder verbetert.
Business value
De beoogde doelstellingen met DevOps dragen bij aan de ‘business value’: klanttevredenheid, reactiesnelheid door flexibiliteit, gebruikersvriendelijkheid, kostenreductie, compleetheid van de nieuwe omgeving en ruimte voor innovatie. En inmiddels zijn er ook binnen de overheid tevreden gebruikers zoals het CIZ (Portero project), gemeente Groningen (digitalisering dienstverlening) en het ministerie van Infrastructuur en Milieu (project Standaard Platform en Centraal Aansluitpunt) die DevOps momenteel in praktijk toepast.
Het is dan ook niet de vraag ‘of’ DevOps moet worden toegepast; het is meer de vraag ‘wanneer’ en ‘waar’ je gaat beginnen met het toepassen van DevOps binnen de organisatie.
Sven Vintges, solution architect en DevOps thought leader bij Atos
Dit artikel is ook te lezen in GOV magazine nummer 8.
In een grijs verleden heb ik ook nog eens ooit wat gedaan voor overheden en banken. Eén van de harde eisen destijds was dat ontwikkeling, vrijgave en beheer strict gescheiden was.
Achtergrond hiervan was een stukje veiligheid: als een ontwikkelaar een achterdeur inbouwt, en zelf (mede) verantwoordelijk is voor vrijgave en beheer dan wordt (mogelijke) fraude of chantage in de hand gewerkt.
Nu praat ik hier over een jaar of 15 geleden, maar ik ben benieuwd of dit soort aspecten nog steeds actueel zijn en hoe zich dat verhoudt tot DevOps.
PaVaKe : DevOps kent ook gewoon cycles en stadia. Het is alleen dat als de juiste stakeholder(s) Accepten dat de deployment naar productie geautomatiseerd gebeurd.
Als developer 1 code incheckt voor test, dan is er een developer 2 of iemand anders die een review doet op de code : Dus is de code volgens conventie en regels? Is de code op het eerste gezicht correct?
In de basis zijn de processen die je benoemd goed te borgen, in feite volg je gewoon een OTAP straat, alleen doordat er goed geautomatiseerd wordt is ligt de focus op functionaliteit en niet om onnodige uren verspilling.
DevOps is prachtig maar zeker niet nieuw en uiteindelijk blijft nog altijd het probleem van support als je lifecycle van service niet onlosmakkelijk bindt aan ecosysteem van techniek. Belofte aangaande het beheer ken ik nog uit de tijd dat banken middels idee van Continuous Delivery een stroom financiële producten de markten indrukten die nu voor knellende problemen zorgen.
Iets met dragende infrastructuur en kosten van verandering als ik kijk naar DevOps en patch management, nog niet echt een gelukkige combinatie.
Ambitieuze onzinprojecten blijven wel hoor, met of zonder DevOps.
De truuk is om het te verkopen. Begin met een nieuwe techniek die alle voorgaande problemen zou oplossen. DevOps bijvoorbeeld. Beetje bestuurder snapt dat niet, daarom vlug eindigen met ‘business value’: klanttevredenheid, reactiesnelheid door flexibiliteit, gebruikersvriendelijkheid, kostenreductie, compleetheid van de nieuwe omgeving en ruimte voor innovatie..
Niet de vraag of maar hoeveel fyra’s er binnenkort over nieuwe disruptive Betuwelijnen door ons ict-landschap sprinten.
Ewout: Je maakt een terecht punt. Een van de kernboodschappen wanneer je flexibeler, sneller etc wilt is dat je niet moet kijken naar 1 aspect. Het heeft impact op het IT landschap, processen, incentives, cultuur en natuurlijk techniek.
Een constatering die ik doe is dat we steeds meer vanuit commodity werken. De commodity beweegt zich naar boven en daarmee worden telkens meer cross-cutting concerns opgelost in het platform. Het resultaat is dat de ontwikkelaar zich meer richt op de functionaliteit: datgene wat waarde oplevert voor de eindgebruiker.
De trend waarbij vroeger de stelling was: software ondersteunt de bedrijfsvoering zien we nu steeds meer dat software de bedrijfsvoering wordt. Kortom digitalisering van de processen die tot diensten of producten leiden. Dit vraagt (of beter eist) een andere invulling van je IT functie.
@Felix The Cat:
Dat klopt DevOps is geen oplossing voor de invulling van opdrachtgeverschap. Wat DevOps je zeker levert is een nieuw niveau van productiviteit. Maar garbage in – garbage out. Dat zal nooit veranderen (het gaat hooguit met een hogere productiviteit ;))
Maar terug naar de stelling. Uiteindelijk draait het voeren van een bedrijf grotendeels om klanttevredenheid (daar doe je het immers voor, toch?). Klant tevredenheid wordt beïnvloed door meerdere elementen. De ene klant wil een goedkoop product (en dan maakt het niet uit dat deze minder innovatief is of dat er wat minder features zijn), een andere klant wil juist graag snel nieuwe features hebben en weer een andere klant wil innovatieve producten. DevOps geeft ons m.i. instrumenten die er eerder niet waren om ervoor te zorgen dat hierin de juiste balans bereiken om onze gebruikerstevredenheid te verhogen met als resultaat: meer klanten, klanten die blijven, kortom meer omzet. Denk hierbij aan mogelijkheden om het gedrag van gebruikers te meten (A/B Testing) icm snelle uitrol. Je kunt een nieuwe feature uitrollen, kijken of deze wordt opgepakt en daarna besluiten deze uit te bouwen of te laten vallen. Je bent in staat om vele malen sneller je hypothese te testen ipv een keer per half jaar een grote feature uitleveren en op hoop van zegen kijken of je gebruikers er blij van worden. Laat staan je reactie snelheid op de steeds sneller veranderende markten.
Kortom: DevOps is geen heilige graal, maar het helpt zeker en is voornamelijk een nieuw productiviteitsniveau en professionaliseren (industrialiseren zo je wilt) van ons vak.