terug naar de referentiepagina
Gepubliceerd | 24 februari 2018

Connective, het uitbouwen van een SAAS Infrastructuur

Connective

De wens om over te stappen naar een SAAS-model confronteerde Connective met een moeilijk vraagstuk: het onderhoud van het platform outsourcen, of zelf kennis opbouwen. De overstap betekende dat het bedrijf zich veel meer zou moeten toeleggen op de operationele kant van hun platform voor digitale ondertekeningen, ten nadele van hun kernactiviteit van het ontwikkelen van de software.

In zijn case presenteert Connective hoe het dat vraagstuk succesvol heeft aangepakt. Een sterke voorbereiding en zorgvuldig onderzoek naar de mogelijkheden samen met een betrouwbare partner vormde de sleutel voor een grotere flexibiliteit en een verhoogde klantentevredenheid voor het bedrijf.

De uitdaging

1. Verschuiving van behoefte
Klassieke klanten kochten een licentie
Operationeel beheer was verantwoordelijkheid van de klant
SAAS wordt gezien als een strategische richting
Hier wordt Connective plots operationeel verantwoordelijk
Een development-omgeving is geen SAAS platform…

2. Focus

WEL

De kennis en toegevoegde waarde zit in software development
Bij voorkeur dus investeren in bijkomende ontwikkelingen
Kennis opbouwen rond nieuwe ontwikkellingen en functionele domeinen
NIET

Het runnen van infrastructuur in 2 datacenters (2FTE !)
Het runnen van een eigen mailomgeving
Oplossen probleem van retentie infrastructuur-kennis
Niet of moeilijk schaalbaar !
Evolutie richting SAAS zou dit alleen maar erger maken

3. Variabilisering van kosten

De IT kost linken aan het aantal SAAS-klanten: groeien als het goed gaat, afbouwen als het even wat minder is.
Optimalisatie van test en demo-omgevingen door gebruik te maken van pay as you use modellen.
Vermijden van stevige investeringen op voorhand op basis van ingeschatte load.
Vermijden van even stevige investeringen om de x-jaar bij het einde van de lifecycle.
Vermijden van staffing-levels op basis van peak-loads.
Niet alleen het aantal machines en de bijhorende factuur maar ook de operationele organisatie schaalt mee !

4. Gebrek aan kennis

Een SAAS-oplossing beheren vroeg kennis die niet aanwezig was op vlak van:
Service Architectuur: wat willen/kunnen we beloven aan onze klanten en hoe richten we onze organisatie daar naar in ?
IT Architectuur: hoe vertaalt zich dat naar schaalbaarheid & systemen ?
Security : de klanten verwachten een vergelijkbaar veiligheidsniveau
Transitie/transfromatie: hoe raken we van “as is” naar “to be” ?
Hoe gaan we de oplossing draaiende houden en ondersteunen ?

De afwegingen

Eigen datacenter of public cloud
Pure Housing niet langer een optie
Hosting en/of shared environment wel maar waar ?
Pay per use was belangrijk
Selectieve multi-datacenter setup was interessant (zelfs georesilientie)
Interessante autoscaling opties.
Vanuit de .Net-ontwikkelomgeving was er al affiniteit met “de cloud”, Azure in het bijzonder.
Keuze werd gemaakt voor Azure Cloud.

2. Kennis opbouwen of niet

Zo goed als niet want:

Cloud vereist geen kennis voor het runnen van een basis infra-laag.
Definieren van de doelarchitectuur kan door specialisten gebeuren
Migreren naar de doelarchitectuur idem
Blijft vooral de grijze zone tussen applicatie en infrastructuur => kennisopbouw nodig.
Dagdagelijks beheer en change management via externe partner

De resultaten

Omgeving volledig operationeel in Azure
Mailomgeving volledig overgezet naar O365
2 datacenters opgezegd.
Geen eigen infrastructuurmensen meer
Architect as a service
ROI van 16 maanden (inclusief migratietraject)