Cloud-native architectuur en het afbreken van applicatiemonolieten is goed, maar als je dat doet, heb je ook een manier nodig om de fijnmazige puinhoop die daaruit voortvloeit te beheren, stelt EnterpriseWeb
Door ZinetroN — Shutterstock < /figuur>
Hoe los je het eeuwenoude data-integratieprobleem op? We hebben dit behandeld in een van de eerste artikelen die we in 2016 voor deze column schreven. Het was een tijd waarin belangrijke termen en trends die het landschap van vandaag domineren, zoals kennisgrafieken en datafabric, op zijn best onder de radar waren.
Gegevensintegratie klinkt misschien niet zo heerlijk intrigerend als AI of machine learning-weetjes die op vanille-apps worden gestrooid. Toch is het het brood en de boter van velen, de enabler van alle coole dingen met behulp van data, en een premium use case voor concepten die ten grondslag liggen aan AI, zo betoogden we destijds.
De sleutelconcepten waar we toen voor pleitten, worden nu algemeen erkend en overgenomen in hun gedaante van kennisgrafiek en datafabric: federatie en semantiek. Destijds waren de concepten niet zo wijdverbreid en waren delen van de technologie minder volwassen en minder erkend. Tegenwoordig zijn kennisgrafieken en datafabrics top of mind; bekijk gewoon de laatste Gartner-rapporten.
De reden dat we dat oude verhaal opnieuw bekijken, is niet om ons te koesteren in een of andere “ik zei het je toch” zelfingenomenheid, maar om er iets aan toe te voegen. Kennisgrafieken en datafabrics kunnen, en hopelijk zullen, uiteindelijk problemen met data-integratie aanpakken. Maar hoe zit het met applicatie-integratie? Kunnen grafieken en ontologieën daarbij ook helpen?
Gegevensintegratie en applicatie-integratie
Het verhaal van de “99 datastores” was gebaseerd op het waargebeurde verhaal van hoe de wildgroei aan gegevensbronnen problemen voor de onderneming veroorzaakt. Maar hoe zit het met applicaties en API's? Datzelfde verhaal speelt zich af, dus waarom zou u niet dezelfde remedie voor die ziekte gebruiken? Dat is wat Dave Duggal en EnterpriseWeb willen bereiken.
Duggal, oprichter en CEO van EnterpriseWeb, heeft het grootste deel van zijn carrière besteed aan het starten, groeien, bouwen en veranderen van bedrijven. Wat hem motiveerde om EnterpriseWeb te starten, was zijn ervaring met het bouwen en integreren van applicaties, en het zien hoe statisch dat de operaties achterliet in de bedrijven die hij leidde. Hij zei:
De manier waarop traditionele softwareontwikkeling tot op de dag van vandaag plaatsvindt, is voornamelijk handmatige code en handmatige integratie. Je codeert en hercodeert, integreert en re-integreert. En dat past natuurlijk niet bij de eisen van vandaag.
Op een gegeven moment bevond alles zich op een mainframe — een grote gecentraliseerde monoliet, maar ook erg krachtig. Een van de redenen dat mainframes erg krachtig zijn, is dat op het mainframe data en code samenleven. Er was geen valse kloof tussen het datateam en het applicatieteam.
Nu zijn we verdeeld. We hebben een hele reeks nieuwe mogelijkheden. Maar we hebben ook heel wat uitdagingen. Want toen we de aggregatie van het mainframe en vervolgens monolithische applicaties, die deze nauw gekoppelde codeballen waren, naar meer servicegebaseerde applicaties, naar microservices en nu serverloze functies, desaggregeerden zonder een programmeermodel voor samenstelling en beheer te hebben.
Met andere woorden, we hebben alles uit elkaar gehaald. Humpty Dumpty brak. Alle stukken lagen op de grond. We zijn er niet in geslaagd om een mechanisme, een middel of een methode te introduceren om die dingen weer samen te stellen en te kijken waar we nu staan.
De kern van Duggals stelling en het aanbod van EnterpriseWeb is dat dezelfde tools die data-integratie kunnen aanpakken, zouden ook applicatie-integratie moeten kunnen aanpakken: grafieken en ontologieën.
