Door op 01/01/2020

Development en Operations zijn in veel organisaties nog twee aparte werelden. Maar beide werelden gaan eigenlijk enorm goed samen. Sterker nog: als je van Development en Operations één DevOps-team maakt, heb je niet langer twee teams die slechts garant staan voor hun eigen stukje van het product. Je hebt dan één team met één hoofddoel: een goed werkend product, dat draait bij iedere klant.

Maanden later nog gedoe

Je ziet het nog vaak gebeuren in veel organisaties: de Development-afdeling maakt een toffe nieuwe functionaliteit. Het werkt als een tierelier, accountmanagers en product owners laten het foefje graag aan hun klanten en stakeholders zien, en Development gaat met een glimlach op het gezicht op naar het volgende project.

Maar dan, een paar maanden later, komt de release om de hoek kijken. Dankzij de nieuwe functionaliteit kakt de performance van je product flink in. Het foefje roept de database achter je product vaker op dan je in een bedrijfsomgeving wilt. Development zit met zijn hoofd én mankracht allang weer ergens anders.

Je Operations-team ziet de bui alweer hangen: het aantal hulpkreten richting database verminderen totdat de nieuwe functionaliteit de performance van je product intact laat. En dan kun je eigenlijk zeggen dat je van één naar twee Development-afdelingen bent gegroeid.

Samen naar de finish

Het bedrijfsleven omarmt de principes van agile steeds meer, en softwareproducten worden steeds vaker via Continuous Deployment in de markt gezet. Dan wordt natuurlijk niemand blij van maanden later nog aan een nieuwe feature moeten sleutelen. Als je een nieuwe functionaliteit toevoegt aan je product, wil je juist zo snel mogelijk feedback. Zodat Development snel belangrijke fouten kan herstellen.

Maar hoe zorg je ervoor dat je medewerkers de feedbackloop op je product kunnen versnellen? Voor veel IT-organisaties is DevOps het antwoord. Development wordt niet alleen verantwoordelijk voor het bouwen, maar ook het succesvol gebruik van het product. En Operations gaat juist meer meedenken tijdens het ontwikkelproces.

Samenwerken in dezelfde systemen

Development gebruikt en onderhoudt systemen waar Operations veel ervaring mee heeft, zoals voor code repositories en automated tests. Waarom zou Development niet dezelfde systemen gebruiken als Operations?

Sterker nog: laat Operations die tools voor beide partijen beheren, iets waar zij juist de meeste ervaring mee hebben. En als je bedrijf er klaar voor is, is je OTAP-infrastructuur (Ontwikkeling, Test, Acceptatie en Productie) centraal beheren op bijvoorbeeld de SaaS-omgevingen van Operations ook verstandig.

Nieuwe technologie effectief voorblijven

Omdat IT-infrastructuur steeds complexer wordt, wordt processen automatiseren steeds belangrijker voor de meeste Operations-teams. Als je bijvoorbeeld 1.500 SaaS-omgevingen beheert, wil je die niet allemaal handmatig bijwerken. Operations werkt daarom steeds vaker met code, net als een Development-afdeling. Een zogeheten desired state configuration wil je bijvoorbeeld zo centraal mogelijk beheren, waarbij je ook gebruikmaakt van een versiebeheersysteem als Git.

Samenwerken in dezelfde omgevingen en tools, en samen werken aan de zo efficiënt mogelijke oplevering van nieuwe functionaliteit. Dat is eigenlijk de sleutel tot jezelf een DevOps-organisatie mogen noemen. Als kers op de taart heb je dus ook nog eens het voordeel dat je niet twee clubs in je bedrijf die apart het wiel opnieuw uitvinden.

Betekent DevOps het einde van ITSM, of brengen ze elkaar juist tot nieuwe hoogten? Lees het hier.

Weinig redenen om de stap naar DevOps niet te zetten. Of zien jullie dat anders? Laat je reactie achter onder dit blog.