Het besluit is genomen: na een aantal experimenten en voorzichtige stappen heeft het hogere management besloten dat de organisatie naar de cloud gaat. Dan begint het echte werk pas. Een cloudmigratie die gebaseerd is op strategisch inzicht in het applicatieportfolio voegt de meeste waarde toe en kan zo’n verhuizing in een versnelling brengen.
Een migratie naar de cloud is voor de meeste organisaties een ingrijpende gebeurtenis. Processen, legacy-apparatuur en applicaties moeten tegen het licht gehouden worden. Passen ze nog in de cloud-strategie? Kunnen we ze vervangen door cloud-varianten of kunnen ze ‘lift and shift’ verplaatst worden? Het hele proces blijkt vaak een kwestie van experimenteren, migreren en transformeren.
De eerste stap is om de rest van de organisatie ook mee te nemen. Voor de meeste gebruikers is IT een basisvoorziening die het vooral moet doen. Een migratietraject dat voor hen geen meerwaarde oplevert, maar wel ongemak en risico’s, zitten ze niet op te wachten. Zonder degelijke uitleg vooraf, over het hoe en waarom, zal de bereidheid tot medewerking niet groot zijn.
Vervolgens worden applicaties die naar de cloud moeten in beeld gebracht. Dat is ingewikkelder dan het lijkt. Vaak is er binnen IT al geen eenduidig overzicht van de applicaties die er zijn, laat staan van alles wat er buiten IT om is gekocht of gebouwd.
Als het applicatieoverzicht er eenmaal is, is het van belang om vast te stellen hoe de applicaties gemigreerd zouden moeten worden naar de cloud. Het bekendste model hiervoor is dat van AWS: het ‘6R model’ (6 Strategies for migrating applications to the cloud) om het overzetten van applicaties naar cloud infrastructuur te versnellen. Applicaties worden in dit model langs de meetlat gelegd, om uiteindelijk in één van de zes ‘R’ bakjes te vallen:
- Retire:
De applicatie is niet meer nodig of levert te weinig waarde, ten opzichte van de kosten, en wordt daarom uit gefaseerd. - Retain:
De status quo rond een applicatie blijft voorlopig gelijk. Deze keuze is relevant als een applicatie een beperkte levensverwachting heeft of ongeschikt is om naar de cloud over te zetten, bijvoorbeeld vanwege bijzondere eisen of eigenschappen van de applicatie, of technologisch zwaar verouderd. Retain moet altijd worden gezien als een tijdelijke oplossing; je zit er immers niet op te wachten om voor een beperkte verzameling applicaties een dure uitzonderingspositie te handhaven. - Rehost:
De applicatie gaat één op één naar de cloud (‘lift and shift’). Dit is doorgaans een snelle, goedkope en relatief risico vrije manier om te migreren, maar levert ook geen meerwaarde op. Immers, bestaande problemen zullen ook één op één meegaan naar de cloud. In de praktijk brengt deze keuze vaak hogere infrastructuurkosten met zich mee voor de applicatie. Organisaties betalen de flexibiliteit van de cloud met een hogere uurprijs dan in een marktconform geprijsd datacenter. - Replatform:
Voor de applicatie wordt een nieuwe infrastructuur gebouwd in de cloud, de software zelf blijft onaangeroerd. Deze aanpak is vooral geschikt voor de migratie van applicaties waarvoor de organisatie alleen een gebruikslicentie heeft en geen eigendom van de broncode. Dit is bijvoorbeeld bij standaardpakketten het geval. Ten opzichte van een rehost is dit een complexere en dus duurdere en minder snelle manier van migreren. Het levert wel meerwaarde op doordat er optimalisaties gedaan kunnen worden en bestaande problemen opgelost kunnen worden. Zonder de software aan te passen zijn de mogelijkheden beperkt en zal ook de meerwaarde beperkt zijn. - Refactor:
Voor de applicatie wordt een nieuwe, zo optimaal mogelijke, infrastructuur gebouwd in de cloud en wordt de software aangepast, zodat deze optimaal op de cloud infrastructuur draait. De functionaliteit verandert in principe niet. Vaak is er overigens geen sprake van een infrastructuur in de klassieke opvatting, maar van een PaaS platform waar de software op landt. Deze aanpak is vooral geschikt voor de migratie van applicaties waarvan de organisatie eigenaar is; bijvoorbeeld maatwerk. Ten opzichte van replatform is hier opnieuw sprake van een hogere meerwaarde. Dit loopt echter tegen zijn grenzen aan door de eigenschappen van de software. - Repurchase:
De applicatie wordt in zijn geheel opnieuw aangeschaft of gerealiseerd. Hierbij kan maximaal gebruik worden gemaakt van de diensten van cloud serviceproviders, maar de weg is lang en kostbaar. Je praat immers over een totale vervanging, waarbij ook de functionaliteit zal veranderen en je dus ook de organisatie zal moeten aanpassen en trainen om van de nieuwe oplossing gebruik te maken.
Bovenstaand overzicht lijkt helder. Als je gedetailleerd naar de materie kijkt, is het veel minder eenduidig dan het in eerste instantie lijkt. Er is bijvoorbeeld niet één meetlat langs welke je de applicaties legt. Bijvoorbeeld: als ik een applicatie één op één verplaats, maar een instelling wijzig omdat de nieuwe omgeving dat eenmaal vereist (bijvoorbeeld een andere locatie voor de database), is het dan al een replatform? En als het er twee zijn? Of tien? Of als ik het meer recente versie van het besturingssysteem neem? Bovendien zijn de kosten meer dan één aspect: organisaties die al gebruik maken van de cloud ontdekken dat kostenbesparingen maar een beperkt deel zijn van de waarde die cloud biedt. De cloud biedt vooral ook mogelijkheden voor innovatie.
Strategisch inzicht in het applicatieportfolio kan een cloudmigratie in een versnelling brengen, omdat zo’n analyse business waarde en de kwaliteit van software in de beoordeling meeneemt. Veel organisaties hebben hier geen inzicht in. Zij managen het portfolio alsof alle applicaties gelijk zijn en/of gelijkwaardige problemen hebben. Daarnaast wordt er niet goed op waarde geschat wat het bedrijfsbelang van een specifieke applicatie is. Hierdoor is het lastig om de juiste prioriteiten te stellen. Met de Metri Applicatie Portfolio Strategizer wordt er per applicatie een passend migratieplan vastgesteld, die in een bredere cloudmigratie in te passen is.