Het Kadaster brengt business en IT vaker samen in BizDevOps

12 juni 2024 Consultancy.nl 7 min. leestijd
Profiel
Meer nieuws over

Bij het Kadaster maken ze steeds meer de transitie van productgericht naar klantgericht innoveren. Een nauwere afstemming tussen de ontwikkelteams en de ‘business’ is hierin cruciaal. Robert van Hamersveld, Product Owner bij het Kadaster, en Jan van den Brink, agile/DevOps Coach bij Cegeka, nemen ons mee in hoe deze ontwikkeling concreet wordt vormgegeven.

De IT-afdeling van het Kadaster heeft de afgelopen jaren flinke stappen gezet in het versnellen en verbeteren van productinnovaties, upgrades en het versterken van IT-gedreven processen.

Robert van Hamersveld kan er als geen ander over meepraten: hij werkt al meer dan 25 jaar bij het Kadaster, vanaf het begin binnen het functioneel beheer. “Ja”, knikt hij, “ik heb de omslag van watervalmethodiek naar agile werken de laatste tien jaar van dichtbij meegemaakt.”

Het Kadaster brengt business en IT vaker samen in BizDevOps

Die omslag begon in 2013. “Traditioneel kent het Kadaster een aparte afdeling waar de IT-werkzaamheden zijn ondergebracht en een aparte afdeling waar de business zit. De business is daarbij de opdrachtgever voor IT. Maar sinds de teams agile zijn gaan werken, is de business als opdrachtgever meer onderdeel van het IT-team geworden.”

DevOps

Cruciaal daarin is het omarmen van DevOps, een manier van denken en werken waarbij alle betrokken partijen worden meegenomen in de ontwikkelketen. “We zijn begonnen met de ontwikkel- en beheerteams, maar in de loop van de jaren steeds verder uitbreidend naar bijvoorbeeld security (DevSecOps) en business (BizDevOps)”, vertelt Jan.

Zelf richt Robert zich de afgelopen jaren vooral op BizDevOps. “Dat is waar de grootste waarde ligt, dicht bij het DevOps team”, verklaart hij. “Door gedurende de hele levenscyclus van softwareontwikkeling businessteams doorlopend mee te nemen in de agile software-ontwikkelmethode, zit de business veel dichter op de bal.”

“Dit betaalt zich uit bij het in beheer nemen van de sprintresultaten. Daarnaast ga je steeds meer elkaars taal spreken en merk je dat je als product owner deze kennis meeneemt in de afweging bij het stellen van de prioriteiten. Dit werkt efficiënt en is een belangrijk voordeel van het vormen van een BizDevOps-team.”

Al met al telt het op tot “producten die beter én sneller worden ontwikkeld, en ook nog eens meer in lijn met de vraag van gebruikers”, legt hij uit. “Dit zorgt uiteindelijk voor maximale klantwaarde.”

Geen ‘one size fits all’

Kortom: belangrijke voordelen. Maar uiteraard is ook DevOps geen wondermiddel – net als elke andere manier van werken brengt het weer zijn eigen uitdagingen met zich mee.

“Een belangrijk aandachtspunt is bijvoorbeeld de afbakening van het functionele en het technische aspect”, schetst Robert: “Waar praat en beslis je vanuit de business wel of niet over mee?”

“Vroeger was dit helder”, legt hij uit: “De business gaat over het ‘wat’ en IT over het ‘hoe’. Maar dit is door de invoering van agile meer in elkaar vervlochten: als business sta je nu achter het loket waar je voorheen je opdrachten neerlegde.”

Het Kadaster weet echter steeds beter met dergelijke uitdagingen om te gaan. Een belangrijk deel van de oplossing zit volgens Robert in het erkennen dat er geen ‘one size fits all’- aanpak bestaat voor het inrichten van DevOps-teams.

“De basisprincipes zijn weliswaar gelijk, maar de precieze manier waarop je daar invulling aan geeft verschilt per geval. Daarbij verschilt met name de mate van integratie tussen DevOps en de business.”

Het Kadaster brengt business en IT vaker samen in BizDevOps

Het Kadaster brengt steeds vaker de business en IT samen in BizDevOps

Use cases

Het belang van een maatwerkaanpak illustreren Robert en Jan aan de hand van drie use cases met ieder een verschillende mate van integratie. De eerste betreft een stabiele, volwassen landelijke dienst met een duidelijk wettelijk kader en een eenduidig gebruik.

Jan: “De business zorgt ervoor dat een brede doelgroep – van particulieren en bedrijven tot overheden – flexibel gebruik kunnen maken van up-to-date geografische informatie. Daarnaast hebben ze een stroom aan doorontwikkelingsverzoeken – een mix van kleinschalige verbetering, vernieuwingen van bestaande processen, het reageren op overheidswijzigingen en interne projecten.”

In deze BizDevOps-constructie is het integratieniveau relatief laag. “Slechts één contactpersoon van de landelijk dienst is dedicated voor het DevOps-team. Deze is ook niet standaard bij het DevOps-team aanwezig. Wel is er veel ad hoc-afstemming tussen DevOps-rollen. Er is geen hoge drempel om elkaar te benaderen.”

Een tweede voorbeeld is de toepassing van DevOps binnen een apart bedrijfsonderdeel van het Kadaster dat geografische informatie registreert en doorlevert aan externe private en publieke organisaties voor een brede toepassing. De producten en data worden ook gebruikt door interne en externe service providers die de klanten ondersteunen met hun vraagstukken.

Door de vele afhankelijkheden tussen de teams is hier gekozen voor een inrichting met een wat hoger integratieniveau. Dat betekent concreet dat de business en IT vaak bij elkaar zitten en korte lijntjes hebben.

“Door fysiek dichter bij elkaar te zitten, krijgen teamleden vanuit zowel business als IT meer inzicht en begrip waarom zaken zijn zoals ze zijn”, zegt Robert. “Hierdoor kan een duidelijke vertaling worden gemaakt naar de wensen van de gebruiker.”

De derde use case betreft een landelijke dienst die zich vooral richt op de registratie van administratieve gegevens. “De dienst kent veel relaties met andere registraties en is relatief complex, zowel technisch en functioneel als qua besturingscontext. Er wordt gewerkt voor een groot aantal afnemers in publieke en private organisaties, en er liggen duidelijke piekmomenten aan het begin van het jaar.”

Vanwege de complexiteit is hier gekozen voor de hoogste mate van integratie. “Hier vormen de business en DevOps-medewerkers bijna één team. In de praktijk vult men elkaars rollen regelmatig aan en zijn de korte lijnen nodig om de dienstverlening succesvol te laten zijn.”

Leerpunten

Jan begeleidde de drie teams uit de cases als agile/DevOps Coach en hielp zo de organisatie bij het doorlopend zetten van stappen in het omarmen van BizDevOps. Hij adviseerde, introduceerde best practices en coachte de teams.

Op basis van zijn ervaringen deelt hij enkele belangrijke lessen voor organisaties die BizDevOps-teams willen opzetten.

“Om te beginnen is het belangrijk om te erkennen dat elke organisatie uniek is”, geeft hij aan. “Kijk daarom welke ontwikkelingen binnen jouw organisatie gaande zijn en speel daar actief op in, omdat die ontwikkelingen vaak leiden tot nieuwe coördinatiemechanismen tussen afdelingen.”

In lijn hiermee pleit hij voor een geleidelijke transitie, waarin gaandeweg invulling wordt gegeven aan de term BizDevOps. “Dit is ook belangrijk omdat het introduceren van deze term bepaalde verwachtingen wekt”, legt hij uit.

Hij adviseert om vooral de gemeenschappelijke doelen en verantwoordelijkheden te benadrukken. “Dan ontwikkelt zich de mate van integratie op een natuurlijke manier. Bespreek hierbij de diverse rollen en verantwoordelijkheden goed met elkaar. Dit bevordert eenduidigheid en generiek werken.”

En zoals de drie use cases illustreren, is de context van grote invloed op de best werkende inrichting. Robert vult aan: “Zaken zoals volwassenheid, complexiteit en omvang bepalen mede de mate van integratie. Essentieel is om te beseffen dat er geen ‘beste’ manier van BizDevOps is die op elke dienst van toepassing is.”

Daarbij waarschuwen de twee tot slot voor onrealistische verwachtingen. “Het samenbrengen van business en IT blijft altijd een kwestie van balanceren. Een totale integratie hebben we ook nog niet meegemaakt.”