Credits : deze blog is een vrije vertaling van de zeven pilaren van DataOps zoals die gedefinieerd wordt op truedataops.org en een interpretatie van de paper Getting DataOps Right van O’Reilly Media. Vertaling door https://www.deepl.com
Fundamentele veranderingen zoals de invoering van DevOps worden meestal omarmd door grote ondernemingen nadat nieuwe technologieën zijn gerijpt tot een punt waarop de voordelen breed worden begrepen, de kosten en de lock-in van legacy / gevestigde leveranciers ondraaglijk worden, en standaarden ontstaan door een kritische massa van adoptie.
We zijn getuige van het begin van een andere fundamentele verandering in enterprise tech genaamd “DataOps” – die ondernemingen in staat zal stellen om snel en herhaaldelijk “mission-ready” data te ontwikkelen uit alle data bronnen binnen een onderneming.
Net als DevOps in de onderneming, lijkt de opkomst van enterprise DataOps op de praktijk van modern datamanagement bij grote internetbedrijven in de afgelopen 10 jaar.
Werknemers van grote internetbedrijven gebruiken de gegevens van hun bedrijf als een strategisch bedrijfsbezit, en leiders in traditionele bedrijven hebben recentelijk dezelfde aandacht ontwikkeld om concurrentievoordeel te halen uit data.
De behoefte aan DataOps komt voort uit het feit dat de consumptie van data de afgelopen tien jaar dramatisch is veranderd. Net zoals internetapplicaties de verwachtingen van gebruikers over de bruikbaarheid, beschikbaarheid en reactiesnelheid van applicaties hebben verhoogd, hebben zaken als Google Knowledge Panel en Wikipedia de verwachtingen van gebruikers over de bruikbaarheid, beschikbaarheid en actualiteit van data drastisch verhoogd.
Het uiteindelijke doel is om kosteneffectief tijdige gegevens van hoge kwaliteit te leveren die voldoen aan de steeds veranderende behoeften van de organisatie.
Vanwege gedragsnormen, zoals het lokaal hamsteren van gegevens in de vele sub-koninkrijkjes binnen afdelingen van de organisatie
Omdat ze achterlopen in hun technische mogelijkheden zitten vaak vast aan omslachtige extract, transform, and load processen en legacy master data management systemen.
De noodzaak van DataOps is ontstaan toen individuen in grote traditionele ondernemingen zich realiseerden dat zij alle gegevens die in hun bedrijf worden gegenereerd als een strategische troef zouden moeten gebruiken om elke dag betere beslissingen te nemen.
Uiteindelijk gaat DataOps evenzeer over het veranderen van de relatie van mensen tot gegevens als over de technologische infrastructuur en processen.
Het engineering framework dat DevOps heeft gecreëerd is een goede voorbereiding voor DataOps. Voor de meeste ondernemingen zal de levering van hoogwaardige, uitgebreide en vertrouwde analyses met behulp van gegevens over vele silo’s hen in staat stellen om snel te concurreren in de komende 20 jaar.
Net zoals de internetbedrijven DevOps nodig hadden om een hoogwaardig, consistent raamwerk voor feature-ontwikkeling te bieden, hebben ondernemingen een hoogwaardig, consistent raamwerk nodig voor snelle data-engineering en analytische ontwikkeling.
DataOps is het logische gevolg van drie belangrijke trends in de onderneming:
Dataschuld is een natuurlijk gevolg van de manier waarop bedrijven zaken doen. Bedrijven willen controle over en snelle toegang tot hun bedrijfskritische gegevens, dus schaffen ze hun eigen applicaties aan, waardoor datasilo’s ontstaan.
Door hun data-infrastructuur van de grond af aan op te bouwen met legioenen getalenteerde technici, hebben digital-native, datagestuurde bedrijven als Facebook, Amazon, Netflix en Google een dataschuld vermeden door hun data vanaf de eerste dag als een bedrijfsmiddel te beheren.
Hun voorbeelden van het behandelen van data als een concurrerend bedrijfsmiddel hebben een model opgeleverd voor slimme leiders van traditionele bedrijven die zich bezighouden met digitale transformatie terwijl ze te maken hebben met een enorme legacy data debt.
Deze leiders begrijpen nu dat het proactief beheren van hun data als een bedrijfsmiddel de eerste, fundamentele stap is voor hun digitale transformatie – het kan geen “leuk extraatje” zijn dat wordt aangestuurd door corporate IT.
DataOps komt, net als DevOps, voort uit de erkenning dat het scheiden van het product – productieklare data – en het proces dat deze levert – operations – de kwaliteit, tijdigheid, transparantie en wendbaarheid belemmert.
De behoefte aan DataOps komt voort uit het feit dat de consumptie van data de afgelopen tien jaar dramatisch is veranderd. Net zoals internetapplicaties de verwachtingen van gebruikers over de bruikbaarheid, beschikbaarheid en reactiesnelheid van applicaties hebben verhoogd, hebben zaken als Google Knowledge Panel en Wikipedia de verwachtingen van gebruikers over de bruikbaarheid, beschikbaarheid en actualiteit van data drastisch verhoogd.
Het uiteindelijke doel is om kosteneffectief tijdige gegevens van hoge kwaliteit te leveren die voldoen aan de steeds veranderende behoeften van de organisatie.
Extract, load, transform (ELT), (een alternatief voor het traditionele extract, transform, load -ETL) biedt verschillende voordelen wanneer het wordt gebruikt bij data lake-implementaties. Waar ETL gegevens transformeert voordat ze het meer binnenkomen, slaan ELT-modellen informatie op in het oorspronkelijke ruwe formaat. Dit zorgt voor snellere laadtijden tijdens analytische bewerkingen. En omdat de gegevens niet worden verwerkt bij binnenkomst in het data lake, hoeven de query en het schema niet van tevoren te worden gedefinieerd. Op het meest basale niveau is ELT een datapijplijnmodel dat “lift and shift met minimale wijzigingen” biedt – maar het is meer dan dat. Door gegevens te laden vóór de transformatie gaan geen details verloren. Deze aanpak maximaliseert het toekomstige potentieel voor gegevensverwerking en -analyse door geen informatie weg te gooien.
Het implementeren van een nieuwe gegevensbron kan zeer kostbaar zijn, dus is het belangrijk dit één keer en slechts één keer te doen. Dit kan betekenen dat we gegevens laden terwijl we niet weten wat we ermee gaan doen. Door ons te richten op ELT, halen we de energie uit het proces door alles te laden in het formaat dat beschikbaar is.
ELT ondersteunt ook de principes van data governance, data auditability en data lineage, omdat de informatie die in het data lake of data warehouse wordt opgenomen, bijna exact hetzelfde is als de informatie die eruit is gehaald, met geen of vrijwel geen wijzigingen. Inzicht in de herkomst en betrouwbaarheid van gegevens die uit deze opgenomen gegevens zijn afgeleid, is daarom veel eenvoudiger. In situaties waarin er “bijna geen wijzigingen” zijn, moet een ELT-model een EtLT-model zijn; de kleine “t” weerspiegelt de bedrijfs- of regelgevingsbehoefte om bepaalde beveiligde of PII-gegevens te weigeren, of de noodzaak om gegevens te versluieren of te hashen voordat ze worden overgedragen of geladen naar een downstreamsysteem.
We doen dit al de hele tijd – denk aan deze databasetabel: Werknemer ID, Werknemer Naam, Salaris, Functie Titel. Als we de tabel een week later opnieuw laden, ziet hij er precies hetzelfde uit, wat allemaal heel normaal is. Maar we hebben ook informatie verloren, niet door het transformeren in de vlucht zoals ETL, maar door het overschrijven van waardevolle gegevens; meer bepaald hebben we alle registratie van de oude waarden en dus de geschiedenis verloren. De “Spirit of ELT” gaat verder met het concept van ELT en pleit ervoor dat wij ALLE acties vermijden die gegevens verwijderen die later nuttig of waardevol kunnen zijn voor iemand, met inbegrip van wijzigingen in gegevens. Dit is een goed begrepen probleem, waarvoor goed begrepen oplossingen bestaan, maar die zijn tijdrovend en duur – om ze overal te kunnen gebruiken, moeten we de kosten van configuratie en implementatie triviaal laag maken.
Continuous Integration Continuous Delivery in de wereld van ontwikkeling is de praktijk van het regelmatig integreren van nieuwe of veranderde code met de bestaande centrale code repository, het bouwen en testen ervan en het in een positie hebben om op verzoek te deployen (de CD kan ook staan voor Continuous Deployment waarbij het op dit punt automatisch naar productie wordt gepushed). Onder DataOps zouden integraties frequent genoeg moeten plaatsvinden dat er weinig tijd zit tussen commit en build, en zodanig dat er geen fouten kunnen optreden zonder dat ontwikkelaars ze opmerken en onmiddellijk corrigeren.
Om deze doelstellingen te bereiken, vertrouwt continue integratie op het gebruik van een versie controlesysteem en takken om de broncode van het project te beheren. Alle artefacten die nodig zijn om het project te bouwen, moeten in deze repository worden geplaatst. In deze praktijk en in de versiecontrole gemeenschap dicteert de conventie dat het systeem moet kunnen worden gebouwd vanaf een nieuwe checkout zonder dat er extra afhankelijkheden nodig zijn.
In de nieuwe wereld van data ontwikkeling, moeten alle logica en taken die worden uitgevoerd op de data als onderdeel van een totale pijplijn (of pijplijnen) worden behandeld als een enkele code basis. Dezelfde principes van beheer en governance worden ook toegepast.
Hoewel DataOps ook begon als een set van best practices, ontwikkelt het zich tot een onafhankelijke benadering van data lifecycle management. DataOps is van toepassing op de gehele levenscyclus – van integratie met modelgeneratie, orkestratie en implementatie, tot gezondheid, diagnostiek, governance en business metrics.
Vergelijkbaar met DevOps code ontwikkeling, begint prototyping met een nieuwe tak – inclusief data. Belangrijk is dat prototyping kan plaatsvinden binnen hetzelfde systeem met continue verbeteringen die worden aangebracht totdat het klaar is om live te gaan. De mogelijkheid om te vertakken zal u helpen te ontsnappen aan de traditionele waterval aanpak die een definitief bedrijfsdoel vereist voordat de ontwikkeling kan beginnen. In plaats daarvan kunt u een algemeen doel nemen, een nieuwe tak creëren (die configuratie, code EN data bevat, d.w.z. een volledig op zichzelf staande en complete sandbox). U kunt dan een eerste versie bouwen en blijven itereren en testen totdat u voldoet aan de (soms vage!) eisen van de stakeholder zonder de data integriteit of kwaliteit in gevaar te brengen.
DataOps streeft er ook naar het beheer van de levenscyclus van data te stroomlijnen – of zelfs volledig onzichtbaar te maken. Door bijvoorbeeld te kiezen voor het Snowflake Cloud Data Platform wordt data lifecycle management overbodig. Niet alleen worden gegevens automatisch gecomprimeerd, maar het platform wordt ook gebouwd op AWS S3, Google Cloud storage of Azure blob-technologieën, de goedkoopste opslagopties die momenteel beschikbaar zijn. Alle cloud data platforms zullen de komende jaren dit ontwerp patroon volgen, waardoor omgevingsbeheer naadloos en data lifecycle management feitelijk overbodig wordt.
Cloud computing technologieën stellen (theoretisch) oneindige middelen ter beschikking van uw ontwikkelaars. Door gebruik te maken van deze toename in rekenkracht, verlegt DataOps de aandacht van CPU-tijd naar ontwikkelaarsproductiviteit.
Uiteindelijk betaal je hetzelfde voor CPU cycles – je beslist alleen of code sneller of langzamer draait. Het voortijdig optimaliseren van code is een rem op de tijd van je ontwikkelaars, omdat het aantal stakeholder wijzigingen dat ze kunnen verwerken vermindert.
In engineering is onderhoudbaarheid het gemak waarmee een product kan worden onderhouden om de downtime of impact voor de eindgebruiker te minimaliseren. Er zijn principes van component- of code ontwerp die in de loop van vele jaren zijn ontwikkeld en verfijnd, waardoor een code basis beter onderhoudbaar en robuuster wordt voor de lange termijn. Neem enkele van Eric Raymond’s regels uit The Art of Unix Programming, bijna 20 jaar geleden gepubliceerd, maar nog steeds het baanbrekende werk op dit gebied, die suggereren dat onderhoudbaarheid kan worden verbeterd door:
– Modulaire programma’s te bouwen
– Leesbare programma’s te schrijven
– Compositie te gebruiken
– Eenvoudige programma’s te schrijven
– Kleine programma’s schrijven
– Schrijven van transparante programma’s
– Schrijven van robuuste programma’s
– Bouwen op de verwachte kennis van potentiële gebruikers
– Onnodige uitvoer vermijden
– Programma’s schrijven die falen op een manier die gemakkelijk te diagnosticeren is
– Tijd van ontwikkelaars belangrijker vinden dan machinetijd
– Abstracte programma’s schrijven die code genereren in plaats van code met de hand te schrijven
– Prototyping van software alvorens het te polijsten
– Flexibele en open programma’s schrijven
– Het programma en de protocollen uitbreidbaar maken.
Of het nu gaat om “programma’s” zoals het toen was, of “componenten” zoals het nu is, deze principes zijn zo waardevol.
De DataOps filosofie geeft de voorkeur aan kleine, atomaire stukjes code die snel en gemakkelijk kunnen worden hergebruikt om de totale prototyping en ontwikkelingstijd te verkorten. Componenten in feite. Door waar mogelijk configuratie boven code te verkiezen, overal elders low-code te kiezen en code te reduceren tot kleine, herbruikbare componenten, wordt het eenvoudiger om delen te verfijnen, te optimaliseren en te vervangen zonder de eindgebruikerservaring te beïnvloeden.
Omgevingsbeheer is een van de meest complexe elementen van DataOps. Organisaties die aan webontwikkeling doen hebben niet alleen meerdere langlevende omgevingen gekraakt (zoals PROD, QA, DEV) maar ook het dynamisch spinnen van meerdere omgevingen voor specifieke doeleinden. Deze “feature branches” stellen een individuele engineer in staat om zijn eigen volledige integratietests te doen. Ze maken gebruik van technologieën zoals Kubernetes, waar het creëren van een nieuwe omgeving om een specifieke versie van code te draaien in enkele seconden kan gebeuren. Typische dataomgevingen zijn hier nog ver van verwijderd; zelfs de meest geavanceerde organisaties hebben zelden meer dan 2 of 3 handmatig gecreëerde omgevingen met een lange levensduur. Deze organisaties besteden meestal onevenredig veel tijd aan het beheren van hoe ze van elkaar verschillen, omdat ze handmatig worden aangemaakt en bijgewerkt en dus snel uiteenlopen.
Goed omgevingsbeheer voor DataOps vereist dat alle omgevingen automatisch worden gebouwd, gewijzigd en (waar relevant) vernietigd. Het vereist ook iets dat niet echt relevant is in de webwereld: een snelle manier om een nieuwe omgeving er net zo uit te laten zien als Productie. Dit kan de duplicatie van TB aan gegevens inhouden.
Het Snowflake-dataplatform is bijvoorbeeld een van de enige cloud-dataplatforms die onderliggende mogelijkheden bieden (zoals Zero Copy Cloning) die vandaag DataOps omgevingsbeheerfaciliteiten mogelijk maken. Maar velen zullen volgen. Cloud-dataplatforms met deze unieke mogelijkheden zouden voor data analytics kunnen doen wat Kubernetes heeft gedaan voor microservices.
Op de juiste manier uitgevoerd, is goed geautomatiseerd omgevingsbeheer niet alleen een enorme stap vooruit voor de ontwikkeling van het dataplatform van een organisatie. Het verlaagt ook de kosten, omdat handmatige stappen voor het creëren, vernietigen en (het ergste van alles) het proberen te controleren van omgevingen, allemaal geautomatiseerd zijn.
DataOps vereist Governance By Design en Privacy By Design – dat wil zeggen, om effectief te zijn, moet een DataOps Platform zeer sterke Governance en Privacy modellen hebben die bij het ontwerp zijn opgenomen in de kern, en niet iets dat later wordt toegevoegd.
Geconfronteerd met multi-miljoen pond boetes voor oneigenlijk gebruik van gegevens, is governance essentieel voor data operations. Volgens de DataOps-filosofie wordt elke verandering geautomatiseerd getest om fouten en bugs op te sporen. De filosofie vereist ook dat er altijd twee paar ogen op alles zijn, zodat er voor elke pull request en code merge een handmatige controle wordt uitgevoerd.
U moet ook uw bron van waarheid definiëren – de basislijn waartegen de kwaliteit en nauwkeurigheid van gegevens wordt gemeten. Als het om software gaat, is de bron van waarheid de ondersteunende code repository van de applicatie in plaats van de applicatie zelf. Hetzelfde principe bestaat onder de DataOps filosofie- de code repository die uw code en componenten ondersteunt is de definitieve bron van waarheid voor uw applicaties. Governance wordt verder versterkt met automatisch gecreëerde audit trails. Elke wijziging, test en goedkeuring wordt volledig gedocumenteerd en voor altijd opgeslagen, zodat u kunt aantonen hoe gegevens zijn en worden gebruikt.
De realiteit is dat, van oudsher, hoe meer geld u in uw dataplatform investeert, hoe duurder toekomstig werk zal zijn. Toenemende complexiteit, platformuitbreiding, meer code: alles bij elkaar maakt het testen ingewikkelder en arbeidsintensiever – en dus duurder – vooral naarmate u verder opschaalt.
Als een datateam de verzoeken van belanghebbenden al niet kan bijbenen, hoe groot is dan de kans dat ze alle vereiste tests kunnen afronden? De oplossing is om geautomatiseerde data testen te gebruiken om problemen te identificeren en het team te ontlasten.
In de snelle agile ontwikkelomgeving is het onmogelijk om optimisme (het geloof dat een nieuwe implementatie de eerste keer zal werken) te balanceren met een gebrek aan ontwikkelproces. Geautomatiseerd testen en monitoren biedt een manier om optimisme tegen te gaan en problemen op te sporen die door optimisme worden veroorzaakt.
Organisaties als Amazon, Netflix en Etsy worden beschouwd als wereldleiders als het gaat om snel testen en implementeren. Zij kunnen met succes ongelooflijk snel nieuwe updates implementeren (in sommige gevallen om de paar seconden) met een bijna perfecte beschikbaarheid – vooral indrukwekkend als je bedenkt dat ze miljoenen regels code beheren. Geautomatiseerd testen is de belangrijkste vaardigheid die hieraan ten grondslag ligt, en ligt aan de basis van de meeste efficiëntieverbeteringen in softwareontwikkeling in de afgelopen twee decennia.
De wiskunde hiervoor is eenvoudig – als je met vertrouwen wilt releasen, moet je elk deel van het systeem testen (“totale” testdekking). Naarmate je systeem groter wordt, is dit meer werk. Als je sneller wilt releasen, moet je dit veel vaker herhalen. De enige manier om de vergelijking op te lossen waarbij de test sets groter worden en de frequentie van uitvoering ordes van grootte sneller wordt is volledige automatisering.
Geautomatiseerd testen is proberen te voorkomen dat “slechte dingen” in productie terechtkomen. Geautomatiseerde monitoring gaat over accepteren dat, hoewel geautomatiseerd testen van cruciaal belang is, het ook nooit perfect kan zijn, en dat er uiteindelijk iets doorheen zal glippen, en dit is waar goede monitoring de sleutel is. De meest geavanceerde DevOps organisaties van vandaag zien dit niet als een tekortkoming, maar als een realiteit die ze kunnen beheersen.
DataOps monitoring houdt meer in dan het bevestigen van systeembeschikbaarheid. Het controleert ook de productiekwaliteit van alle gegevens en artefacten in uw analytische processen, en test nieuwe code tijdens de implementatie. Door onverwachte variaties te detecteren en operationele statistieken te genereren, verzamelt uw datateam nieuwe inzichten die kunnen worden gebruikt om de prestaties verder te verbeteren – van de pijplijn en het onderliggende platform.
Het is ook belangrijk om te beseffen dat de definitie van beschikbaarheid van data is uitgebreid onder DataOps. Naast het kunnen uitvoeren van queries, definieert DataOps beschikbaarheid als het vermogen om gegevens terug te sturen die geldig zijn voor besluitvorming. Zelfs als uw platform 99,999% uptime haalt, is de beschikbaarheid misschien niet zo hoog als u denkt als het geen bruikbare inzichten kan leveren. Het is heel goed mogelijk dat defecte pijplijnen uw gegevens in gevaar brengen. Maar zonder geautomatiseerde tests kunnen deze storingen onopgemerkt blijven – en de nauwkeurigheid van uw analytics aantasten.
Collaboratie en self-service zijn de herkenbare resultaten en duidelijke voordelen van een geleverde DataOps. En we kunnen dit op twee manieren bekijken.
Ten eerste, samenwerking en self-service op een ontwikkelings- en operationeel niveau. Zoals we in deze hele filosofie hebben gezien, zijn er veel verschillende mensen en teams die bijdragen aan verschillende onderdelen van een algeheel data- en analyticsplatform. Data-engineers, data-analisten, data prep teams, data scientists, visualisatieteams, machine learning teams, etc. en ze gebruiken allemaal hun eigen specifieke tools om hun werk te doen. Het is als een productielijn die dataproducten ontwikkelt, en de klant ontvangt dat product aan het eind van de lijn. Vandaag werken al die teams onafhankelijk van elkaar, de coördinatie is zowel uitdagend als kwetsbaar, en de productkwaliteit is op zijn best onvoorspelbaar. DataOps is ontworpen om dit te coördineren en te opereren als een hoog presterende, voorspelbare, kwaliteitsgeoriënteerde, industriële productielijn. Het verwacht een heterogene tooling-omgeving en is gericht op het in staat stellen van al die teams om efficiënt samen te werken, en het orkestreren van de gehele levenscyclus om een product van de hoogste kwaliteit aan de eindklant te leveren.
Ten tweede, samenwerking en self-service op het niveau van de klant en de stakeholders. De meeste organisaties proberen meer data-driven te worden – ze willen inzichten uit gegevens om de besluitvorming te onderbouwen. Dit vereist dat gegevens uit verschillende delen van het bedrijf op één plaats worden samengebracht. De theorie is dat wanneer we alle data op één plaats hebben, iedereen ze kan gebruiken, zijn eigen vragen kan beantwoorden en zijn eigen use cases kan oplossen door meerdere datasets samen te voegen. Historisch werd dit gezien als een technologisch probleem, opgelost met een Data Warehouse waar we al deze verschillende gegevensverzamelingen kunnen samenbrengen. Dit is natuurlijk een deel van de oplossing. De realiteit voor de meeste ondernemingen is echter enigszins anders.
Voor typische zakelijke gebruikers is het erg moeilijk om te begrijpen welke gegevens beschikbaar zijn en hoe ze die moeten gebruiken. Hoe succesvoller een organisatie is in het samenbrengen van datasets, hoe erger dit probleem wordt;
Veel datasets hebben een bepaalde mate van data-gevoeligheid. Dit heeft ertoe geleid dat datasets weliswaar in hetzelfde Data Warehouse zijn geladen, maar dat de toegang ertoe beperkt is tot de afdeling die ze heeft aangemaakt (en een paar geselecteerde Data Guru’s). De technologie silo’s zijn dus vervangen door privacy silo’s;
Het invoeren van nieuwe gegevens is een lang, pijnlijk en duur proces geweest, waarvoor dus een sterke business case nodig was. Wanneer één of twee gebruikers alleen maar een eenvoudige spreadsheet wilden bijvoegen om andere gegevens die zich al in het Data Warehouse bevonden te kunnen samenvoegen/analyseren, was dit zelden mogelijk of kosteneffectief.
De ideale situatie hier is altijd geweest dat, met voldoende toegang tot gegevens in de hele organisatie, mensen in staat zullen zijn om inzichten te creëren en te ontdekken die van tevoren nooit bij hen waren opgekomen. De realiteit is vandaag heel anders: meestal moet je verantwoorden hoe en waarom je de gegevens nodig hebt om er toegang toe te krijgen, en dit vernietigt het ontdekkingselement dat zo essentieel is voor een data gedreven onderneming.
Om deze problemen aan te pakken, en de gaten te dichten naar de oorspronkelijke data-gedreven bedrijfsdoelstellingen, vereist DataOps:
Een business user facing data catalogus zodat zij kunnen zoeken en begrijpen welke data beschikbaar is en hoe deze te gebruiken;
Een manier om verschillende versies van gegevens te maken met verschillende niveaus van anonimisering, zodat datasets met een zekere mate van gevoeligheid nog steeds veilig kunnen worden gedeeld met de rest van de organisatie – waardoor het discovery-element mogelijk wordt;
Er moeten zeer lichte en snelle manieren zijn om eenvoudiger gegevens van eindgebruikers binnen te krijgen. Hiervoor hoeven niet noodzakelijkerwijs dezelfde controles en processen te worden gevolgd als voor de belangrijkste organisatorische gegevens – wat we “communautaire gegevens” zouden kunnen noemen.
Om de zeven pijlers van DataOps hoog te houden, moet elk onderliggend platform bepaalde mogelijkheden hebben:
Broncontrole: de mogelijkheid om code te vertakken tijdens de ontwikkeling zal helpen om ontwikkelingscycli te versnellen zonder bestaande operaties of, nog belangrijker, uw data in gevaar te brengen;
End-to-end orkestratie: automatisering is de sleutel tot het versnellen van de ontwikkeling, dus je hebt een platform nodig dat push-button uitvoering van je data pipelines biedt. Belangrijk is dat het platform in staat moet zijn om meerdere verschillende pipelines uit te voeren tegen dezelfde data;
Omgevingsbeheer: het door u gekozen platform moet functionaliteit bieden om code- en gegevens branches snel en efficiënt aan te maken en te verwijderen;
Geautomatiseerd testen en monitoren: om tekortkomingen in de code en de prestaties te identificeren voordat een implementatie wordt voltooid, en om te monitoren op zeldzame productieproblemen en engineers te waarschuwen voor problemen, zodat ze updates onmiddellijk kunnen terugdraaien;
Configuration Control and Governance: om ervoor te zorgen dat uw bedrijf zijn wettelijke en reglementaire verplichtingen nakomt, moet het platform automatisch documenteren hoe gegevens toegankelijk worden gemaakt, verwerkt en getransformeerd;
Samenwerking: om de toegang tot gegevens zowel intern als naar de rest van de organisatie toe te openen zonder de governance in gevaar te brengen.
Data-omgevingen van de toekomst zullen niet effectief kunnen functioneren zonder DataOps. Degenen die DataOps adopteren zullen de wendbaarheid hebben om met de data tsunami om te gaan, de vasthoudendheid om controle te houden en de kracht om bedrijfswaarde te leveren. De rest zal te maken krijgen met steeds hogere kosten, afnemende waarde en uiteindelijk een crisis creëren waarin ze worden vervangen.
In de komende 5 jaar zal elke organisatie overstappen op DataOps. Het zal de enige manier zijn om zinvol dataomgevingen te bouwen en te besturen.
DataOps is de zuiverste filosofie voor de beste manier om data-gedreven waarde te leveren, en de grootste ROI te halen uit uw gegevens.
DIKW Intelligence heeft een trackrecord in het opzetten, ontwerpen, onderhouden van uw DataOps stack.
DIKW Services is onze fullservice dienstverlener waar wij het volledige beheer doen van uw DataOps processen.
Bij DIKW Academy kunt u terecht voor toepassingsgerichte opleidingen op het gebied van data science en data engineering.
DIKW Intelligence
Wattbaan 1
3439 ML Nieuwegein
