nld

De nieuwe wereld: Wat betekenen Agile en DevOps voor ITSM en ITIL®?

Door Charles T. Betz en Christoph Goldenstern

Je moet wel onder een steen geleefd hebben om de impact van Agile en DevOps op alles wat met IT te maken heeft gemist te hebben de laatste tijd. Van startups tot de grootste ondernemingen ter wereld, Agile en aanverwante technieken transformeren de manier waarop IT wordt gepland, gebouwd, geleverd en beheerd.

Wat betekent deze transformatie voor IT service management professionals en het raamwerk waaraan zij de voorkeur geven -ITIL? Veel. DevOps heeft het gesprek op onverwachte manieren veranderd. Bijvoorbeeld, lang werd aangenomen dat verandering de vijand van stabiliteit was, en dus kozen organisaties voor infrequente, "goed geplande" releases - die nooit goed leken te werken.

Toen kwam DevOps. "10 Deploys a Day at Flickr" was de eerste kreet in 2009. De systemen moeten toch constant crashen? Nee, dat was niet zo. Wanneer Continuous Delivery goed wordt begrepen en correct wordt uitgevoerd, verbetert de stabiliteit van de systemen. Alleen voor Silicon Valley startups, toch? In september 2016 verklaarde Barclays Bank dat hoe vaker haar 800 Agile applicatieteams deployen, hoe stabieler haar diensten. Op alle schalen is het duidelijk dat kleinere, meer incrementele veranderingen aan complexe systemen minder risico's met zich meebrengen en de stabiliteit bevorderen. Bovendien maakt de snelle feedback van die kleine, incrementele veranderingen een nieuwe leercultuur mogelijk op basis van het testen van hypotheses door (in Lean Startup-termen) Minimum Viable Products snel naar de klant te brengen.

Wat gebeurt er en wat zou dit kunnen betekenen voor de gevestigde onderneming versus een startende organisatie? Een manier om de impact van Agile en DevOps te begrijpen is door middel van een schaalvergrotings- of "emergence" model. Het probleem met raamwerken, zoals ITIL en COBIT, is dat ze worden gepresenteerd op een ondernemingsschaal. Het raamwerk kan verklaren dat het moet worden aangepast aan de behoeften van de specifieke onderneming; maar hoe dit precies moet worden gedaan wordt vaak overgelaten aan consultants. Wat werkt voor een grote onderneming is misschien niet zinvol voor een startende onderneming. Verne Harnish merkt in het boek "Scaling Up" op dat er natuurlijke clusters van bedrijven van bepaalde omvang zijn:

  • 1-3 werknemers
  • 8-12 werknemers
  • 40-70 werknemers
  • 350-500 werknemers
  • 2.500-3.500 werknemers

Het schalingsproces kan ons helpen de huidige debatten in de industrie te begrijpen, zoals "DevOps versus ITIL". Denk na over IT-processen in deze termen. Zou u een volwaardig change management proces aanbevelen voor een bedrijf met 10 werknemers? Zou u een bedrijf met 3.000 werknemers kunnen leiden zonder een dergelijk proces? Op welk moment zou u er een introduceren, en waarom? Welke andere processen zou u introduceren en wanneer?

Agile werkt goed in kleinere contexten. Het is team-georiënteerd, en bedrijven van elke grootte realiseren zich steeds meer dat het samenwerkende team de plaats is waar waarde wordt geproduceerd. Bewezen onderzoek heeft aangetoond dat samenwerkingsculturen beter presteren dan alle andere culturen (met inbegrip van concurrerende culturen). Een bedrijf van 10 personen is een team, maar een bedrijf van 50 personen moet zichzelf zien als een "team van teams". De vraag is hoe we "de lijm" kunnen leveren voor al die teams, zodat we de onderlinge afstemming niet verliezen. Hoe meer we "losjes gekoppeld" zijn (in de termen van Spotify's ingenieurscultuur) hoe meer we "nauw op elkaar afgestemd" moeten zijn met gemeenschappelijke benaderingen die samenwerking en het oplossen van problemen vergemakkelijken.

Dit lijkt voor de hand te liggen, maar naarmate bedrijven groter worden, is het patroon zich te specialiseren naar gelang van de functies:

  • Marketing
  • Onderzoek en ontwikkeling
  • Verkoop
  • Operaties en service
  • Back-office (Financiën, HR, IT)

Bovendien zijn er sub-specialisaties binnen elke functie (bv. IT specialiseert zich verder in applicatie- en infrastructuurteams; infrastructuurteams specialiseren zich in server, opslag, networking, 24 x 7 NOC, enzovoort).

IT organiseert zichzelf als een "order nemer", zowel in haar relatie tot de business als intern. Applicatie teams dienen "tickets" in bij het infrastructuur team voor benodigde middelen, bijvoorbeeld. Dit model kan IT-systemen en -diensten opleveren die redelijk stabiel zijn, maar ze zijn vaak traag te leveren en traag te veranderen. Functionele silo's versus end-to-end procesdenken is de norm, wat een beetje ironisch is omdat dat niet is wat raamwerken als ITIL voorstaan.

Digitale transformatie daagt vandaag silo's uit en verstoort ze. Aangezien marktgerichte producten steeds meer informatietechnologie bevatten, convergeert de "backoffice" IT met onderzoek en ontwikkeling en algemene operaties en service. Nu IT van cruciaal belang is voor het voortbestaan van een bedrijf, moet het beter kunnen inspelen op de behoeften van de markt. Stabiliteit is nog steeds vereist, maar stabiele systemen die niet aan de snel veranderende marktbehoeften voldoen, zijn waardeloos.

Functionele silo's vereisen handoffs. Handoffs veroorzaken vertraging en vertragen het reactievermogen. Functionele silo's hebben de neiging om een "wij-tegen-hen" houding te ontwikkelen ten opzichte van de teams die zij bedienen, en waarvan zij diensten vragen. Daarom promoten Agile methoden teams met meerdere vaardigheden: zoals Marty Cagan zegt in zijn invloedrijke boek, Geïnspireerd: Hoe maak je producten waar klanten van houden, moet het team minimaal in staat zijn om een product naar drie noodzakelijke kwaliteiten te stuwen:

  • Is het waardevol?
  • Is het bruikbaar?
  • Is het haalbaar?

Een team dat resultaten kan bereiken in overeenstemming met deze drie dimensies kan een "full stack" worden genoemd. Scrum en andere Agile methoden benadrukken herhaaldelijk dat het team in staat moet zijn om in het algemeen, op eigen kracht te opereren, met minimale externe afhankelijkheden en blokkades.

Een andere huidige praktijk is "je bouwt het, je draait het". Dit is een goede praktijk en een grote verandering ten opzichte van de oude dagen van "throw it over the wall and run", toen ontwikkelaars weinig verantwoordelijkheid namen voor het schrijven van software die daadwerkelijk in productie kon worden genomen. In wezen verschuift de nadruk van een verticaal IT "fabrieksmodel" naar een meer "horizontale management" benadering. Dit is waar het team end-to-end verantwoordelijkheid heeft, inclusief enkele van de meer traditionele ITIL disciplines van Incident en Problem Management.

Zoals de beroemde Amazon CTO Werner Vogels zei: "Het geven van operationele verantwoordelijkheden aan ontwikkelaars heeft de kwaliteit van de diensten enorm verbeterd, zowel vanuit het oogpunt van de klant als vanuit technologisch oogpunt." Ontwikkelaars dragen nu steeds meer "de pieper", en worden gestimuleerd om software te schrijven die stabiel, schaalbaar en goed functionerend is, naast het voldoen aan de verwachtingen van de gebruiker voor functionaliteit.

Waarheen ITIL?

Deze team-gebaseerde benaderingen hebben bewezen opmerkelijk goed te werken, dat is waarom organisaties, groot en klein, over de hele wereld zich haasten om Agile en DevOps te adopteren.

Maar op het "team van teams", grote organisatieniveaus, moeten communicatie en samenwerking teams overschrijden. We kunnen proberen de behoefte aan dergelijke communicatie te minimaliseren, maar hoe weet je op een bepaald moment dat twee veranderingen niet met elkaar zullen botsen? Team-overschrijdende processen om activiteiten te coördineren en te synchroniseren, moeten zich snel richten op de kritieke stukjes informatie die van vitaal belang zijn voor de operaties en die een minimale, maar essentiële kwaliteitscontrole bieden (b.v. de incident- of probleemverklaring).

Een gemeenschappelijke aanpak voor het oplossen van problemen binnen de teams neemt een aantal barrières weg tussen incident-, probleem- en wijzigingsbeheer. Wanneer iedereen "dezelfde taal spreekt voor het oplossen en uitvoeren van problemen", wordt de "dode tijd" van ineffectieve of repetitieve activiteiten tot een minimum beperkt en wordt de manier waarop gegevens worden gebruikt en gedeeld verbeterd.

Veranderingsmanagementt

Omdat ITIL lang een rigoureus veranderingsproces heeft bepleit, is het een obstakel geworden voor veel voorstanders van Agile en DevOps. Maar het vertragen van de doorvoer van veranderingen (wat ITIL Change Management meestal doet) is niet gecorreleerd met systeemstabiliteit.

Nu, in alle eerlijkheid tegenover ITIL, voortdurende updates van een toepassing of dienst waarvan het platform in het algemeen stabiel is, worden gezien als "standaard" wijzigingen die geen bespreking of goedkeuring behoeven. Er is niets in ITIL dat dit verhindert. De realiteit in te veel organisaties is echter om "de ontwikkelaars te laten wachten" door een change-control cadens van één of twee weken te gebruiken.

Wanneer operations engineers verantwoordelijk zijn voor het doorvoeren van de vereiste wijziging in de productie, kan een vertraging van een wijziging het gevolg zijn van te veel werk in het proces en niet van een gebrek aan teamoverstijgende synchronisatie (zoals het gebruik van een tweewekelijkse Change Approval Board meeting voor het beoordelen van risico's). Echter, naarmate meer teams werken op een "jij-bouwt-het, jij-voert-het" basis, wordt het doorvoeren van productieveranderingen door operations gezien als niet waarde toevoegend. Zelfs de vaak geciteerde "scheiding van taken" zorg is vervaagd. (Zie de DevOps Audit Defense Toolkit, mede geschreven door DevOps-evangelist Gene Kim en IT-auditor James DeLuccia).

Verder dan veranderingsbeheer

Hoe hebben Agile- en DevOps-teams ITIL ervaren, afgezien van Change Management? Teams die operaties beheren, inclusief de helpdeskfunctie en 24 x 7 centra (wat twee verschillende diensten zijn), hebben de neiging ITIL training en terminologie over te nemen en hebben serviceteams die opereren als functionele silo's.

Deze silo's worden verdedigd met opmerkingen als, "we hebben niet genoeg mensen om elk ontwikkelteam hun eigen operations personeel of infrastructuur ingenieurs te geven!" Maar dit gaat voorbij aan het punt van moderne cloud-gebaseerde DevOps praktijken en ziet belangrijke aspecten van IT service management over het hoofd. ITIL pleit voor het opstellen van Service Catalogs, die vaak worden gebruikt om infrastructuurdiensten te "front- end". Historisch gezien ondersteunt een Service Request Management proces deze diensten, vaak met handmatig werk (bv. een ingenieur die een aanvraag voor enkele nieuwe servers analyseert).

Cloud en micro services benaderingen veranderen het gezicht van Service Request Management met een consistente, catalogus-gebaseerde front-end en volledig geautomatiseerde service. Wat is de Amazon of Azure Cloud portal anders dan een service catalogus met een hoge mate van automatisering? Self-service en automatisering maken functionele teams sterker en bevrijden de infrastructuurteams van de meeste on-demand consulting- en engineeringdiensten, zodat ze zich kunnen concentreren op het bouwen en onderhouden van een gedeelde, self-service infrastructuur.

Op weg naar bedrijfsschaal

Wat gebeurt er wanneer een Agile-mentaliteit op ware ondernemingsschaal wordt gebracht? Naast de behoefte aan "team of teams" coördinatie, zijn er problemen met risicobeheer, governance en meer. Bedrijfscontinuïteit, probleembeheer en reactie op grote incidenten worden kritieke punten van zorg. Kepner- Tregoe is van mening dat met name het beheer van grote incidenten gespecialiseerde vaardigheden vereist die de onderneming helpen beschermen tegen catastrofale schade en verlies. Dit "noodoplossingvermogen" om het bloeden te stoppen wanneer zich grote storingen voordoen, vereist specialisten met een combinatie van zowel uitstekende probleemoplossing als facilitatie- en communicatievaardigheden, vanwege de van nature hoge druk op de omgeving en de overvloed aan belanghebbenden die tevreden moeten worden gesteld.

Bovendien kunnen organisaties het zich in deze snel veranderende omgeving niet veroorloven om dezelfde oude problemen te blijven oplossen. Het introduceren van Agile en DevOps principes in een organisatie met een onoverkomelijke achterstand van open problemen (en, daardoor, stijgende incidentvolumes) is een riskante onderneming. Om Agile en DevOps te laten slagen, moeten organisaties Problem Management serieus gaan nemen en middelen gaan inzetten om de oorzaak van problemen te vinden. Het terugvoeren van Problem Management in de backlog van het team, op dezelfde voet als nieuwe user "stories," is een opkomende best practice.

Aan de andere kant is een risico van schaalvergroting wanneer de organisatie zo veel processen implementeert dat de zo belangrijke teamervaring wordt verstoord. Meervoudige processen die meer worden gedreven door de behoefte aan administratie/documentatie dan door de waarde van hun output, kunnen de levering door de teams blokkeren en hun samenhang en vermogen om klantwaarde te leveren verslechteren. Een dergelijke verslechtering van de prestaties is ook een bedrijfsrisico; mogelijk het grootste risico van schaalvergroting.

Tot besluit

Er is veel dat ITSM-praktijken te bieden hebben aan de nieuwe Agile/DevOps-wereld. Ze bieden een afstemming rond taal en bewezen praktijken. Service catalogi, Change, Incident, en Problem Management zijn allemaal relevant. Organisaties moeten er echter voor waken ITSM te gebruiken als een reden om structuur en processen te benadrukken boven serviceresultaten, waardoor een deel van de oorspronkelijke bedoeling van frameworks als ITIL verloren gaat. Een servicegerichte benadering van gebruikersresultaten maakt al lang deel uit van de ITSM-filosofie, en servicemanagers die zich daarop blijven richten en het vermogen hebben om "kwaliteitsdenken op snelheid" toe te passen, zullen het goed blijven doen. Uiteindelijk gaat het allemaal om die klantervaring, en hun dagelijkse moment van de waarheid wanneer ze uw digitale systemen tegenkomen, zowel wat betreft kwaliteit als stabiliteit.

Over Kepner-Tregoe

Kepner-Tregoe is de leider in het oplossen van problemen. Al meer dan zes decennia helpt Kepner-Tregoe duizenden organisaties over de hele wereld bij het oplossen van miljoenen problemen door middel van een effectievere analyse van de onderliggende oorzaak en besluitvormingsvaardigheden. Kepner-Tregoe werkt samen met organisaties om de kosten aanzienlijk te verlagen en de operationele prestaties te verbeteren door
probleemoplossende training, technologie en adviesdiensten.

Gerelateerd

Shift Left? Nee, 'Shift Down' voor Services Support Success

De strategische rol van klantenondersteuning bij het maximaliseren van aandeelhouderswaarde

Wij zijn experts in:

Neem contact met ons op

Voor vragen, details, of offertes!