In het vorige blog las je dat een goede Cloud transitie begint bij het slim inpakken van je koffer. Of in technische taal: hoe beter je nadenkt over je toekomstige IT-situatie, hoe soepeler de migratie en hoe gunstiger het eindresultaat. Maar dan komt het. Want hoe regel je die voorbereiding goed? Wat ons betreft begint alles met het in kaart brengen van je applicatielandschap. Want als je weet wat je hebt staan en wat de ideale locatie zou zijn van je applicaties, ben je al een heel eind. In dit blog lees je daarom hoe je je applicatielandschap in kaart brengt aan de hand van een overzichtelijk stappenplan.
Landingsplaatsen per applicatie
Wie zijn applicatielandschap in kaart brengt, maakt een lijst van alle bestaande applicaties en bepaalt per individuele applicatie de beste landingsplaats in de nieuwe situatie. Er zijn immers meer smaken dan “Cloud” en “geen Cloud”. Zo kan je ervoor kiezen applicaties te migreren naar een Public Cloud, een Managed Public Cloud of een Private Cloud. Ook kan je een applicatie helemaal uitzetten omdat je ‘m niet meer nodig hebt na de cloudmigratie, of ‘m vervangen door een SaaS-product. Als het SaaS-product in precies dezelfde behoeften voorziet als de applicatie die je hebt vervangen, profiteer je zo nog steeds van alle functionaliteiten van de applicatie, maar neemt de leverancier het beheer en onderhoud van je over.
Er is geen goed of fout (of wacht, toch wel)
Welke landingsplaats het beste past, hangt simpelweg af van de applicatie. Een Managed Public Cloud is namelijk niet per se beter dan SaaS. Er bestaat wel zoiets als een mismatch tussen je cloudstrategie en de doelstellingen van je bedrijf. Stel dat jullie met een applicatie werken die jullie onderscheidt van jullie concurrenten. In dit geval wil je de ontwikkeling en het beheer van die applicatie zoveel mogelijk binnenshuis houden, omdat je de applicatie zelf het beste kent en misschien al op een DevOps-manier werkt. Als je er vervolgens voor kiest om het beheer van deze applicatie volledig uit te besteden, kan dit tot een hoop frustraties leiden. Zo weet je leverancier misschien niet goed hoe hij je applicatie beschikbaar moet houden en betaal je voor iets dat je uiteindelijk alsnog zelf moet doen. Het tegenovergestelde kan ook: als jullie strategie voorschrijft dat jullie zoveel mogelijk beheer uit handen geven, wil je juist wél zoveel mogelijk taken laten overnemen door een leverancier, of applicaties afnemen als SaaS-product.
Hoewel je nieuwe applicatielandschap dus afhangt van je bedrijfsdoelstellingen, hoef je het wiel niet opnieuw uit te vinden. Op basis van onderstaand stappenplan verzamel je nuttige informatie waarmee je zelf de ideale landingsplaats bepaalt:
Stap 1. Onderscheid missie-kritische applicaties van niet missie-kritische
Stel jezelf bij iedere applicatie de vraag of deze noodzakelijk is om de operatie draaiende te houden. Is het antwoord ja? Dan heb je te maken met een missie-kritische applicatie. Denk aan je ERP-systeem en klantapplicaties. Als je deze uitzet, functioneert (een deel van je) organisatie niet meer en lijd je dus schade. Missie-kritische applicaties zijn daarom het beste op hun plek in een omgeving die ervoor zorgt dat ze altijd en stabiel kunnen leveren.
Voorbeelden van niet missie-kritische applicaties zijn experimenten of nieuwe klantapps die nog niet live zijn. Dit soort applicaties vraagt boven alles om flexibiliteit. Omdat developers nog aan de applicaties sleutelen, heb je veel computerpower nodig en mogelijkheden om op te schalen als de apps een succes blijken te zijn en je ze beschikbaar wilt maken voor een groot publiek. Tegelijkertijd moet je omgevingen ook makkelijk uit kunnen zetten als de experimenten geen succes blijken te zijn.
Stap 2. Onderscheid applicaties met onderscheidend vermogen van niet-onderscheidende applicaties
De tweede vraag die je jezelf stelt, gaat over het onderscheidende vermogen van de applicatie. Kopen klanten bij jouw bedrijf omdat jij met deze specifieke applicatie werkt? Dan draagt de applicatie bij aan je onderscheidende vermogen en is het belangrijk dat je deze kunt blijven ontwikkelen na de cloudmigratie.
Applicaties die jouw dienstverlening niet per se uniek maken, zijn bijvoorbeeld planningssystemen, en boekhoudpakketten. Dit soort applicaties wil je liever niet zelf beheren, zeker omdat Cloud Service Providers dit vaak veel beter (en kosten-efficiënter) doen. Ze leveren deze diensten immers aan duizenden bedrijven tegelijk.
Stap 3. Bepaal de landingsplaats per applicatie
In stap 1 en 2 heb je missie-kritische van niet missie-kritische applicaties onderscheiden en bedrijfs-unieke applicaties van de standaardapplicaties. In stap 3 bepaal je wat de beste landingsplaats is per applicatie. Hiervoor kun je kiezen uit vijf smaken:
- Managed Private Cloud
- Public Cloud
- Managed Public Cloud
- Vervangen door SaaS
- Uitzetten
Afhankelijk van je bedrijfsdoelstellingen ga je je applicaties nu indelen in deze vijf groepen. Zo kan je applicaties die je na de cloudmigratie niet meer nodig hebt, uitzetten (offloaden) en niet missie-kritische en niet-onderscheidende applicaties zoals boekhoudpakketten af gaan nemen als SaaS. Hou hierbij de bedrijfsdoelstellingen goed in de gaten. Willen jullie bijvoorbeeld veel applicaties in eigen beheer houden vanwege hun onderscheidende vermogen maar wil je wel veel computerpower en ontwikkelmogelijkheden? Dan is een Public Cloud een geschikte optie. Wil je juist zoveel mogelijk uit handen geven om je handen vrij te maken voor andere zaken? Kies er dan voor om een groot deel van je applicaties af te nemen als SaaS.
Stap 4. Maak groepen per applicatie (clustering)
Als je je overbodig geworden applicaties even buiten beschouwing laat, heb je nu vier groepen applicaties. Deze applicaties hebben dezelfde eigenschappen (bijvoorbeeld missie-kritisch maar niet onderscheidend) en vormen daarmee een cluster. Voor dat cluster bepaal je vervolgens wat er moet gebeuren. Handig, want zo hoef je je applicaties niet ad hoc te migreren, maar werk je met groepen applicaties die overeen komen of zelfs overlap hebben. Ook kun je per cluster bekijken wat de migratielast gaat zijn. Hoe complex wordt de transitie bijvoorbeeld en hoe lang verwacht je dat deze gaat deze duren? Op basis van deze informatie bepaal je de quick wins (lichte applicaties die je snel kunt migreren en die ook snel waarde creëren) en maak je een planning. Onderstaande infographic is handig om bij deze planning te gebruiken.
Next steps: plan je cloudmigratie
Hopelijk weet je na het lezen van deze korte gids hoe je het applicatielandschap van jouw organisatie in kaart brengt en voorbereidt op de cloudmigratie. Maar hoe zet je zo'n migratieplan precies op poten? In onderstaand e-book delen we een uitgebreid stappenplan, zodat je niet migreert om het migreren, maar de Cloud als middel gebruikt om een Digital Enterprise te worden.
