In een agile enterprise waarin engineering van digitale producten centraal staat, en software-defined infrastructuur op meerdere public en private clouds draait, is operations geen fase meer zoals we gewend waren. Het draait nu om ‘plan to operate’ en ‘build to operate’. Operability staat centraal zodra een change zelfs maar wordt voorbereid. Deze aanpassing in het denken gaat gelijk op met de reis naar de cloud die de meeste bedrijven maken – en profiteert daar ook van.

Grote veranderingen

Wat betekent het Design2operate-denken nu concreet? Er verandert veel. Zo gaan we van een aanpasbare naar een niet-aanpasbare infrastructuur. Patchen of aanpassen van configuration items doen we niet meer, want elke verandering in de configuratie leidt tot een nieuwe deployment. De snelheid van het ‘deployen’ gaat met continuous delivery dan ook sterk omhoog. Hierbij behoeft de beweging van waterval naar agile geen toelichting meer.

Responstijden en SLA’s zijn geschiedenis. Het gaat nu om het vermijden van incidenten, automatisch herstel en business level-agreements. Disaster recovery sneuvelt ook.

‘Always on’ is de nieuwe ambitie, waarbij de programmeerbare infrastructuur voorzien wordt van auto-herstelopties. De workload zal toenemen, maar de bemensing hoeft niet te volgen. Automatiseren waar het kan, met behulp van bots, machine-learning en AI, is het parool, en ook haalbaar. Een belangrijke ontwikkeling in dit verband is AIOps (artificial intelligence for operations).

Op het vlak van sourcing zullen zelfbediening en geautomatiseerde fulfillment de plaats van langdurige RFP- en PO-processen gaan innemen. En vergeet crowdsourcing niet. Moderne platforms kunnen uitkomst bieden waar veel ondernemingen met een tekort aan gekwalificeerde medewerkers kampen.

Technologie

Het ‘wat’ is nu duidelijk, maar het ‘hoe’ nog niet. Kijken we naar de aspecten van deze grootschalige verandering, komen we uit bij het bekende drietal people, process and technology.

Technologie is het probleem niet. Belangrijke componenten hiervan zijn DevOps tooling, software-defined infrastructuur en een goed service management-platform. Dat laatste fungeert met zijn workflow- en automatiseringsmogelijkheden als de lijm tussen de cloud- en on-premise-diensten.

Veel cloudproviders bieden automatiseringsopties op basis van AI en machine learning en maken ze toegankelijk via standaard-api’s. Het is zaak dit soort functionaliteit niet zelf te ontwikkelen, maar de automatiseringsopties van de providers te benutten en via het eigen service management-platform te integreren.

Organisatie

Zoals gezegd zit de uitdaging niet in de techniek, maar in people en process, oftewel de manier waarop IT-organisaties traditioneel werken (in silo’s) en de competenties waarover de medewerkers beschikken. Zo zie je vaak dat IT-afdelingen hun cloudservices runnen als ware het een datacenter.

De digitale transformatie stelt echter dusdanige eisen aan snelheid en beschikbaarheid, dat de traditionele manier van werken niet meer volstaat. De referentiearchitectuur van IT4IT biedt veel aanknopingspunten voor een nieuwe manier van werken.

IT4IT zet de IT-waardeketen centraal en onderscheidt daarin vier ITwaardestromen. De manier waarop invulling wordt gegeven aan deze waardestromen en de teams die ervoor verantwoordelijk zijn, gaat veranderen.

Veel organisaties zullen een product-engineer-ing-team instellen dat met de business zal werken aan digitale producten of revenue streams. Het team moet in staat zijn digitale business te begrijpen, en programmability en automation in te brengen.

Een ander team richt zich op service alignment en service management. Het is verantwoordelijk voor het ontwikkelen, draaien en verbeteren van het serviceportfolio. Het managet ook de serviceproviders. In feite is het een klassiek SIAM-team.

Het derde is een infrastructuur- en securityteam. Het is verantwoordelijk voor het beheer van de programmable en software-defined infrastructuur, de security en de beschikbaarheid van data.

Het vierde team is een bescheiden operationsteam, verantwoordelijk voor beheer, patching en dergelijke.

Risico’s zijn onvermijdelijk – omhels ze!

Een belangrijke voorwaarde is dat de bijbehorende tooling makkelijk in te richten is. We spreken dan van intent-based tooling. Hierbij draait het om het abstraheren van de configuratie van de tools: van complexe code en instellingen naar de bedoeling die de gebruiker met een bepaalde toepassing heeft. Wanneer deze aangeeft dat een toepassing GDPR-compliant moet zijn, vertaalt zich dat bijvoorbeeld in het opslaan van de data van die applicatie gedurende twaalf maanden. De infrastructuur verzorgt automatisch de aanpassing van de benodigde instellingen.

Waar te beginnen?

Toegegeven, dit is een enorme verbouwing van de IT-organisatie. Sommige elementen van de nieuwe wereld, zoals DevOps-teams, zijn al aanwezig, andere nog niet. Waar te beginnen? Traditioneel is IT georganiseerd in silo’s. Nu moet de focus meer gaan liggen op samenwerking met zowel de business als het partnerecosysteem. Alles alleen doen is al lang niet meer mogelijk.

Werkten we vroeger met een jaarplanning, nu meer met een geautomatiseerde releaseplanning. Sourcingscontracten van drie à vijf jaar zijn passé. Nu zien we multi-sourcing als het dominante model, waarbij brokerage nodig is. Een belangrijk aandachtspunt hierbij is het zo helder en eenvoudig mogelijk houden van de cloudarchitectuur.

De verleiding is groot om op basis van kortetermijnafwegingen, bijvoorbeeld naar aanleiding van een interessante offerte, onnodige complexiteit in te bouwen. In zulke gevallen is goedkoop altijd duurkoop.

De verbouwing zal veel tijd kosten. Een goede manier om te starten is het cloud-native implementeren van alle nieuwe services. Probeer ze niet in de on-premise-omgeving onder te brengen. Bestaande infra aanpassen is een lang, pijnlijk proces waarvan de ROI niet altijd helder is. Creëer plan-build-release-run-teams. Een nieuwe cloud-native implementatie zal een inspirerende voorbeeldfunctie hebben en is makkelijk te kopiëren.

De CIO

Wat betekent dit alles voor de CIO? Is deze verbouwing niet zeer risicovol voor hem of haar? Het uitgangspunt is dat de CIO in de business ingebed moet raken. Werd hij of zij vroeger afgerekend op efficiency, nu op wendbaarheid en innovatie. Hoe efficiënt de infrastructuur is, is tot op zekere hoogte minder interessant.

De CIO van nu laat zich afrekenen op andere metrics, zoals de snelheid van innovatie, van go-to-market, van het integreren van een overgenomen bedrijf…

En over risico’s gesproken: met zoveel veranderingen zijn risico’s onvermijdelijk. Omhels ze! Werk met minimal viable products en accepteer dat die risico inhouden.

De transitie naar een digital operations model houdt in dat de CIO dit alles dient te doen. Snel zijn, wendbaar, gericht op samenwerking, werkend in ecosystemen. Cloud en automatisering, ook van de governance, zijn de bondgenoten. Welkom in de nieuwe wereld!

1 REACTIE

REAGEREN

Plaats je reactie
Je naam