Migratie Dataplatform NS Stations

De digitale transformatie van organisaties vraagt steeds meer van hun dataplatform. Data komt uit een groeiend aantal bronnen, gebruikers verwachten sneller inzicht en dataproducten moeten flexibel kunnen meegroeien met de organisatie. Tegelijkertijd vormen bestaande systemen en legacy-oplossingen vaak een belangrijke afhankelijkheid.

Van een bestaand dataplatform naar Azure en Snowflake

Bij NS Stations zijn we betrokken bij de migratie van een bestaand dataplatform naar een nieuwe omgeving in Microsoft Azure en Snowflake.

Het bestaande landschap bestaat uit verschillende technologieën, waaronder SQL Server, Oracle en BODS. Daarbovenop draaien verschillende rapportages en dataproducten. Dat maakt een migratie al snel meer dan het verplaatsen van data van de ene omgeving naar de andere.

Voordat we zijn gaan bouwen, hebben we daarom eerst goed gekeken naar wat er stond, hoe de verschillende onderdelen met elkaar samenhangen en wat er uiteindelijk in de nieuwe omgeving nodig is.

Eerst begrijpen wat er staat

Een dataplatform dat langere tijd in gebruik is, groeit mee met de organisatie. Er komen nieuwe bronnen bij, rapportages worden aangepast en in de loop van de tijd ontstaan afhankelijkheden die niet altijd direct zichtbaar zijn.

Bij de start van een migratie wil je daarom niet alleen weten welke databases en systemen er zijn. Je wilt vooral begrijpen wat ermee gebeurt.

Welke data wordt gebruikt?
Welke processen zijn ervan afhankelijk?
Welke rapportages moeten blijven werken?
En waar zit functionaliteit die misschien beter opnieuw kan worden opgebouwd?

Dat voorwerk is een belangrijk onderdeel van de migratie. Het voorkomt dat je tijdens de bouw voor verrassingen komt te staan.

Niet alles één-op-één overzetten

Een van de dingen waar we bij een migratie altijd kritisch naar kijken, is de bestaande implementatie.

Het is verleidelijk om een bestaande oplossing zo nauwkeurig mogelijk na te bouwen in de nieuwe omgeving. Technisch gezien lijkt dat de veiligste route. Maar daarmee neem je ook de keuzes en beperkingen van de oude omgeving mee.

Dat is niet altijd nodig.

Een migratie naar de cloud is juist een goed moment om opnieuw naar de inrichting te kijken. Wat werkt nog goed? Wat kan eenvoudiger? En welke mogelijkheden biedt de nieuwe omgeving die we in de oude situatie niet hadden?

Daarom proberen we niet simpelweg een oude implementatie in een nieuw jasje te steken.

Azure en Snowflake

Voor de nieuwe omgeving wordt gebruikgemaakt van Microsoft Azure en Snowflake.

Snowflake vormt daarbij het datafundament waarop nieuwe dataproducten kunnen worden gebouwd. Azure biedt de cloudomgeving waarin de verschillende onderdelen van het dataplatform samenkomen.

De migratie gaat daarmee niet alleen over het vervangen van de bestaande techniek. We bouwen tegelijkertijd aan een omgeving waarin nieuwe dataproducten verder kunnen worden ontwikkeld.

Dat betekent dat we tijdens de migratie steeds twee dingen in de gaten houden: wat moet vanuit de bestaande situatie worden behouden en hoe willen we dat het platform er straks uit gaat zien?

Accelerators

Bij een migratie van deze omvang kom je regelmatig dezelfde werkzaamheden tegen. Als je die iedere keer opnieuw uitvoert, kost dat onnodig veel tijd. Daarom maken we gebruik van accelerators. Dat kunnen bijvoorbeeld scripts, templates of andere technische bouwstenen zijn waarmee terugkerende werkzaamheden sneller kunnen worden uitgevoerd. Het voordeel zit niet alleen in snelheid. Door werkzaamheden op een vaste manier uit te voeren, wordt het ook makkelijker om consistent te werken.

Natuurlijk blijft iedere migratie anders. Een accelerator is geen vervanging voor nadenken over de specifieke situatie. Het is vooral een manier om het werk dat wél herhaalbaar is, niet steeds opnieuw te hoeven uitvinden.

Back-end en front-end

Binnen de migratie zijn verschillende werkzaamheden van elkaar afhankelijk. Aan de ene kant wordt gewerkt aan de back-end van het dataplatform: databronnen, verwerking, transformaties en het datafundament.

Aan de andere kant zijn er de rapportages en andere toepassingen waarmee gebruikers uiteindelijk met de data werken. Waar het kan, kunnen deze werkzaamheden naast elkaar plaatsvinden. Dat vraagt wel om goede afstemming. Wanneer er bijvoorbeeld iets verandert in de manier waarop data wordt aangeleverd of gemodelleerd, kan dat gevolgen hebben voor een rapportage. Daarom kijken we niet alleen naar de technische migratie zelf, maar ook naar wat de gebruiker uiteindelijk ziet.

Reporting is onderdeel van de migratie

Een dataplatform is voor de meeste gebruikers geen doel op zich. Zij willen informatie kunnen vinden en rapportages kunnen gebruiken.

Wanneer reportingtools veranderen, verandert daarmee ook een deel van de gebruikerservaring. Dat betekent dat we bij een migratie niet alleen kijken naar de vraag of de data technisch goed is overgezet. We kijken ook naar de rapportages en naar de manier waarop gebruikers met de nieuwe omgeving gaan werken. Daar hoort begeleiding bij.

Een nieuwe omgeving kan technisch heel goed zijn, maar als gebruikers niet weten hoe ze ermee moeten werken, heb je het probleem niet opgelost.

Een replica van de legacy-omgeving

Een van de manieren om de overgang beheersbaar te houden, is het maken van een replica van de legacy-omgeving. Die omgeving kan worden gebruikt als schaduwomgeving. Bestaande rapportages kunnen daar worden nagebouwd of opnieuw worden ontworpen voordat de overgang naar de nieuwe situatie volledig wordt gemaakt. Dat geeft ruimte om te vergelijken. Werkt het nieuwe rapport hetzelfde? Klopt de informatie? Zijn er verschillen die verklaard moeten worden? Op die manier kun je de nieuwe omgeving ontwikkelen zonder direct alles aan de bestaande productieomgeving op te hangen.

Het geeft ook gebruikers de mogelijkheid om geleidelijk kennis te maken met de nieuwe manier van werken.

De gebruiker meenemen

Een migratie is uiteindelijk niet alleen een technisch project. De mensen die dagelijks met de data werken, moeten mee kunnen in de verandering. Dat geldt zeker wanneer rapportages of tools veranderen. Daarom kijken we ook naar adoptie en self-service.

Als gebruikers zelf bepaalde zaken kunnen vinden of regelen, hoeft niet iedere vraag bij een data-engineer of beheerder terecht te komen. Dat maakt de nieuwe omgeving niet alleen technisch anders, maar kan ook de manier waarop mensen met data werken veranderen.

Dat vraagt wel om goede ondersteuning en duidelijke afspraken.

Geen technische verhuizing, maar opnieuw kijken

Wat deze migratie interessant maakt, is dat het niet alleen gaat om het vervangen van SQL Server, Oracle en BODS door een nieuwe cloudomgeving. De migratie is ook een moment om opnieuw naar het dataplatform te kijken.

Welke onderdelen moeten mee?
Welke onderdelen kunnen anders?
Waar kunnen we standaardiseren?
Waar kunnen we automatiseren?
En hoe zorgen we ervoor dat het nieuwe platform niet dezelfde complexiteit opbouwt als de omgeving die we nu aan het vervangen zijn?

Dat zijn uiteindelijk belangrijkere vragen dan alleen de vraag welke technologie we gebruiken.

Wat we hiervan meenemen

Bij een dataplatformmigratie is de techniek natuurlijk belangrijk. Maar minstens zo belangrijk is het begrijpen van de omgeving die je gaat veranderen.

Voor ons betekent dat:

• eerst goed in kaart brengen wat er staat;
• afhankelijkheden begrijpen;
• niet automatisch alles één-op-één overzetten;
• waar mogelijk standaardiseren en automatiseren;
• back-end en reporting goed op elkaar afstemmen;
• gebruikers meenemen in de verandering;
• en de nieuwe omgeving zo ontwerpen dat die ook op langere termijn beheersbaar blijft.

De overstap naar Azure en Snowflake is daarmee niet alleen een technische migratie. Het is vooral een moment om opnieuw te bepalen hoe het dataplatform moet werken.

En dat is eigenlijk het interessante aan dit soort projecten: je begint met een bestaande omgeving, maar je hoeft niet te eindigen met een kopie daarvan.