Zo schrijf je met devops een succesverhaal

Meer en meer organisaties overwegen een 'devops way of working'. Ze brengen softwareontwikkeling, testen en beheer onder in één team, zodat bij het ontwikkelen van software al is na te denken over de kwaliteit en het beheer van die code op de langere termijn.

De manier van werken komt overgewaaid van startups die klantgerichte webapplicaties maken, bedrijven zoals Spotify en Coolblue. Zij streven maximale agility na en geven hun devops-teams daarom een hoge mate van autonomie. De teams kunnen zelf bepalen hoe ze hun doelen gaan bereiken, welke technologie ze daarbij gaan gebruiken en welke processen ze volgen.

Stappenplan

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.

• Denk na over waar je agility nodig hebt en waar niet

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.

• Maak een overzicht van de gewenste flexibiliteit per devops-team

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 backend-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.

• Kijk wat je kunt standaardiseren op het gebied van opleidingen, processen en technologie

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.

• Denk na over wat je zelf doet en wat je outsourcet

De basisregel bij outsouring is altijd: hou datgene wat jou onderscheidend maakt dicht tegen je aan en doe dat zelf, desgewenst met tijdelijke externe ondersteuning. En outsource activiteiten 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 corebusiness. 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.

• Train de teams in wat hun verantwoordelijkheden zijn

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 24×7 mensen stand-by 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.

Prachtig concept

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.