Illustratie door Lex Dirkse.
Agile/Scrum en DevOps hebben zich in de praktijk bewezen, maar toch zit mij nog wat dwars. Het lijkt er soms op dat we met de komst van deze ‘drie musketiers’ zijn vergeten wat het beheren van producten écht inhoudt. Ik zie dit vooral rondom de ontwikkeling van data- en informatieproducten. Dergelijke producten leveren een bijdrage aan de bedrijfsdoelstellingen doordat zij intensief gebruik maken van bedrijfsgegevens: dashboards, rapportages, analyses, risicomodellen et cetera.
In mijn vorige blog heb ik een aantal problemen beschreven die ontstaan door de afwezigheid van beheerprocessen rondom DevOps teams. In dit blog beschrijf ik hoe het inrichten van deze processen deze problemen wegnemen, de werkdruk verlaagt en de kwaliteit van dergelijke producten en dienstverlening doet toenemen. De inrichting van de beheerprocessen kan het beste worden gedaan aan de hand van bestaande en bewezen referentiekaders en best-practices. Door alleen die processen te implementeren die ook echt nodig zijn wordt het geheel overzichtelijk en efficiënt aangepakt. Het inrichten van beheer blijft uiteindelijk de verantwoordelijkheid van het management en dus niet van de DevOps teams zelf of de vertegenwoordiger van de business: de Product Owner.
In dit blog ga ik op zoek naar antwoorden op de volgende drie vragen:
- Waarom is er zo weinig aandacht voor beheer?
- Wat levert het op om beheerprocessen in te richten?
- Hoe kun je beheer inrichten in een Agile/Scrum en DevOps organisatie?
Ik sluit het blog af met een aantal overwegingen…
Waarom is er zo weinig aandacht voor beheer?
Er zijn diverse redenen te bedenken waarom DevOps teams weinig aandacht besteden aan de inrichting van beheer van data- en informatieproducten. Ik heb er vier opgeschreven op basis van concrete voorbeelden.
Er is te weinig kennis over beheer in het team en bij het management
Een team data analisten heeft een prototype webapplicatie ontwikkeld dat pdf-documenten op basis van algoritmes intelligent aan elkaar kan relateren. De manager is onder de indruk en zegt: “Zet het maar in productie!”.
Kennis rondom beheer ontbreekt vaak binnen DevOps teams en eigenlijk kun je het ze niet eens kwalijk nemen. Het management – verantwoordelijk voor de samenstelling van het team – heeft heel vaak geen idee wat er komt kijken bij het ontwikkelen en vóóral beheren van duurzame data- en informatieproducten. Hierdoor ligt de focus te vaak op het leveren van het ‘zichtbare’: de functionaliteit.
Teams accepteren informatieproducten… te snel?
Een ingehuurde data engineer heeft vlak voor zijn vertrek een data pipeline voortgebracht naar ‘productie’. Het team kwam er pas na twee weken achter dat deze pipeline niet werkte en de documentatie volledig ontbrak.
In de ‘oude’ wereld werden informatieproducten ontwikkeld door ontwikkelteams en na het voldoen aan strikte kwaliteits- en acceptatiecriteria door een ander beheerteam in beheer genomen. Het voordeel was dat een apart team expliciet verantwoordelijk was voor operatie en beheer. Het grote nadeel hiervan was dat er vaak te weinig afstemming was en dat het product te snel over de ‘schutting’ werd gegooid.
Binnen DevOps teams is deze verantwoordelijkheid van accepteren vaak niet expliciet belegd. Hierdoor worden data- en informatieproducten onvoldoende getoetst op kwaliteit en is er niemand écht verantwoordelijk voor operatie en beheer. Het gevolg is dat een informatieproduct net iets te snel in productie wordt gezet.
Beheer is… aansluiten op standaarden
Er is een risicomodel ontwikkeld in Python op basis van ‘exotische’ packages. Er wordt besloten om het risicomodel in productie te nemen. Dit lukt echter niet omdat blijkt dat de Python packages technische componenten vereisen die niet aanwezig zijn op de systemen van de organisatie.
Om data- en informatieproducten langdurig te kunnen blijven gebruiken is het noodzakelijk dat deze gebaseerd is op technologie die ook daadwerkelijk wordt ondersteund in de organisatie. Dit is meteen één van de mogelijke redenen waarom beheer weinig aandacht krijgt binnen DevOps teams: beheer betekent standaardisatie en daarmee inperking van vrijheden. Het is onmogelijk voor een beheerteam om alle mogelijke technische smaken aan te bieden en ook te ondersteunen.
Beheer is niet ‘sexy’, het leveren van nieuwe functionaliteit is dat wel…
Ons team stond voor de uitdaging om Enterprise Analytics software te upgraden (wat zich bevond op twee mainframes, tientallen Unix systemen en duizenden werkplekken). Zorgvuldige analyse en planning gecombineerd met heldere communicatie leverde een probleemloze upgrade op zonder downtijd te introduceren voor de gebruikers en batchprocessen.
Net als in de ‘oude’ wereld is er altijd sprake van schaarste: men wil altijd meer dan dat er mogelijk is. Met Agile en Scrum leggen we verantwoordelijkheid bij de opdrachtgever via de rol van de ‘Product Owner’. Maar wie maakt zich hard voor het inrichten van beheer inclusief de juiste mensen en bijbehorende processen? Hoe zorgen we ervoor dat de data- en informatieproducten voldoen aan de door beheer gestelde eisen? Dit leidt tot minder ruimte voor nieuwe ontwikkelingen. Ondertussen heeft de Product Owner uit de business geen kennis van zaken over beheer en voelt zich ook niet verantwoordelijk voor het inrichten ervan. Er leeft een constante druk om nieuwe functionaliteit op te leveren daarentegen levert het inrichten van beheer niets zichtbaars op en wordt het niet gedaan…
De meerwaarde van beheer voor data- en informatieproducten
Het inrichten van beheerprocessen voor data- en informatieproducten biedt diverse voordelen voor het team en het product, hieronder zijn er een viertal benoemd.
Minder verstoringen, meer continuïteit, minder kosten
De continuïteit van de bedrijfsprocessen kan beter gegarandeerd worden omdat er meer controle momenten ‘in-place’ worden gebracht die voorkomen dat er verstoringen optreden. Een bijkomend voordeel hiervan is dat hierdoor de operationele kosten zullen dalen (omdat er minder verstoringen zijn).
Lagere werkdruk en betere informatieproducten
De introductie van beheerprocessen zorgt voor standaardisatie van de werkzaamheden. Dit creëert voorspelbaarheid en daarmee rust in het team en zal de samenwerking en communicatie binnen het team verbeteren. Een belangrijke bijvangst is dat de kwaliteit van de producten zal toenemen doordat het team zorgvuldiger te werk gaat in iedere fase van het ontwikkelproces.
Tevreden gebruikers, betere producten en diensten
Het beschikbaar stellen van bijvoorbeeld rapportage- en dashboard software aan gebruikers in de organisatie kan pas wanneer het goed is ingericht en wordt beheerd door functioneel beheerders. Deze beheerders helpen de gebruikers bij het werken met de software en zorgen voor kennisborging door het schrijven van gebruikersdocumentatie. Functioneel beheerders hebben vaak een uitstekend beeld van de gebruikers en kunnen hier inzicht en overzicht in genereren wat uiteindelijk leidt tot een betere ‘fit’ tussen producten, diensten en haar afnemers.
Heldere verwachtingen.. voor alle partijen
Door data- en informatieproducten aan te bieden op basis van vooraf vastgelegde afspraken (Service Level Agreements of kort SLA) ontstaat er helderheid over de te verwachten dienstverlening. Deze helderheid gaat twee kanten op: de gebruikers weten waar ze aan toe zijn maar het DevOps team ook. De samenstelling van het team kan worden geoptimaliseerd op de te leveren dienstverlening.
Hoe beheerprocessen in te richten in een DevOps organisatie?
Onderstaand stappenplan helpt organisaties om beheerprocessen in te richten naast de bestaande DevOps teams.
1. Inventariseer de uitdagingen van het team
In deze stap wordt in kaart gebracht waar de huidige problemen zitten en de ‘gaten’ in het functioneren van het team. Waar besteedt het team de meeste tijd aan en is dit wenselijk? Wat wordt als frustrerend ervaren in het team? Waar is geen tijd voor, maar zou wel ingericht moeten zijn? Wat kan beter volgens de gebruikers? Zijn er terugkerende momenten waarop het ‘mis’ gaat? Op basis van dit inzicht kan er een vertaling gemaakt worden naar de te implementeren beheerprocessen.
2. Stel vast welke processen er moeten komen
In deze stap wordt gekeken welke processen de huidige problemen kunnen wegnemen. Hoe zwaar moeten deze processen worden ingericht? Op welk moment in de tijd is het nodig om deze processen te implementeren? Waar deze processen het beste in te richten en met welke middelen? Is het mogelijk om bestaande middelen (bijv. helpdesk/ticket systeem) te hergebruiken? Deze stap levert uiteindelijk een overzicht op van de te implementeren processen en vormt de basis voor een implementatie planning.
3. Richt de processen en bijbehorende organisatie in
In de derde stap worden de processen en organisatie ingericht. De wijze waarop dit gedaan wordt is uiteraard afhankelijk van de organisatie.
4. Controleer of de processen het gewenste effect hebben
Controleer in de vierde en laatste stap of de beheerprocessen effect hebben op de werkdruk en de kwaliteit van de DevOps teams. Inventariseer bij de gebruikersorganisatie of zij effect zien van de genomen maatregelen en blijf hen bevragen t.a.v. tevredenheid, worden ze gehoord? Is het product stabiel? Herhaal desnoods stappen één tot en met vier.
Overwegingen bij het inrichten…
Wanneer organisaties écht voordeel willen hebben van de moderne manier van werken op basis van Agile/DevOps en Scrum, dan vereist dit dat er wordt nagedacht over beheer, de ondersteunende functie en het inrichten daarvan.
Het kan best wel zo zijn dat de huidige manier van werken sneller functionaliteit oplevert maar de vraag of deze functionaliteit over 3 jaar nog steeds goed functioneert vind ik een veel belangrijkere. Als we data- en informatieproducten niet duurzaam ontwikkelen en beheren is het maar de vraag of het op lange termijn nog zoveel zal opleveren…
Het management van een organisatie is ten allen tijden verantwoordelijk voor het inrichten van gedegen beheer rondom de DevOps teams van data- en informatieproducten. Deze verantwoordelijkheid kan niet bij de Product Owner en de DevOps teams zelf liggen. Het management moet de randvoorwaarden voor continuïteit invullen. Zij moeten staan voor de noodzaak dat dit geld en inspanning kost, de organisatie en processen vormgeven en dat geheel verdedigen naar de opdrachtgevers toe. Hierin moet het management van een organisatie toch echt het voortouw nemen…
Roy Maassen, april 2021