Transformatievlakken voor ISV's - Technologie

Als je als ISV overstapt van een legacy-applicatie naar een SaaS-applicatie, gaat je organisatie op een vijftal vlakken een transformatie door: Strategie, Financieel, Organisatie, Go To Market en Technologie. In deze vijfdelige reeks nemen we deze vlakken onder de loep. De vlakken overlappen elkaar wel deels of de één heeft impact op de ander, dus je kunt ze niet echt zien als vijf afzonderlijke gebieden. Maar ze hebben ieder hun eigen vragen en onderwerpen om rekening mee te houden.

Dit artikel gaat in op de technische wijziging en de keuzes die een ISV moet overwegen bij de overgang van een legacy-applicatie naar een SaaS-applicatie in de public Cloud. Ik raad je aan om ook het ISV-playbook van Microsoft te bekijken. Ze behandelen veel van de transformatievlakken aan de hand van diepgaand onderzoek, wat kan helpen de juiste beslissingen te nemen.

Techniek

Als laatste van de 5 artikelen in deze reeks, de technische verandering. Nu schrijven wij veel over technische innovaties middels Azure en hoe je daar als ISV (software bedrijf) van profiteert, zie daarvoor ook de artikelen op onze website. Dit artikel gaat eigenlijk meer over de business impact van de technische wijzigingen als je naar de publieke cloud migreert. Sowieso zien we over al onze klanten een erg verspreid beeld. Het ene software bedrijf heeft de code zo geoptimaliseerd dat ze rechtstreeks naar een PaaS (Platform as a Service) omgeving kunnen en de andere klant heeft 20 jaar oude code waar veel aan gewijzigd moet worden voordat ze daadwerkelijk naar PaaS kunnen. Met als resultaat dat we dan vaak voor een IaaS oplossing kiezen of een combinatie. Ook speelt Azure Virtual Desktop daar weer een rol in, omdat je middels AVD applicaties online kan faciliteren met gedeeltelijk PaaS en gedeeltelijk IaaS. Voor meer informatie over AVD check ook de Azure pricing calculator. In dit artikel wil ik dan ook stil staan bij hoe je onder andere met de volgende onderwerpen omgaat: Kennismanagement onder personeel; IaaS vs PaaS; Hoe hou je innovaties bij? DevOps cultuur; Cloud security en framework.

Kennismanagement

Als je je applicatie of oplossing op de publieke cloud zet moet je ook nadenken hoe je je mensen opleid in het developen op die publieke cloud en hoe je dit gaat beheren. En hoe hou je die, zeer gewilde, mensen dan vervolgens binnen in je organisatie? Een goed startpunt, nadat je bepaalt hebt welke publieke cloud leverancier het moet worden, is om een skill assessment toe doen. Hiermee bepaal je het huidige niveau van je developers, plot dat op waar je wil staan met je doel architectuur en welke kennis je daarvoor nodig hebt en je kunt een training of opleidingsplan maken. Waar je van mag uitgaan is dat de meeste veranderingen langzaam gaan en niet binnen 1 dag klaar zijn. Dat betekend dus ook dat werken met de publieke cloud, het ontwikkelingen daar op en het beheren daarvan nieuwe vaardigenheden zijn die je krijgt door het te doen en jezelf in te trainen. Dat kost tijd. Veel van onze klanten trekken hier wel 6 maanden tot 12 maanden vooruit, voordat ze dat daadwerkelijk hebben staan. Vervolgens is het belangrijk dat je bijhoudt waar deze mensen mee bezig zijn, wat het ontwikkelplan moet zijn en hoe ze die vaardigheden op de publieke cloud kunnen bijhouden. Meetups is een goed voorbeeld van hoe ze actief kennis kunnen delen, kunnen ophalen en een netwerk kunnen opbouwen. Daarnaast zijn kennisdeel sessies intern ook een goed idee om mensen uit te dagen en uit hun comfortzone te halen en wat te laten vertellen over de nieuwste ontwikkelingen. Los van alle kennis zelf intern op te bouwen, zal je waarschijnlijk ook gebruik willen maken van kennis partners of partners die helpen met het beheren van de publieke cloud. Belangrijk is dan dat je goede samenwerkingsafspraken maakt over hoe je de kennis die jullie dan gedeeltelijk samen op doen borgt en documenteert ook intern binnen je eigen organisatie.

IaaS vs PaaS

Ik krijg vaak te horen dat je naar PaaS moet migreren, anders heeft de publieke cloud geen zin. Dit is interessant, want dit is deels wel waar en deels niet. Ja je zou naar PaaS moeten willen migreren omdat het kosteneffectief, schaalbaar, veilig en robuust is. Maar dat betekend niet dat je niet kan starten alvast te migreren naar de publieke cloud als je op IaaS draait. Er is niks mis met het afnemen van IaaS diensten binnen de publieke cloud. Al is het kostbaarder en moet je het een en ander regelen omtrent beschikbaarheid, het is een prima dienst. Ook zijn er meerdere reden om alvast te starten met IaaS. Bijvoorbeeld je bent nu nog een legacy applicatie leverancier en je wil graag je applicatie in de ogen van de eindgebruiker aanbieden als web applicatie. Dan kan je dat prima op IaaS doen. Je hebt dan al je eerste “cloud offering” of SaaS aanbieding voor je klanten klaar liggen. Dat het aan de achterkant nog niet geoptimaliseerd is, prima. Daar kan je dan vervolgens aan gaan werken. Ook kan je binnen je IaaS omgeving al vast gebruik maken van cloud native diensten, zoals firewaling, gateways etc. Dat geeft al een enorm voordeel. Dit betekend dus dat het niet een of of is, maar dat het ook een en en kan zijn. Naast alvast een SaaS oplossing in de markt hebben, kan het ook zijn dat je als software bedrijf bezig bent een investering in je bedrijf binnen te halen en dat ze dat alleen willen doen als ze het zien werken in de publieke cloud. Ook dat kan een reden zijn om alvast met IaaS te starten. Nog een reden zou kunnen zijn dat je bestaande hardware is afgeschreven en dat je het datacenter wil vervangen. Dus legio redenen om nu alvast te migreren naar de publieke cloud en niet af te wachten totdat je volledig serverless kan werken. Wel moet je intern een verantwoordelijkheid beleggen die bekijkt wat de meest efficiënte dienstverlening binnen de publieke cloud is voor het doel dat je op dat moment probeert te bereiken. Dat betekend dus onder andere dat je bij de keuzes die je maakt je moet afvragen doe ik dit al op PaaS, serverless, microservice, containers of IaaS? Afhankelijk van de casus die je hebt kan daar een andere uitkomst bij horen.

Innovatiemanagement

Nog sneller dan voorheen volgen de wijzigingen in het publieke cloud landschap elkaar op. Een Enterprise Architect hebben die eenmalig de architectuur of de structuur uitdenkt voor de komende 5 jaar is niet meer relevant. Deze mensen moeten hard omgeschoold worden om aan te haken aan de publieke cloud trein. Je zult dus een andere structuur in stelling moeten brengen, waarlangs je de innovatie gaat managen. Dan is het misschien niet perse dat je technisch de innovatie moet gaan managen en moet gaan inrichten in de cloud, maar dat je een manier van werken mogelijk maakt, waarbij developers en DevOps medewerkers de mogelijkheid krijgen binnen een vaste governance structuur de nieuwste dingen mogen en misschien wel moeten uitproberen. Dus ga je zelf zien als iemand die een innovatie cultuur faciliteert in plaats van bepaalt wat de route moet zijn.

DevOps cultuur

Een aantal weken geleden had ik twee voorbeelden van wat een enorme verandering op technisch gebied en de manier van werken transformeren naar de publieke cloud wel niet kan zijn. Aan de ene kant een software bedrijf met bijna 300 man in dienst die over de hele wereld haar software uitrolt en nu de transformatie van datacenters naar de publieke cloud wil maken. We hebben geholpen met de eerste stap uit ons Cloudify programma, het maken van een clouddesign. Vervolgens vind er geen migratie plaats naar de publieke cloud, omdat ze eerst een jaar uittrekken om de DevOps cultuur binnen de organisatie verder uit te werken. Ze maken daar 4 man een jaar voor vrij. Ze bouwen pipelines experimenteren met CI/CD en hoe ze dat willen introduceren binnen de organisatie. Kortom best een behoorlijke investering, als je er zo over nadenkt. Ik realiseer me dat zij het bij het juiste eind hebben. Want je kunt technisch nog zo veel voor elkaar hebben, als je de cultuur niet adopteert en het je echt eigen maakt, heeft het allemaal geen zin. Dus manage je DevOps cultuur! Zie het als een nieuwe sportwagen, als je daar niet in kan rijden, kan je er alleen naar kijken, hoe frustrerend is dat.

Daarnaast sprak ik het team van Team Now die een applicatie hebben gemaakt waarmee je je DevOps transformatie kan monitoren en kan gamificeren. Op deze wijze kan je je DevOps team monitoren hoe ze performen en dat zonder naar saaie cijfertjes te kijken. Check vooral hun site en neem contact met ze op als je vragen hebt over het transformeren van je DevOps teams.

Cloud security en framework

Last maar zeker niet least, cloud security. Wat is het belangrijk om op lange termijn je technische beslissingen binnen je publieke cloud keuze te beveiligen en langs dezelfde governance meetlat te leggen. Je wilt in controle zijn over je spent, maar ook over je security en dus moet je een framework hebben. Naast een framework, wat technisch mogelijk is binnen de publieke cloud, wil je het ook monitoren en rapporteren. Want technisch alles goed voor elkaar hebben, dat willen externe partijen natuurlijk ook zien. En dat kan je klant zijn, maar ook een auditer of een klant van een klant. Dus hou er rekening mee als je met de publieke cloud aan de slag gaat, dat je ook zo vroeg mogelijk begint met goverance. Shifting left in the proces noemen we dat. Helemaal aan het begin beginnen met het framework, zodat je er later niet al je processen moet aanpassen aan je nieuw gekozen framework.  

Verder lezen over transformatievlakken voor ISV’s?

Dit artikel is onderdeel van een serie over transformatievlakken bij de overstap naar de Cloud. Wil je weten wat de transformatie naar de Cloud op strategisch vlak inhoudt? Lees dan hier verder.