Molnbaserad arkitektur och att bryta ner applikationsmonoliter är bra, men om du gör det behöver du också ett sätt att hantera den finkorniga röran som uppstår, hävdar EnterpriseWeb
Av ZinetroN — Shutterstock < /figur>
Hur löser du det urgamla dataintegreringsproblemet? Vi tog upp detta i en av de första artiklarna vi skrev för den här kolumnen redan 2016. Det var en tid då nyckeltermer och trender som dominerar dagens landskap, som kunskapsgrafer och dataväv, i bästa fall låg under radarn.
Dataintegrering låter kanske inte lika spännande som AI eller maskininlärning som spritsas på vaniljappar. Ändå är det mångas bröd och smör, möjliggör för alla coola saker med hjälp av data, och ett förstklassigt användningsfall för koncept som ligger till grund för AI, argumenterade vi då.
De nyckelbegrepp som vi förespråkade för då har blivit allmänt erkända och anammat idag i deras kunskapsdiagram och datastruktur: federation och semantik. Då var begreppen inte lika utbredda, och delar av tekniken var mindre mogen och erkänd. Idag är kunskapsgrafer och datatyger top of mind; kolla bara de senaste Gartner-rapporterna.
Anledningen till att vi återkommer till den gamla historien är inte för att sola sig i någon “sägt det” självrättfärdighet, utan för att lägga till den. Kunskapsdiagram och datastrukturer kan, och förhoppningsvis, så småningom, ta itu med dataintegreringsproblem. Men hur är det med applikationsintegration? Kan grafer och ontologier hjälpa till med det också?
Dataintegration och applikationsintegration
Berättelsen om “99 databutiker” var baserad på den sanna historien om hur spridningen av datakällor skapar problem för företaget. Men hur är det med applikationer och API:er? Samma historia spelar där ute, så varför inte använda samma botemedel för den sjukdomen också? Det är vad Dave Duggal och EnterpriseWeb vill uppnå.
Duggal, grundare och VD för EnterpriseWeb, har tillbringat större delen av sin karriär med att starta, växa, bygga och vända företag. Det som motiverade honom att starta EnterpriseWeb var hans erfarenhet av att bygga och integrera applikationer, och att se hur statiskt som lämnade verksamheten i de företag han drev. Han sa:
Det sätt som traditionell mjukvaruutveckling sker än i dag är manuell kod och manuell integration, i första hand. Du kodar och kodar om, integrerar och återintegrerar. Och det passar naturligtvis inte för dagens krav.
Vid ett tillfälle var allt på en stordator — en stor centraliserad monolit, men också mycket kraftfull. En av anledningarna till att stordatorer är väldigt kraftfulla är att på stordatorn lever data och kod tillsammans. Det fanns inte den här falska skillnaden mellan datateamet och applikationsteamet.
Nu är vi distribuerade. Vi har en hel mängd nya möjligheter. Men vi har också en mängd utmaningar. För när vi disaggregerade från stordatorn och sedan monolitiska applikationer, som var dessa tätt kopplade kodbollar till mer tjänstebaserade applikationer, till mikrotjänster och nu serverlösa funktioner, disaggregerade vi utan att ha en programmeringsmodell för sammansättning och hantering.
Med andra ord, vi tog isär allt. Humpty Dumpty gick sönder. Alla bitarna låg på golvet. Vi misslyckades med att faktiskt införa en mekanism, ett medel eller en metod för att sammanställa dessa saker igen och titta på var vi är idag.
Kärnan i Duggals avhandling, och EnterpriseWebs erbjudande, är att samma verktyg som kan hantera dataintegration bör också kunna hantera applikationsintegration: grafer och ontologier.
Fallet med SAP
Big Data Analytics | Moln | Innovation | Teknik och arbete | Samarbete | Utvecklare