Mijn IT-dienstverlener adviseert Azure. Hoe beoordeel je zo’n voorstel?

Uw IT-dienstverlener komt met een voorstel. De huidige omgeving begint te verouderen en volgens de dienstverlener is dit een goed moment om een deel van de IT-omgeving naar Microsoft Azure te migreren.

Het verhaal klinkt logisch. Azure is een bewezen platform, de dienstverlener heeft er ervaring mee en in de presentatie komen voordelen voorbij als flexibiliteit, schaalbaarheid, veiligheid en minder zorgen over de onderliggende infrastructuur.

Toch blijft er na de presentatie een vraag hangen:

Dat is een gezonde vraag. Niet omdat er iets mis hoeft te zijn met het advies of met de dienstverlener. Het voorstel kan uitstekend zijn. Maar een goede technische oplossing is nog niet automatisch de juiste oplossing voor uw organisatie.

Om dat te kunnen beoordelen, zou ik daarom niet beginnen bij Azure.

Begin bij het probleem dat moet worden opgelost

Stel dat de dienstverlener aangeeft dat de huidige serveromgeving binnen twee jaar vervangen moet worden. De voorgestelde oplossing is een migratie naar Azure.

Dan lijkt de keuze op het eerste gezicht overzichtelijk: investeren we opnieuw in eigen infrastructuur of gaan we naar de cloud? Maar daarmee slaan we een stap over.

Waarom moeten de servers worden vervangen en wat willen we daarmee bereiken?

Misschien is alleen de hardware aan het einde van zijn levensduur. Maar het kan ook zijn dat de interne IT-afdeling minder tijd wil besteden aan technisch beheer, applicaties tegen capaciteitsproblemen aanlopen, de organisatie snel groeit of men de continuïteit wil verbeteren.

Dat zijn verschillende vraagstukken die tot verschillende goede oplossingen kunnen leiden.

Past het voorstel bij wat de organisatie nodig heeft?

Als de aanleiding duidelijk is, kan het voorstel zelf worden bekeken. Daarbij gaat het niet alleen om technische eisen. De oplossing moet ook passen bij de organisatie die ermee moet werken.

Een organisatie met een grote interne IT-afdeling, veel technische kennis en tientallen bedrijfskritische applicaties heeft andere mogelijkheden en behoeften dan een organisatie met een klein IT-team dat vrijwel het volledige technische beheer heeft uitbesteed.

Ook cloud vraagt om grip op gebruik en kosten. Zonder goed inzicht in waar kosten ontstaan en hoe deze kunnen worden beheerst, kunnen de werkelijke kosten anders uitpakken dan vooraf verwacht.

Daarom wil ik ook begrijpen wat de organisatie de komende jaren verwacht. Welke applicaties zijn belangrijk? Welke veranderingen zijn voorzien? Welke kennis is intern aanwezig? Welke rol moet de IT-dienstverlener blijven spelen? En hoeveel flexibiliteit is daadwerkelijk nodig?

Een uitgebreide technische beschrijving van Azure kan uitstekend uitleggen hoe de oplossing werkt, maar geeft nog geen antwoord op de vraag of die oplossing ook bij de organisatie past.

Welke alternatieven zijn onderzocht?

Een van de vragen die ik bij een belangrijk IT-voorstel vrijwel altijd interessant vind, is:

Welke andere mogelijkheden zijn onderzocht en waarom zijn die afgevallen?

Dat betekent niet dat voor iedere beslissing vijf volledig uitgewerkte ontwerpen op tafel moeten liggen. Maar uit een goed voorstel moet wel blijken dat er een afweging heeft plaatsgevonden.

Misschien is Azure inderdaad de meest logische keuze. Misschien kan een deel van de huidige omgeving beter blijven staan. Bepaalde applicaties zijn wellicht inmiddels als SaaS-oplossing beschikbaar en hoeven helemaal niet naar Azure te worden gemigreerd. Of misschien past een combinatie van oplossingen beter.

Een Microsoft-georiënteerde IT-dienstverlener zal veel kennis van Azure hebben en daar waarschijnlijk efficiënte diensten omheen hebben gebouwd. Dat is juist een voordeel. Tegelijkertijd wordt een oplossing daarmee mede bekeken vanuit de kennis en dienstverlening die de dienstverlener zelf kan bieden.

Daarom moet duidelijk zijn waarom juist deze oplossing voor uw organisatie is gekozen.

Kijk verder dan de migratie

Bij grote IT-veranderingen krijgt de migratie zelf gemakkelijk de meeste aandacht. Wat kost deze? Hoe lang duurt het? Welke systemen moeten worden overgezet en hoe beperken we de verstoring?

Maar de gevolgen van de keuze duren veel langer dan het migratieproject.

Hoe ziet onze situatie eruit wanneer de migratie achter de rug is?

Welke kennis is dan nodig? Welke werkzaamheden voert de dienstverlener uit en welke verantwoordelijkheid blijft bij de eigen organisatie? Hoe eenvoudig kunnen diensten later worden aangepast of vervangen? En wat gebeurt er als het gebruik sterker groeit dan verwacht?

Juist daar wordt duidelijk of een oplossing niet alleen tijdens de implementatie aantrekkelijk is, maar ook daarna.

Wat gaat het werkelijk kosten?

Cloudkosten vergelijken met alleen de aanschafprijs van servers levert zelden een volledig beeld op.

Bij een goede vergelijking kijk je naar de totale kosten over meerdere jaren. Denk aan infrastructuur, licenties, beheer, ondersteuning, verbindingen, beveiliging, back-up, benodigde interne kennis en dienstverlening van externe partijen.

Een oplossing die op papier duurder is, kan bijvoorbeeld beheerrisico wegnemen of investeringen vooraf voorkomen. Andersom kan een oplossing met lage instapkosten op termijn duurder worden wanneer het gebruik groeit of steeds meer aanvullende diensten nodig zijn.

Het doel is daarom niet simpelweg de goedkoopste oplossing te vinden.

Het gaat erom dat duidelijk is waarvoor u betaalt, welke voordelen daar tegenover staan en welke kosten en risico’s u voor de komende jaren accepteert.

Welke afhankelijkheden ontstaan?

Iedere belangrijke IT-keuze creëert afhankelijkheden. Ook de huidige omgeving kent die waarschijnlijk al: van hardware, softwaredienstverleners, specifieke kennis of de IT-dienstverlener die de omgeving beheert.

Een overstap naar Azure haalt bepaalde afhankelijkheden weg, maar introduceert andere.

Dat hoeft geen probleem te zijn. Volledige onafhankelijkheid van dienstverleners is in de praktijk nauwelijks realistisch en vaak ook niet wenselijk. Specialisatie en standaardisatie kunnen juist veel voordeel opleveren.

Wel moet duidelijk zijn welke afhankelijkheden bewust worden aangegaan. Hoeveel van de oplossing is specifiek voor Azure ingericht? Welke kennis is nodig? Kan een andere IT-dienstverlener het beheer relatief eenvoudig overnemen? En wat betekent het als de organisatie over vijf jaar een andere richting wil kiezen?

Past de keuze bij de toekomstige IT-koers?

Een van de risico’s bij een technisch voorstel is dat het afzonderlijk wordt beoordeeld. De oplossing kan prima zijn voor het probleem van vandaag, terwijl hij minder goed past bij waar de organisatie naartoe wil.

Stel bijvoorbeeld dat de organisatie de komende jaren veel bestaande applicaties wil vervangen door SaaS-diensten. Dan kan de behoefte aan eigen infrastructuur sterk veranderen. Bij een voorgenomen overname kan flexibiliteit extra belangrijk worden. En wanneer data en AI een grotere rol moeten krijgen, kunnen andere aspecten van het platform relevant worden.

Daarom hoort bij de beoordeling ook de vraag:

Helpt deze keuze ons alleen het huidige probleem op te lossen, of ondersteunt zij ook de richting waarin de organisatie zich wil ontwikkelen?

Daarvoor hoeft niet alles voor de komende vijf jaar vast te staan. Maar een belangrijke IT-beslissing zou toekomstige keuzes bij voorkeur mogelijk moeten maken in plaats van ze onnodig te beperken.

En misschien is Azure gewoon de juiste keuze

Na al deze vragen kan de conclusie heel goed zijn dat het voorstel van de IT-dienstverlener uitstekend is.

Azure kan technisch goed passen. De kosten kunnen verdedigbaar zijn. De organisatie kan profiteren van de kennis van haar bestaande dienstverlener en de oplossing kan aansluiten op de toekomstige plannen.

Een onafhankelijke beoordeling is daarom geen zoektocht naar fouten in een voorstel. Het doel is ook niet om de IT-dienstverlener tegenover de klant te zetten.

Het doel is dat een organisatie een belangrijke beslissing neemt omdat zij begrijpt waarom de voorgestelde oplossing bij haar past, welke alternatieven er zijn, welke consequenties de keuze heeft en welke risico’s zij accepteert.

Bij een beslissing die uw IT-landschap mogelijk voor vele jaren beïnvloedt, is dat een belangrijk verschil.