Cloud-native arkitektur og nedbrydning af applikationsmonoliter er godt, men hvis du gør det, har du også brug for en måde at håndtere det finkornede rod, der opstår, hævder EnterpriseWeb
Af ZinetroN — Shutterstock < /figur>
Hvordan løser du det ældgamle problem med dataintegration? Vi behandlede dette i en af de første artikler, vi skrev til denne klumme tilbage i 2016. Det var en tid, hvor nøgletermer og tendenser, der dominerer nutidens landskab, såsom vidensgrafer og datastruktur, i bedste fald var under radaren.
Dataintegration lyder måske ikke så lækkert spændende som AI eller maskinlærings-godbidder drysset på vanilje-apps. Alligevel er det manges brød og smør, muliggør alle fede ting ved hjælp af data og en førsteklasses use case for koncepter, der understøtter AI, argumenterede vi dengang.
De nøglebegreber, som vi gik ind for dengang, er blevet bredt anerkendt og vedtaget i dag i deres vidensgraf og datastof-form: føderation og semantik. Dengang var begreberne ikke så udbredt, og dele af teknologien var mindre moden og anerkendt. I dag er vidensgrafer og datastrukturer top of mind; bare tjek de seneste Gartner-rapporter.
Grunden til, at vi gentager den gamle historie, er ikke for at sole sig i en eller anden “sagt dig det” selvretfærdighed, men for at tilføje den. Videngrafer og datastrukturer kan, og vil forhåbentlig i sidste ende, løse dataintegrationsproblemer. Men hvad med applikationsintegration? Kunne grafer og ontologier også hjælpe med det?
Dataintegration og applikationsintegration
Fortællingen om “99 datalagre” var baseret på den sande historie om, hvordan udbredelsen af datakilder skaber problemer for virksomheden. Men hvad med applikationer og API'er? Den samme historie udspiller sig derude, så hvorfor ikke også bruge den samme kur mod den sygdom? Det er, hvad Dave Duggal og EnterpriseWeb søger at opnå.
Duggal, grundlægger og administrerende direktør for EnterpriseWeb, har brugt det meste af sin karriere på at starte, vokse, bygge og vende virksomheder. Det, der motiverede ham til at starte EnterpriseWeb, var hans erfaring med at bygge og integrere applikationer og se, hvor statisk det efterlod driften i de virksomheder, han drev. Han sagde:
Den måde, traditionel softwareudvikling foregår på selv den dag i dag, er manuel kode og manuel integration, primært. Du koder og omkoder, integrerer og genintegrerer. Og det skalerer naturligvis ikke til nutidens krav.
På et tidspunkt var alt på en mainframe – en stor centraliseret monolit, men også meget kraftfuld. En af grundene til, at mainframes er meget kraftfulde, er, at på mainframen lever data og kode sammen. Der var ikke denne falske kløft mellem datateamet og applikationsteamet.
Nu er vi fordelt. Vi har en lang række nye muligheder. Men vi har også en lang række udfordringer. For da vi adskilte fra mainframen og derefter monolitiske applikationer, som var disse tæt koblede kodekugler til mere servicebaserede applikationer, til mikrotjenester og nu serverløse funktioner, adskilte vi os uden at have en programmeringsmodel til sammensætning og styring.
Med andre ord skilte vi alt fra hinanden. Humpty Dumpty gik i stykker. Alle brikkerne lå på gulvet. Vi formåede ikke rent faktisk at introducere en mekanisme, et middel eller en metode til at sammensætte disse ting igen og se på, hvor vi er i dag.
Kernen i Duggals afhandling og EnterpriseWebs tilbud er, at de samme værktøjer, der kan adressere dataintegration, bør også kunne adressere applikationsintegration: grafer og ontologier.
Sagen om SAP
Big Data Analytics | Sky | Innovation | Teknik og arbejde | Samarbejde | Udvikler