Illustratie door Lex Dirkse.
“Wij doen niet aan beheer: wij doen DevOps!” zegt Erik vol trots tegen zijn collega van IT, terwijl hij zijn mok onder de koffieautomaat plaatst. “Alles wat wij ontwikkelen, beheren we ook zelf! Infrastructuur, DDL, Data Pipelines: alles wordt middels CI/CD volledig geautomatiseerd voortgebracht naar productie!”.
Traditionele IT-organisaties
Traditionele IT-organisaties worden gekenmerkt door afzonderlijke afdelingen met sterke functiescheiding. Iedere afdeling heeft zijn eigen management en werkwijze. De afdeling ontwikkeling realiseert – onder regie van de afdeling architectuur – nieuwe producten die in beheer worden gebracht bij de afdeling beheer. Deze organisatievorm heeft voordelen: de verantwoordelijkheden zijn duidelijk en er zijn heldere processen. De producten worden overgedragen aan de afdeling beheer zodra er is voldaan aan de acceptatiecriteria. De nadelen zijn er ook: het opstarten van nieuw projecten of doorvoeren van aanpassingen zijn veelal langdurige trajecten. Processen zijn heilig – er wordt niets gedaan zonder incidentnummer. De eindgebruiker is over het algemeen ver te zoeken tijdens de realisatie van nieuwe IT-producten.
DevOps, Agile en Scrum
En toen ineens waren er: DevOps, Agile en Scrum. De drie-musketiers van softwareontwikkeling. DevOps teams die werken op basis van Agile/Scrum zijn professioneel, open en werken goed samen. DevOps teams zijn in staat om snel functionaliteit te leveren omdat de verantwoordelijkheid voor het ontwikkelen en beheren binnen hetzelfde team is belegd.
Ik zie bij organisaties die werken op basis van DevOps, Agile en Scrum een verontrustende ontwikkeling ontstaan: de waardevolle ervaringen en adviezen die staan beschreven in de referentiekaders en best-practices zoals ITIL, ITSM en BiSL lijken steeds meer te worden vergeten, waardoor beheer het kind van de rekening dreigt te worden. Onderstaande praktijkvoorbeelden laten zien dat DevOps, Agile en Scrum in zichzelf de uitdagingen rondom beheer niet wegnemen.
En toen ineens waren er: DevOps, Agile en Scrum. De drie-musketiers van softwareontwikkeling.
De last van het beheren drukt zwaar op het team.
Er wordt een DevOps team geformeerd en binnen enkele weken wordt de eerste functionaliteit geleverd. De klant wordt op zijn wenken bediend en is uiterst tevreden. Jaren later blijkt toch dat de klant het zelf ook niet heel goed wist. Het team heeft een versnipperd functioneel en alweer verouderd technisch landschap in beheer. In deze werkelijkheid wordt er nog maar weinig nieuwe functionaliteit geleverd omdat de beheerlast van de bestaande functionaliteit zwaar drukt op het team.
Variërende kwaliteit van functionaliteit
De ontwikkelaars binnen het DevOps team maken gebruik van automation om functionaliteit gecontroleerd voor te brengen naar productie. Functionaliteit wordt frequent voortgebracht maar het is voor het team onduidelijk wanneer functionaliteit naar productie mag. Er is geen aandacht voor methodisch testen.
Toenemende werkdruk en overall complexiteit.
Het DevOps team bestaat 4 jaar. De afgelopen jaren is het ziekteverzuim toegenomen. De druk om te leveren en de bijkomende beheerlast zorgt ervoor dat teamleden steeds vaker ziek thuis zitten. De totale complexiteit van alle functionaliteit is toegenomen en daarmee ook de onderlinge technische afhankelijkheden.
Het kind van de rekening: ondersteuning gebruikers en functioneel beheer.
De nieuwe functionaliteit is een succes. Het aantal gebruikers neemt toe en daarmee ook de vragen die worden gesteld aan het DevOps team. Wie helpt bij het in gebruik nemen van de functionaliteit? Het DevOps team voelt zich hier niet verantwoordelijk voor…
Het piepsysteem van het DevOps team.
Het Ops deel van het DevOps team is druk en heeft een overvolle backlog. Ops werkt dagelijks aan het oplossen van technische incidenten: een pipeline is stukgelopen, een applicatie werkt niet meer enz. Op basis van het piepsysteem wordt er wat aan beheer gedaan. Niemand houdt zich bezig met de grotere vraagstukken rondom beheer.
Wat levert het DevOps team eigenlijk?
Het team heeft verschillende producten ontwikkeld. Welke producten zijn dit eigenlijk? Is er een overzicht van alles wat er nu in productie staat? Is er een overzicht van de afhankelijkheden met andere systemen? Onder welke condities en afspraken worden deze producten eigenlijk geleverd? Hoe passen deze producten eigenlijk in het grote geheel? Wat gebeurt er als ik deze producten ‘uit’ zet? Het team heeft eigenlijk geen idee hoe het bijdraagt aan de strategische doelen van de organisatie…
De crux is dat het één het ander niet hoeft uit te sluiten: de best practices rondom beheer gaan prima samen met de drie musketiers DevOps, Agile en Scrum. De nadruk ligt vaak op Dev en maar zelden op Ops. En misschien is het ook wel een beetje zo dat alles wat naar klassiek beheer ruikt per definitie wordt af geserveerd als old-school.
Ook bij DevOps, Scrum en Agile blijft het inrichten van gedegen beheer noodzakelijk!
Bovenstaande uitdagingen hadden voorkomen kunnen worden door aandacht te schenken aan beheerprocessen en bijbehorende inrichting. Ook bij DevOps, Scrum en Agile blijft het inrichten van gedegen beheer noodzakelijk! Goede regie op de afhandeling van klantwensen, incidenten, problemen en ondersteuning en het bewaken van de koers met een duidelijke strategie kunnen veel problemen voorkomen. In mijn volgende blog zal ik hier verder op in gaan.
Roy Maassen, juni 2020.