Hoe banken succesvol DevOps inzetten

IT bij banken zit vol risico. Er lijkt weinig speelruimte te zijn om veranderingen door te voeren , maar het gebruik van Agile en DevOps kunnen opmerkelijke resultaten worden behaald.

Banken, en dan vooral retailbanken, moeten zeer risicomijdend zijn, vooral als het gaat om hun IT-ecosystemen. Voor iedereen die ooit heeft gewerkt in IT bij een retailbank is hun deploymentmodel berucht. Ten eerste worden systeemveranderingen zes tot tien maal per jaar geïmplementeerd, normaal gesproken met bevriezingsperiodes in tijden van hoge activiteit, zoals Sinterklaas en Kerst.

Ten tweede is de overgang van development naar het eindelijk komen in de productiefase een lange en langzame route. Sommige banken kennen tot aan drie preproductie-omgevingen, waarin de veranderingen een maand lang inzitten voordat ze overgaan naar een volgende omgeving. Ten slotte komt systeemfalen, ondanks alle voorzorgsmaatregelen, verontrustend veel voor wanneer de veranderingen worden toegepast in de productie-omgeving, met vanzelfsprekend de boze reacties van de klanten van de bank en het risico op financiële verliezen.

De ironie zit hem erin dat alle voorzorgsmaatregelen die genomen zijn om risico's te vermijden, juist zeer risicovolle situaties creëren.

Hoe voorzichtigheid risico's creëert

Er is een gezegde dat oefening kunst baart. Dit is een van de grondslagen onder Lean productie of zoals het wordt genoemd, de Toyota-manier. Regelmatige herhaling verbetert de mogelijkheid om een taak uit te voeren.

Op het eerste gezicht zijn de beschrijvingen als hierboven valide. Jarenlang heeft het zich bewezen als een manier om veranderingen door te voeren via de zo geheten waterval-methode, de traditionele IT-aanpak. De requirements zijn tot in de puntjes gedefinieerd, en worden gezien als technische specificaties en als zodanig aan de ontwikkelaars overhandigd om aan de hand daarvan de code te schrijven. De code gaat vervolgens naar de testomgeving, waar het wordt getest als product en op gebruikerswaardering. Het verandermanagement besluit dan of het de veranderingen accepteert en dan gaat het naar productie. Dat wordt van oudsher gedaan door het systeem offline te halen, bijvoorbeeld om middernacht van vrijdag op zaterdag tot aan zondagavond.

Hoewel dat een juiste en nette manier lijkt om veranderingen door te voeren, zit het vol met systematische risico's:

  • Als de veranderingen worden doorgevoerd in een van de legacysystemen van de bank, is de applicatie op zichzelf al heel groot en complex. Door de jaren heen zijn patches en modificaties toegepast en, als de bank erg veel mazzel heeft, zijn er nog een of twee helden die de applicatie door en door begrijpen. De kans is eerder dat niemand meer totaal inzicht heeft in de applicatie.
  • De tijdspanne tussen de eerste specificatie van de requirements tot aan het afleveren van een afgerond product kan jaren omvatten, en tegen die tijd zijn de systeemvereisten veranderd.
  • In de periode die voorbij gaat is minimaal één teamlid naar elders gegaan en geen enkele hoeveelheid documentatie kan de opgedane informatie/ervaringen vervangen die opgedaan is tijdens de ontwikkelfase.
  • Zelfs de teamleden die vanaf het begin op het project zitten, kunnen al drie maanden op de verandering op de verandering hebben moeten wachten en al veel van de achterliggende drijfveren zijn vergeten die aan de basis staan van het ontwikkelde product.
  • Er zijn altijd een paar 'kleine' veranderingen die in het originele verzoek zijn gemoffeld indien het ontwikkeltraject geen doorlopend tempo heeft. Deze voegen hoge risico's toe omdat hun impact op de originele systeemverandering vaak niet wordt begrepen en een samenhangende integratietest niet is gedaan.
  • De testomgeving is zelden een precieze kopie van de productie. Tevens kunnen verschillende resultaten ontstaan bij complexe systemen, zelfs als de test- en productieomgeving identiek lijken.
  • Omdat veranderingen alleen een paar maal per jaar worden toegestaan is het vermogen om de verandering zonder haperingen te implementeren iets waar zowel Development als Ops niet in zijn getraind.
  • Een slecht inzicht in de systeemarchitectuur zal resulteren in een obstakel in het proberen te achterhalen wat de aard is van foutmeldingen en een mogelijke roll-back, omdat er niet genoeg tijd is om te herstellen wat er fout is in de applicatie. Het moet worden hersteld met de versie van voor de veranderingen en implementatie moet opnieuw worden gepland nadat de herstelwerkzaamheden en testen zijn gedaan. Dat is niet altijd opgenomen in het oorspronkelijke tijdschema.

Als je al die risico's overweegt is het geen wonder dat deployment onrust en spanning veroorzaakt bij alle betrokkenen.

Banken zijn ook agile

Het moet gezegd worden dat deze aanpak in de regel alleen wordt toegepast bij de legacy kernsystemen van de bank en de meeste banken hebben een andere aanpak bij de klantgerichte producten zoals internetbankieren en mobiele apps. Deze zijn ontwikkeld met gebruikmaking van agile technieken en werken onder geheel andere verandermanagementprocessen. Sommige banken kiezen ervoor dit werk uit te besteden, anderen bouwen ze in huis, maar in beide gevallen werkt IT van de bank op een ander tempo. Er is een algemeen besef dat de kernsystemen moeten worden vervangen om een uniforme en stabiele IT-infrastructuur te realiseren, maar dat kan niet van de een op andere dag worden gerealiseerd, vooral omdat het een grote herschikking betreft van alle betrokken processen.

Agile niet genoeg, daar is DevOps

Zelfs als een bank in staat is geweest om hun IT-development te uniformeren, hebben ze nog een volgende stap nodig naar continuous delivery. Agile werkt tot aan de daadwerkelijke deployment, dan gaat het over naar Operations die voor het overgrote deel uitgesloten was van het ontwikkelproces. De fusie tussen Development en Operations (en niet te vergeten Security) creëert een omgeving waarin continuous development, integratie en deployment mogelijk wordt. Dit is hoe Amazon, Facebook en andere websites die niet de luxe hebben om zich downtime te kunnen permitteren, het doen. Ze zijn in staat om meerdere deployments per dag te doen, waarvan hun klanten totaal onbewust zijn. Omdat daar heel wat automatisering voor nodig is, is DevOps vooral een cultuurverschuiving.

Banken die over tien jaar nog willen bestaan moeten een DevOps-cultuur laten bloeien. De uitdaging ligt in het introduceren van een nieuwe manier van denken, wat het beste kan door het introduceren van DevOps-as-a-Service om zo geleidelijk de nieuwe processen te implementeren en de cultuurverandering in te prenten. Banken die die uitdaging zijn aangegaan, hebben opmerkelijke doorbraken behaald.

Enkele banken die veranderen

Er zijn banken over de hele wereld die de uitdaging zijn aangegaan.

In 2011 had ING Bank een goed ingebedde CMMI- en ITIL-omgeving, met gebruik van Prince2 voor projectmanagement, maar de bank merkte instabiliteit ondanks het gebruik van best practises. Ze stapten geleidelijk over op Agile, met aanvankelijk gemengde resultaten, en introduceerden toen DevOps, met spectaculaire resultaten. Ze waren in staat meer veranderingen te implementeren door Agile, maar kwamen hetzelfde aantal incidenten tegen. Hun implementatie-risico was nog steeds hoog totdat ze DevOps gingen hanteren.

Wat nog indrukwekkender was is dat ondanks dat het aantal incidenten hetzelfde bleef, omdat de frequentie van veranderingen toenam, het aantal incidenten per verandering dramatisch daalde. Wat ING wel benadrukt is de schaarste aan de beste vaardigheden voor deze taak en hoe belangrijk het is om die binnen te halen.

Otkritie FC Bank, een van Ruslands grootste financiële organisaties, optimaliseerde de interne systemen en verbeterde bedrijfsprocessen door over te stappen naar DevOps. Hun traditionele infrastructuur was zoals bij veel banken, met nieuwe releases per kwartaal, maar een grote uitval verleidde de bank om te veranderen. Ze doken direct in het diepe, veranderden de bedrijfsprocessen, richtten zich op geautomatiseerde testen en een robuuste aanpak in het veranderen van oude gewoonten. Ze behaalden opmerkelijke resultaten in de transitie naar een digitale bank. Kirill Menshov. IT-directeur van Otkritie FC Banking Group zegt veel van die resultaten te danken te hebben aan automatisering van testen en deployment.

In Singapore is DBS een grote bank die eveneens te maken kreeg met een grote outage, in 2010. Hoewel IBM zich verantwoordelijk stelde voor het falen haalde dat de onzekerheid van de klanten van de bank niet weg. Het maakte ook geen indruk op de Monetary Authority van Singapore, die DBS beval zijn huishouden aan kant te maken. Zeven jaar later heeft DBS de overgang naar DevOPs gemaakt en zijn ze optimistisch over een mooie en meer stabiele toekomst, zowel voor hun 4,5 miljoen klanten als voor henzelf. De focus ligt nu op microdiensten, die ze sneller en beter deployen, en ze doen duidelijk iets goed want ze zijn uitgeroepen tot Best Digital Bank door Euromoney in 2016.

Google en SRE (Site Reliability Engineering)

DevOps is nu bijna een decennium oud en tien jaar is een lange tijd in IT en technologie in het algemeen. Google stelt dat ze DevOps zijn ontgroeid en SRE toepassen. Het bedrijf heeft een boek uitgegeven waarin wordt beschreven wat SRE is en hoe je dat toe kan passen. Die banken die nog steeds worstelen met hun kernsystemen zouden SRE kunnen beschouwen als een verre horizon, maar als ze vertrouwen hebben in hun DevOPs-capaciteiten kunnen ze het zien als een volgende stap.

Copyright © 2018 IDG Communications, Inc.

Learn how leading CIOs are reinventing IT. Download CIO's new Think Tank report!