Hoe maak je DevOps tot een succes?

Deze manier van werken krijgt navolging in allerhande andere bedrijven, waaronder veel enterprises. Dat is lang niet altijd een succes en ook lang niet altijd nodig, want waarom zou een applicatie in de backoffice flexibel moeten zijn als het proces dat deze applicatie ondersteunt niet of nauwelijks verandert? Natuurlijk, de DevOps-kant van het verhaal – ‘you build it, you run it’ – bewijst ook in die omgevingen zijn meerwaarde. Maar autonoom en agile hoeven die teams vaak niet te zijn. Bedenk daarom vooraf per team goed hoe je DevOps inricht. Het volgende stappenplan kan je daarbij helpen.

Zoals gezegd is lang niet overal dezelfde mate van agility nodig. Het hangt af van het type bedrijf en het type applicatie. Heb jij een seizoensbedrijf, dan heb je meer flexibiliteit nodig in je IT-omgeving dan wanneer je omzet gedurende het hele jaar min of meer gelijk is. Gaat het om een klantgerichte applicatie, dan is de kans groot dat je daar vrij vaak aanpassingen aan wilt doen, bijvoorbeeld in relatie tot een marketingcampagne. Gaat het daarentegen om een applicatie die je kernprocessen aan de achterkant ondersteunt, bijvoorbeeld het transactieproces, dan zul je hooguit wat moeten schalen in capaciteit als je naar aanleiding van een succesvolle marketingactie meer verkoopt. Maar de manier van bestellen, betalen en afleveren wijzigt niet wezenlijk.

Als je op hoofdlijnen weet waar je wel flexibiliteit nodig hebt en waar niet, is het tijd om dit te vertalen naar de DevOps-teams. Bepaal per team de gewenste flexibiliteit en daarmee autonomie op drie assen: mensen, processen en technologie. De klantgerichte teams aan de voorkant zul je waarschijnlijk op alle drie de assen een hoge mate van autonomie willen geven, de back-end teams aan de achterkant mogelijk een lagere. Waar in het verleden wel werd gesproken over ‘IT op twee snelheden’, gebruiken wij liever een glijdende schaal. Want er zitten vele tinten grijs tussen het zwart en het wit. Het is meer een equalizer met drie schuiven die je naar believen in de juiste stand kunt zetten.

Naarmate DevOps-teams een hogere mate van autonomie krijgen, ontstaat er makkelijk een wildgroei aan werkmethodes, technieken, tools en programmeertalen. Dat brengt niet alleen hoge kosten met zich mee, je loopt ook het risico dat er veel kennis uit je organisatie verdwijnt zodra een lid van een DevOps-team een andere baan vindt. Het wordt bovendien een stuk lastiger om eerder ontwikkelde services te hergebruiken in andere omgevingen. Je ontkomt daarom niet aan afspraken: op welke platformen gaan we ontwikkelen? Hoe gaan we met containers om? Welke werkprocessen spreken we af voor de pipelines? Welke tools gebruiken we daarbij (en welke dus niet)? Hoe gaan we om met security? Op welke manier testen we nieuwe code? Hoe regelen we monitoring in? Welk kennisniveau is vereist in de teams en welke opleidingen moeten medewerkers daarvoor volgen? Hoe lager de mate van autonomie die je de teams geeft, hoe dwingender deze afspraken zullen zijn.

De basisregel bij outsouring is, zoals altijd: hou datgene wat jou onderscheidend maakt dicht tegen je aan en doe dat zelf, desgewenst met tijdelijke externe ondersteuning. En outsource die dingen die generiek zijn. Je zult merken dat de knip vaak ligt tussen applicaties en de omgeving waar die applicaties op draait. Het ontwikkelen, beheren en onderhouden van maatwerkapplicaties is core business. Maar het bouwen, beheren en onderhouden van het containerplatform waar die applicaties op draaien, is een generieke dienst waarin jij je als bedrijf niet in kunt onderscheiden. Dat besteed je dus liever uit.

Zoals gezegd krijg je een lappendeken van teams die meer of minder autonomie hebben op het gebied van werkprocessen en te gebruiken tooling. Het kennisniveau, en daarmee de opleidingsbehoefte, in de teams moet hierop worden afgestemd. Realiseer je daarnaast dat vrijheid altijd hand in hand moet gaan met het nemen van verantwoordelijkheid. Hoe hoger de autonomie in de teams, hoe meer verantwoordelijkheid die teams moeten dragen. Verantwoordelijkheid op allerlei vlakken: het halen van deadline, te maken kosten oplossen van storingen op ongelegen momenten. Zo zal een autonoom werkend team zelf moeten regelen dat er 24x7 mensen standby staan voor het geval er iets met die applicatie aan de hand is. Immers, als een tv-commercial in prime time leidt tot veel extra bestellingen in de avond, mag het niet gebeuren dat die bestelapplicatie onderuit gaat en er pas de volgende ochtend iemand naar gaat kijken.

Kortom, bezint eer ge begint. DevOps is een prachtig concept dat ook in de backend zijn meerwaarde bewijst. Kijk goed welke mate van flexibiliteit en daarmee van autonomie nodig is. En zadel teams niet op met verantwoordelijkheden die ze eigenlijk niet aan kunnen.