5 Belangrijke lessen over datamigratie die je moet weten

Het migreren van gegevens van een legacy, on-premise omgeving naar de cloud is een van de grootste uitdagingen van een bedrijf. De bedrijfsgegevens staan verdeeld over verschillende omgevingen, zo is de data ook zelden vrij van gebreken. Net als hoe we soms niet herkennen of een sleutel ergens in past, zijn er ook bepaalde data sets waarvan we niet zeker weten of deze belangrijk zijn. Maar wat we ook niet weten is waar je deze data dan zou kunnen neerzetten. Gegevensophoping, domeintoewijzing en migratieprojecten zijn vaak langdradig van duur. Dus hoe worden deze problemen opgelost?

Het sleutelconcept is hier het omgaan met big data zelf, het probleem oplossen in kleine stukjes.

In deze blog bespreken we het proces van het beheren van een data migratieproject, waar op gelet moet worden en wat weggegooid moet worden in het belang van het bereiken van de algemene doelen.

Wat is datamigratie?

Een datamigratie komt in een paar verschillende vormen: het verplaatsen van een on-premise data warehouse naar de cloud, het verplaatsen van applicaties en de bijbehorende data en het samenbrengen van data in een data-mesh aanpak.

Een enterprise data migratieproject wordt vaak geactiveerd door een of meer van deze drie pijnpunten:

1. Snelheid: Het bedrijf heeft het gevoel dat het achterloopt – of dreigt achter te lopen – achter haar concurrenten omdat haar belangrijkste gegevens begraven liggen in legacy-systemen, waardoor het traag of onmogelijk is om analyses uit te voeren of om nieuwe data centrische producten in hoog tempo aan zijn klanten aan te bieden.

2. Kosten: De IT-infrastructuur is ondergebracht in een on-premise data center, die een eigen roadmap heeft om zijn voetafdruk te verkleinen. Dit betekent dat er applicaties of documenten moeten worden verwijderd.

3. Toegang: De gegevens zijn op zoveel plaatsen opgenomen, dat het eenvoudigweg niet praktisch is om ze samen te voegen voor analyses of om een enkele bron van waarheid voor belangrijke gegevens te identificeren. Het beheren van de toegang tot gevoelige gegevens is tijdrovend.

Je herkent misschien enkele van de volgende typische oplossingen voor deze problemen die we regelmatig zien wanneer we het hebben over datamigratie met klanten: data-warehousing, data-marts, replatforming, API’s, cloud migraties, master data management (MDM), applicatieherschrijvingen, change data capture (CDC), data mesh, domeinmodellering.

Elk van deze heeft zijn plaats, maar onthoud altijd dat het niet is wat als oplossing geïmplementeerd wordt dat telt – het is hoe je het aanpakt die je datamigratie tot een succes of een faalproject maakt.

4 Voordelen van het migreren van gegevens

Enkele voor de hand liggende en enkele minder voor de hand liggende voordelen die we zien als het gevolg van de gegevensmigraties voor anderen:

1. Snelheid: het opschonen van data, software en processen maakt je flexibeler en sneller om te reageren.

2. Het verlagen van de vaste kosten: het achterlaten van datacenters en het verwijderen van onnodige licenties verandert de manier waarop er betaald wordt voor gegevens en technologie, wat resulteert in besparingen op dat specifieke budget voor vaste kosten.

3. Talent: het is ook gewoon gemakkelijker om mensen te vinden die de moderne technologieën zoals Python, NodeJS, Spark, Scala en cloud computing-technologieën kennen of kunnen oppikken, die gebruikelijk zijn in data migratiestacks, in plaats van te proberen teams op te schalen die legacy-code ondersteunen.

4. Nieuwe vragen beantwoorden: traditionele op rijen gebaseerde relationele gegevens zijn erg snel voor het bedienen van de applicaties waar het achter zit, maar zijn veel minder geschikt om complexe analyses in combinatie met andere gegevens te ondersteunen.

Nu kan je denken, dit is een best korte lijst, dat klopt! Onderschat echter niet wat een data migratie voor je bedrijf kan betekenen.

Zo hebben we ook een aantal redenen als drijvende kracht achter de data migratie. We zien vaak dat dit redenen zijn om een data migratieproject te beginnen, maar vaak niet voldoende gekwantificeerd zijn om de echte voordelen te benutten.

1. De gebruikte legacy-systemen zijn te traag om nieuwe functies te bieden

2. De bestaande systemen zitten vol bugs

3. Het datacenter/ centrale infrastructuurteam reageert te weinig op snel veranderende zakelijke behoeften

4. De gegevens moeten worden gestandaardiseerd in verschillende legacy-systemen.

5. We hebben één bron van waarheid nodig voor een klant / merk / asset

6. Het bedrijf moet ML en AI gebruiken

7. De data zit allemaal in silo's

8. Ze willen omgaan met streaming data

9. Er is geen concept van een domein in de gegevens

Sommige hiervan zijn nobele doelen op zich, maar probeer de zakelijke waarde van deze initiatieven te bereiken voordat er tijd en moeite aan besteedt wordt.

5 lessen uit meer dan 20 jaar datamigratie

1. Legacy-gegevens zijn altijd besmet. Je hoeft het niet allemaal schoon te maken!

We kunnen met grote zekerheid voorspellen dat de meesten van jullie de afgelopen jaren een datamigratie hebben uitgevoerd. Dit komt niet alleen dat je door dit artikel te lezen om meer over SaaS te weten komen, maar ook omdat je waarschijnlijk je mobiele telefoon in die periode al hebt aangepast.

Wat is het eerste dat gebeurt na het uitpakken van een nieuwe telefoon? Op zijn minst synchroniseren we onze contacten van de oude telefoon, evenals foto's, e-mailinstellingen, browserbladwijzers, apps, enzovoort. Dit is vandaag de dag eenvoudig, maar weet je nog toen het niet zo was?

Een paar jaar geleden betekende de overstap naar een nieuwe telefoon het importeren van contacten van de simkaart en ook veel handmatig kopiëren van andere contacten en dingen zoals instellingen. Tijdrovend en vervelend? Ja, maar ook een beetje louterend, want dat betekende natuurlijk het opschonen van de gegevens onderweg - dat telefoonnummer voor Dave Plumber of de IT-helpdesk op die plek waar ik werkte? Je hoeft geen tijd te verspillen aan het kopiëren ervan! En dus werden de gegevens in de migratie naar een glimmende nieuwe Nokia 7650 onderweg opgeschoond.

Vandaag hebben we contacten waar je nooit meer gebruik van zal maken, maar raad eens? Het maakt niet uit. Datamigraties naar een nieuwe telefoon zijn tegenwoordig beter, ook al heb je niet alle gegevens opgeschoond. Ze zijn beter omdat ze snel en wrijvingsloos zijn, en dat is waardevoller dan een perfecte dataset.

Nu is het gemakkelijk om dit af te ronden in een alledaagse anekdote die dit punt bewijst, maar laten we dit ook in context plaatsen.

Gegevens die zijn gemaakt door en bewaard in legacy-systemen - soms het resultaat van fusies en overnames door de jaren heen - die stapsgewijs worden aangevuld door talloze applicatie-updates en vaak nauw worden gekoppeld aan bedrijfslogica en applicatielogica, zijn nooit “schoon”.

Dit is belangrijk om te begrijpen: legacy data is altijd besmet.

In de meer dan 20 jaar dat we gegevens van de ene plaats naar de andere hebben gemigreerd, hebben we gewerkt aan een breed scala aan gegevensmigraties met verschillende niveaus van gegevensschoonheid.

Voorbeelden van "Vervuilde Data"

1. Een eigen database waar tabellen alleen rijen bevatten: het schema om de rij-inhoud te parseren was ingebouwd in de toepassing, overal, inclusief de gegevensinvoerschermen, en verschillende modules binnen de toepassing zouden een ander schema gebruiken, wat betekent dat gegevens in aangrenzende rijen verschillende lay-outs zouden volgen. Hoe gemakkelijk is het om gegevens uit dergelijke tabellen te lezen?

2. Een database die wordt gedeeld door verschillende producten in dezelfde toepassing: het wijzigen van de tabelhandtekening, d.w.z. het schema, betekende dat alles opnieuw moest worden gecompileerd. De belangrijkste tabellen voor gegevens zoals klant en transacties konden eenvoudigweg niet worden gewijzigd zonder grote verstoring, dus raad eens wat de tijdelijke oplossing was? Dat klopt, veel reservevelden (letterlijk Spare Field 1, Spare Int 26, Spare Flag 6, etc)! Maar de verschillende producten die de database gebruikten, hadden verschillende toepassingen voor die reservevelden. De enige manier om te vertellen wat ze waren, zou zijn om door de applicatiecode te bladeren.

3. Een instantie per klant van een applicatie, met configureerbaar gebruik van de database: elke klant had effectief een ander databaseschema binnen dezelfde applicatie.

4. Een door de leverancier aangeleverd dagelijks gegevensextract dat met terugwerkende kracht van schema zou veranderen: gegevens die gisteren zijn geladen, kunnen opnieuw worden verzonden met verschillende kolommen.

5. Om nog maar te zwijgen van de eenvoudige oude problemen met de gegevenskwaliteit: de klant die het aandurfde om driecijferige leeftijd te hebben in een tabel die er maar twee toestond; de klantadressen met backslashes, komma's, elk speciaal teken dat je maar kunt bedenken; de vergeefse pogingen om alle mogelijke titels op te sommen die een persoon zou verwachten op zijn correspondentie te staan; de kolommen gevuld met ongeldige datums; Amerikaanse versus Europese datumnotaties...

Elk van deze heeft aanzienlijke uitdagingen met zich meegebracht als het gaat om het openen of migreren van die gegevens buiten de oorspronkelijke toepassing.

Het opschonen van de meeste van deze datasets aan de bron zou die systemen breken, gezien het zeer begrijpelijke feit dat de applicaties die het gebruiken zijn gebouwd rond de status van de gegevens. Maak je dus geen zorgen over het opschonen van al je gegevens - soms is het gewoon niet mogelijk.

2. Je hebt niet al je gegevens nodig om de boel draaiende te houden

Dus wat doen we met de gegevens in dit soort toestanden? Het antwoord is om je te concentreren op wat zinvolle gegevens zijn. Neem in ieder geval "Spare Field 6" en de waarde van '3' of 'S' mee wanneer je de gegevens migreert, maar als je deze niet nodig hebt om je doelen te bereiken, is het goed om ze achter te laten.

De eenvoudigste manier om sneller bij je doelen te komen, is door minder te doen op de heenweg en prioriteit te geven aan de gegevens die je nodig hebt om minder tijd te besteden aan het migreren ervan.

De doorbraak om gegevens uit het systeem te halen waar elke klant een ander databaseschema had, was om zich eenvoudiger weg te concentreren op het absolute minimum aan belangrijke gegevensvelden die nodig ware.

Wat van cruciaal belang is, zijn de huidige contactgegevens van de omgeving en de huidige garantiestatus. Het accepteren van de ingekorte dataset betekende dat het probleem kon worden vereenvoudigd. Dit betekende minder velden om je zorgen over te maken en omdat het meestal centrale delen van de database zijn, was het aandeel velden dat door de klant was aangepast lager.

Belangrijke vragen om te beantwoorden voordat je begint:

1. Welke gegevens heb je nodig om je doelen te bereiken?

2. Welke gegevens kun je achterlaten (dit kan voor nu of voor altijd zijn)

3. En cruciaal, wat zijn de doelen van het verplaatsen van deze gegevens? Vergeet niet dat dit een zakelijke drijfveer heeft - het is geen technologische beslissing.

3. Niet alle gegevens zijn gelijk

We bewaren onze wachtwoorden veilig met een wachtwoordmanager en onze paspoorten op een veilige plek, maar iedereen kan ons arbeidsverleden zien op LinkedIn. Dit zijn allemaal persoonlijke gegevens, maar worden afhankelijk van het type, toch anders behandeld. Evenzo, komen succesvolle migraties van bedrijfsgegevens voor uit inzicht in hoe verschillende soorten gegevens behandeld moeten worden.

Informatie die is opgedoken voor klanten van je bedrijf, misschien ingrediënten in het voedsel die je verkoopt, is van vitaal belang om goed te krijgen. De interne werkgeschiedenis van je werknemers is misschien minder. Dus richt de inspanningen op de juiste manier: zorg ervoor dat die ingrediëntenlijsten schoon en up-to-date zijn en besteed tijd aan het verifiëren hiervan, maar misschien kun je de werknemersgeschiedenis in bulk kopiëren als ongestructureerde gegevens. Het is op een bepaald moment in de toekomst beschikbaar voor analyses, maar je hebt geen kostbare tijd gebruikt om het er perfect uit te laten zien op het migratiepunt.

4. Kies voor een iteratieve aanpak

Datamigratieprojecten trekken een watervalleveringsmentaliteit aan, misschien omdat ze relatief duidelijke begin- en eindpunten kunnen hebben en vaak gaan over het oplossen van een bekende reeks problemen. Dit leidt tot grote werkprogramma's, die het platgetreden pad van data-eigendom volgen > het opschonen > domeinmodellering > MDM-> replatforming. Maar het zijn deze traditionele stappen die leiden tot een moeras van eindeloze data-analyse.

Hoe maak je van een watervalproject een flexibel werkproces:

1. Focus op de waarde die het project wil leveren

2. Begrijp de betrokken use cases en kies er een om aan te werken

3. Introduceer een cultuur van experimenteren

4. Maak van deze ene use case uw Lighthouse-project

Voorbeeld klant A

Een klant met wie we werkten, was betrokken bij een meerjarig project om naar de cloud te gaan, met een up-front architectuur voor data governance, tracking lineage en data science segregatie van activiteiten tussen afdelingen. Ze waren zeer grondig in het ontwerp, maar diep verstrikt in analyse en zorgen over het opschonen van gegevens. Twaalf maanden later was deze onderneming nog steeds aan het ontwerpen en had ze geen echte data-inzichten klaar voor zakelijke consumptie.

Voorbeeld Client B

Een andere klant zette een cloud-first strategie op hoog niveau uit en begon vanaf het begin met het onboarden van data use cases. Ze gebruikten enkele Jupyter-notebooks en ontwikkelden in de loop van de tijd steeds meer functies, naarmate er meer use cases werden geïntroduceerd.

Twaalf maanden later had deze onderneming de bèta van een cloud data science en analytics platform al resultaten opgeleverd voor haar interne klanten.

Keer op keer zien we dat de iteratieve aanpak sneller waarde krijgt voor je zakelijke sponsors en gebruikers en je in staat stelt om ideeën en functies te laten vallen die geen waarde toevoegen, maar waarmee je nog steeds een algemene strategie kunt volgen en fantastische kwaliteit en beveiliging in je oplossingen kunt bouwen, en dit is waar we bij Like-IT beroemd om zijn.

5. Afscheid nemen is moeilijk

Ik ga het opnieuw hebben over het begrijpen van de bedrijfswaarde van het project. Zo belangrijk is het. Als de migratie een replatforming-element heeft en als de waarde voor het bedrijf gedeeltelijk de kostenbesparingen is bij het weggaan van legacy-systemen, dan is er één belangrijk ding dat moet gebeuren om die waarde te realiseren. Wees moedig.

Schakel het oude systeem uit, schakel die servers uit, verleng de licenties niet. Deze worden beschouwd als significante voordelen en drijfveren, of op zijn minst zijn mitigaties voor de kosten van migratie. En toch, met uitzondering van één investeringsbank, vinden bedrijven waarmee ik heb gewerkt dit het moeilijkste deel.

Maar er is hier een vraag om te beantwoorden: hoe creëer je een legacy-systeem elders?

Legacy is een makkelijke term om te gebruiken, maar we hebben het niet over een oude spijkerbroek die we meteen kunnen vervangen. Legacy software en databases betekenen eigenlijk jaren - waarschijnlijk tientallen jaren - van functierijke ontwikkeling, van op maat gemaakt ontwerp, van klantaanpassingen en gerichte BI, van integraties met andere systemen, leveranciers, klanten, enz. Dus hoe migreer je dit allemaal?

Het antwoord is natuurlijk dat je dat niet kunt, en je kunt niet verwachten dat je project de uitzondering zal zijn. Om de efficiëntie van het herontwerpen van hoe je met gegevens werkt te vergroten, moeten moeilijke beslissingen over wat er bij je komt en waar je afscheid van neemt, van tevoren worden genomen.

Het bereiken van overeenstemming over een grote uitschakeling, waarbij sommige partijen natuurlijk teleurgesteld zullen zijn, is een moeizame oefening. Daarom heeft je complexe data migratieproject steun van bovenaf nodig die deze gesprekken tot een goed einde brengt.

In het kort

Een datamigratie alleen lost de problemen van je bedrijf niet op. Door je te concentreren op deze belangrijke afhaalmaaltijden, kun je optimaal gebruik maken van een migratie en de beste waarde bieden aan je bedrijf:

1. Begrijp de business drivers echt

2. Zorg ervoor dat je echte executive sponsoring hebt om die bedrijfspolitiek glad te strijken

3. Laat gegevens achter als dit past binnen jouw situatie

4. Reinig de gegevens die je absoluut moet hebben, laat de rest zo stinkend als het komt

5. Pas op voor niet-gekwantificeerde logica die beslissingen zoals data standaardisatieprogramma's stuurt

6. Neig naar het beantwoorden van nieuwe vragen in plaats van het opnieuw opbouwen van wat je al hebt

7. Begin klein en schaal geleidelijk op

8. Wees moedig in het uitschakelen van wat je hebt vervangen

9. En vergeet niet dat snelheid wint

Wat is jouw mening? Ziet je succesvolle datamigraties werken met enkele van de elementen die wij voorgesteld hebben om te verwijderen, of worstel je op dit moment midden in een stagnerende migratie? Neem contact op!