Ja, enterprise service bussen, ESBs voor integratie, ik verklaar ze tot een succes! De afgelopen jaren deden ze een inhaalslag. En ze vullen meer en meer hun belofte in. Net nu het hele spel door Digitaal is veranderd. Moeten we integratie nu weer anders gaan doen? Ik denk van wel.

Rond de eeuwwisseling ontstond de behoefte aan enterprise applicatie integratie. Primaire doelstelling het met elkaar verbinden van applicaties. Eerst vooral 1 op 1. En omdat er veel verschillende platformen, transportmogelijkheden, gegevensformaten en mogelijkheden van applicaties waren leidde dat tot het leggen van veel losse bruggen.

Omdat dat een onbeheersbare kluwen dreigde te worden kwam van halverwege het vorige decennium de enterprise services bus op. Met als primaire doelen het integreren te uniformeren. Middels adapters op applicaties werden de applicatie-specifieke zaken geuniformeerd op de bus. Je hoeft je alleen in de adapters zorgen te maken over specifieke protocollen, dataformaten of toegangsopties van applicaties. Binnen de bus kun je de data in het uniform data model aan alle andere applicaties beschikbaar maken. Zo raak je applicatie-onafhankelijk in de bus.
Bovendien kon je nu op 1 plaats beheren. Het maken, bewaken en herstellen van integraties werd overzichtelijk en inzichtelijk.

Door vervolgens centrale, samengestelde, services op de bus te maken, was het mogelijk diensten over alle applicaties heen te maken. Bijvoorbeeld: al wordt een klant in meerdere applicaties beheerd, als applicatie hoef ik slechts te abonneren op de centrale klant service van de bus om van alle veranderingen op de hoogte te blijven.

Inmiddels, tien jaar later, zijn enterprise service bussen een succes. Vaak is meer dan 75% van het applicatielandschap er met een adapter op aangesloten. Informatiestromen lopen beheerst, veilig en auditbaar door de bus. En vaak zijn er belangrijke herbruikbare centrale services op gerealiseerd. Het was lange tijd wennen, maar de laatste jaren is de inhaalslag gemaakt.

En nu verandert Digitaal het integratie spel. Een deel van de oorspronkelijke integratie doelen is nog geldig. Een heel nieuw pallet van behoeften/doelen is zichtbaar.

Nog steeds overbruggen we applicatie specifieke kenmerken. Maar die zijn veel meer gestandaardiseerd. Bijvoorbeeld de meeste applicaties hebben een “REST” of “SOAP” API voor de integratie. De focus van de enterprise service bus hoeft hier niet meer te liggen.

Nog meer dan vroeger willen we een zekere onafhankelijk van de applicaties. Applicaties (en hun interfaces) waren vaak jaren stabiel, vastgeklikt op 1 versie. Nu veranderen applicaties, meer en meer in de cloud, en dus ook hun API, wekelijks of maandelijks.

Maar de stevige centrale regie en de centrale logica, daar heeft Digitaal een andere kijk op. Flexibiliteit en autonomie, zelf de integratie kunnen verzorgen, dat is een belangrijke eis. En die eis werd vooral voelbaar door dat de business meer en meer extern samenwerkt. Een API moet daar makkelijk bruikbaar, via zelfservice, goed gedocumenteerd, toegankelijk zijn. Zodat een willekeurige ontwikkelaar daarop kan aanhaken. Losgekoppeld, maar beheerst. API management doet haar intrede.

Meer en meer ook moet externe data worden geintegreerd. Niet batchmatig, maar realtime. En niet kleinschalig, maar met grote volumes, bijv. verzameld vanuit social media, bilaterale interactie met klanten of surfgedrag op het web.

Meer en meer is snelheid geboden. Moet integratie direct vanuit de doos kunnen worden opgelost. Zijn applicatie-leveranciers meer dan ooit al met elkaar bezig om de basis integratie voor elkaar te hebben. Dat kan ook makkelijker, omdat ze via API management in elkaars keuken kunnen kijken en de integratie al voor ons klaarmaken. Integratie hergebruik en onafhankelijkheid van applicaties lijkt daarmee verloren te gaan. Maar het wordt gelukkig vervangen door leveranciers die, al autonoom samenwerkend, zorgen dat de integratie voor elkaar is.

Tot slot wordt integratie steeds meer vloeibaar. Ze noemen het ook wel zero integration. Het oorspronkelijke patroon is dat de ene applicatie verzoekt aan de ander. Zo ontstaan er vaste integratie paden, waarop je heen en weer moet schakelen. Een nieuw patroon is dat informatie niet meer gehaald, maar een data snelweg op gepushed wordt. Voor iedere andere applicatie realtime binnen bereik. Van schakelen naar gewoon consumeren.
Meer en meer merk ik in mijn praktijk: de traditionele ESB is niet voor Digital ingericht. Hij is met een ander doel opgezet. Van migratie – naar de cloud, naar oplossingen maken in dagen, naar stromende data – kan eigenlijk geen sprake zijn. De nieuwe doelen vragen een nieuwe lichtere opzet. Digital is spelbreker, we moeten het anders doen.

Wilt u meer lezen over hoe: kijk dan bij Vereenvoudigen van IT.

Anderen lazen ook deze blog van Rijk over systems of engagement!

Meer weten over het ontwerpen van een digitale strategie?

Tags: , ,