iBurgerzaken is belangrijk voor een primair proces van de gemeente. Nieuwe functionaliteiten die het proces optimaliseren snel kunnen uitleveren is dan ook wenselijk. Bovendien versterkt dat de vraag om continue beschikbaarheid. Met beide wensen in het achterhoofd hebben we ons releaseproces opnieuw bekeken en waar mogelijk aangescherpt. Dat betekent dat we de OTAP-straat en de gefaseerde uitlevering behouden om de continue beschikbaarheid te borgen. En dat we kiezen voor kortere releases om de nieuwe functionaliteiten eerder in het land te hebben.
Bij de planning van de iBurgerzaken releases zijn er verschillende zaken om rekening mee te houden. Wat te denken van de releasemomenten? Je wilt immers dat alle betrokkenen op dat moment de gewenste activiteiten kunnen uitvoeren. Of wat te denken van de inhoud van een release en het moment dat het gereed is voor productie? Je begrijpt het al, het is steeds weer een hele puzzel…
De conclusie van de recente analyse van het releaseproces? Het moment waarop we kortere releaseperiodes kunnen gaan hanteren is aangebroken! In de afgelopen periode ontwikkelden we grote stukken functionaliteit. Dusdanig complex en onderdeel van ‘de basis van iBurgerzaken’ dat het moeilijker was dat in kleinere stukken te hakken. Recente releases van iBurgerzaken hadden daardoor een lange ontwikkeltijd; release 3.00 bijvoorbeeld 12 weken en 3.01 zelfs 14 weken. Daardoor liet de uitlevering van kleine stukjes functionaliteit ook op zich wachten; bugfixes, marktsignalen en configuraties. Nu we de komende ontwikkelingen wel kunnen opknippen in kleinere stukken realiseren we een minimale time to market. Bovendien is jullie feedback dan ook sneller bekend zodat eventuele verbeteringen weer sneller opgepakt kunnen worden. Tegelijkertijd voeren we ook een extra kwaliteitsverbetering door: softwarewijzigingen zijn sneller, veiliger en laagdrempeliger te realiseren doordat we meer focus kunnen aanbrengen.
Dat is een mooi bruggetje naar de implementatie van iBurgerzaken. Laten we dat proces met veel aandacht voor kwaliteit ook eens nader bekijken: elke nieuwe softwarereleases en infrastructurele wijziging doorloopt een gedegen OTAP-straat die we hieronder beschrijven. Hiermee streven we ernaar dat wijzigingen geen nadelige effecten hebben op de productieomgeving. Dat past bij de vraag om continue beschikbaarheid van iBurgerzaken.
· [O] In onze ontwikkelomgeving werken we aan een nieuwe iBurgerzaken release. Daarbij bootsen we na hoe deze in productie zal fungeren.
· [T] Vervolgens wordt dit uitvoerig – intern – getest. In onze Kwaliteitsweek zijn daarbij al onze ontwikkelaars betrokken. Bovendien analyseren we op dit moment de performance, bijvoorbeeld door (geautomatiseerde) regressietesten en loadtesten.
· [A-1] Na deze controleslag installeren we de release in onze acceptatieomgeving. Daar testen we wederom de functionaliteit van de nieuwe release.
· [A-2] Als deze stap succesvol wordt doorlopen installeren we de release op de klanttestomgeving; CTE. Vanaf dat moment kunnen alle klanten met een testomgeving de nieuwe software in hun eigen testomgeving benaderen. Dit gebeurt vrijwel direct na stap A1.
· [A-3] Na acceptatie van een groep specifieke testklanten zetten we de release door naar de ‘Early Adopter omgeving’; een groep van 8-10 geselecteerde gemeenten die de software in de praktijk gaan gebruiken. Dit is bij voorkeur 1 à 2 weken na stap A2.*
· [P] Wanneer hier geen problemen naar voren komen zetten we de release tenslotte door naar de productieomgeving; alle klanten gebruiken vanaf dat moment de nieuwe software in de productieomgeving. Dit is bij voorkeur 1 à 2 weken na stap A3.*
Doordat iBurgerzaken een cloudapplicatie is vragen de installaties overigens een minimale inspanning van de gemeenten. Met één druk op de knop wordt zogezegd de software in een omgeving bijgewerkt. Daarbij is er een minimale productieverstoring die we bovendien bewust in de avonden of weekenden plannen om de dienstverlening aan de balie in ieder geval niet te verstoren.
*) Voor de volledigheid: We leveren in principe uit conform releaseplanning waarover we tijdig communiceren. In het geval van enige twijfel nemen we echter geen risico’s. Dan stellen we de installatie van een release uit naar de acceptatieomgeving, CTE, Early Adopter of productieomgeving. En zetten we zogezegd eerst een aantal stappen terug in de OTAP-straat.
Deze kortere releases met behoud van de implementatiefases zijn kortom onderdeel van hét antwoord om op elk gewenst moment te kunnen beschikken over de nieuwste functionaliteiten. Daarmee beschikken gemeenten continu over toekomstbestendige burgerzakensoftware.
De voordelen op een rij:
· Snellere reactietijd
Het snel kunnen aanpassen door frequente softwarereleases
· Verminderd risico
Door frequent software-updates uit te voeren is het risico op fouten kleiner
· Lagere kosten
Door het releaseproces te automatiseren blijven de kosten onafhankelijk van het aantal releases gelijk
· Flexibiliteit
Het biedt vrijheid in de manier waarop en wanneer, bijvoorbeeld ’s nachts, releases worden vrijgegeven
‘Klanten wil ik steeds opnieuw op een creatieve wijze verrassen.’
Sanne van der Zanden, Programmamanager
