Jeder, der sich schon länger mit Integration beschäftigt weiß, daß Integration ein elementares Bindeglied ist - der Leim der Systeme - und damit auch die Komponente, die entscheidend für den Erfolg der Umsetzung und für die Stabilität im operativen Betrieb sein kann.

Betrachten wir die Anfänge der Integration: im Zeitalter der Mainframe-Systeme, als Cobol noch die Wahl der Qual war, wurde eine Integrationsarchitektur meist noch nicht als notwendig erachtet. Warum auch? Es gab ja gefühlt nur ein System. Es entstanden jedoch zwischen den hunderten von Cobol-Programmen Datenschnittstellen, sei es per Flatfile oder über Datenbanktabellen. Der heute bekannte "Spaghettiknoten" entstand. Mit der damals zunehmenden Datenverarbeitung wuchs dieser Spaghettiknoten immer mehr.

Als dann der Trend "weg von einem System, weg vom grün-weiss-Terminal" des Mainframesystems und hin zu einer bunten Welt der 3-Thier Architektur hochkam, hielten Personal-Computer Einzug im Büro. Die grün-weissen 3270 Terminals verschwanden; Windows oder IBM OS2 war nun die Qual des Users und des Alltags. Der bereits vorhandene Spaghettiknoten wurde dadurch noch komplexer, weil immer mehr Schnittstellen entstanden. Oftmals mehr als einmal implementiert, kreuz und quer - da niemand mehr eine genaue Übersicht hatte.

Der Betrieb wurde zunehmend schwerer, und an ein proaktives Monitoring, Alerting oder an ein End-2-End Prozeßmonitoring war nicht zu denken. Es wurde nach Antworten gesucht. Das Zeitalter von EAI war geboren. Der Spaghetthiknoten wurde entwirrt, es wurde meist am Anfang noch eine Hub-and-Spoke Architektur aufgebaut mit dem EAI-Tool in der Mitte. Später wurde dann eine Bus-Architektur daraus, und am Ende des EAI-Zeitalters, mit dem Einzug von SOA und eSOA Ansätzen wurde dieses Zeitalter dann mit der ESB Architektur abgeschlossen.

Nun stehen wir wieder vor einem Wechsel, wie damals vom Mainframe zur 3-Thier Architektur. Im Zuge der vierten industriellen Revolution stehen wir nun am Anfang der digitalen Revolution, in deren Zuge wir uns immer mehr weg von den OnPremise-Systemen bewegen, die wir in der Vergangenheit so lieben gelernt haben, hin zu einer Multicloud-Architektur. In der aktuellen Übergangszeit leben wir in einer hybriden Multicloud-Architekturwelt die uns sicherlich noch eine Zeit begleiten wird - genauso wie vor gut 25 Jahren, als der Mainframe auch nicht von heute auf morgen "verschwand".
Der Trend wird definitiv weiterhin in Richtung Cloud gehen und auf Dauer nur schwer aufzuhalten zu sein. Das macht die Integration nicht einfacher. Doch welche Antworten finden wir darauf? Bauen wir uns nicht wieder einen neuen Spagetthiknoten auf, indem wir fleissig P2P Microservices in Massen implementieren? Wie werden wir dieser Herausforderung gerecht, und wie vermeiden wir dieselben Fehler wie damals in der Mainframe-Zeit, als jedes Cobol-Programm mit jedem anderen Cobol-Programm direkt miteinander kommunziert hat ohne eine "Middelware"? Die Antwort ist die Digitale Integration Hub Architektur.

Der Digitale Integration Hub übernimmt dabei in seiner Gesamtheit die Aufgabe der Integration. Der DIH agiert dabei meist vollständig in der Cloud, vorgelagert zu den noch vorhandenen OnPremise-Systemen.

Der DIH kann (wenn er gut konzipiert wurde) aufgrund seiner Architektur vollständig in seinen wichtigsten Komponenten dynamisch skalieren. Dies bedeutet, daß je nach Umfang des Datenverkehrs sich die Anzahl der Microservices  dynamisch erhöhen oder reduzieren kann. Dies gilt auch für den sog. Event-based Integration Layer. Somit kann der DIH automatisch auf Peaks reagieren und im "Leerlauf" nur die Ressourcen verbrauchen, die er minimal benötigt.

Im Zeitalter der Cloud spart dies pures Geld. Der DIH verhält sich somit "Brieftaschen-freundlich" nach dem Pay-what-you-use-Prinzip. Ein klassicher EAI-Layer muss dabei immer auf den maximalen Peak ausgelegt sein, um unter der maximalen Last auch zu funktionieren. Meist sind die Systeme daher überdimensioniert für den normalen Betrieb. Der DIH ist vom Sizing dynamisch immer genau so groß wie er sein soll, ganz egal wie groß der Peak auch sein mag. Durch das API-Gateway und das API-Portal werden die Schnittstellen nach außen transparant zur Verfügung gestellt.

Dieser Ansatz ermöglicht z.B. eine genaue Abrechnung der Konsumierung von API's, entweder für die interne Verrechnung oder für externe Drittanbieter, die neue Services oder ThirdParty-Apps basierend auf Ihren Daten anbieten wollen.