zurück zur Startseite Axway
Autonomie und Dynamik erreichen

„Nur die notwendigen Aspekte zentralisieren“

In einem weiteren Kurzkommentar erklärt Erik Wilde, Digital Transformation Catalyst bei Axway, was die Bewegung hin zu einem offenen Ökosystem für die IT-Architektur bedeutet.

  • Zentralisierung

    Bei einer Bewegung hin zu einem offenen Ökosystem sollte man nur zentralisieren, was man zentralisieren „muss“. ((Bildquelle: Getty Images / iStock / Getty Images Plus))

  • Erik Wilde, Axway

    „Es wird immer wichtiger werden, Offenheit zu bewahren“, meint Erik Wilde, Digital Transformation Catalyst bei Axway. ((Bildquelle: Axway))

Auf der Internet- und Webebene gibt es schon lange das Prinzip von „Smart Endpoints and Dumb Pipes“. Dies ist wie alles nicht als kategorischer Lehrsatz zu verstehen, aber es ist dennoch einer der Gründe, weshalb sich das Internet und das Web so robust und dynamisch entwickeln konnten. Man überlege sich einmal, für wie lange das Internet Protokoll IP und das Verbindungsprotokoll TCP als Grundlage dienen konnten: über Jahrzehnte hinweg!

Der grundlegendste Wechsel in der IT-Architektur ist der zur Dezentralisierung. Tendenziell herrscht oft der Ansatz, in der IT-Architektur alles zu zentralisieren, was man zentralisieren „kann“. Dies hat eine ganze Reihe an Gründen, die zum Teil technischer, aber z.T. auch organisatorischer Natur sind. Mit dieser Grunddynamik landet man unausweichlich bei eher integrierten Architekturen.

Bei einer Bewegung hin zu einem offenen Ökosystem sollte man nur zentralisieren, was man zentralisieren „muss“. Es ist vor allem diese grundlegende Perspektive, die es einem ermöglicht, mehr Autonomie und Dynamik zu erreichen, indem man nur die notwendigen Aspekte zentralisiert und damit vereinheitlicht.

Konsequent auf Offenheit setzen

Eine andere gute generelle Einstellung ist die, immer über Alternativen nachzudenken. Wenn ich z.B. in einer Architektur über den Einsatz von Low-Code-/No-Code-Werkzeugen nachdenke, so kann das schlicht gewissen Anforderungen geschuldet sein. Aber ich habe immer noch die Wahl, ein solches Werkzeug so zu wählen, dass sich nur eines verwenden lässt (weil es mit anderen Komponenten integriert ist), oder ich kann eines wählen, dass sich durchaus auch austauschen lässt, oder wo sich zwei solche Werkzeuge parallel verwenden lassen. Dies kann ich dann tun, wenn ich konsequent auf Offenheit setze und in meiner Architektur APIs ermögliche, dass Werkzeuge auf Ressourcen und Dienste zugreifen, und ich nur Werkzeuge verwende, die für eine solche offene Umgebung konzipiert sind.

Was sich an diesem Beispiel erkennen lässt, ist, dass eine offene Architektur immer daran denken sollte, wie man Dinge auch anders machen könnte. Lösungen, die auf den ersten Blick attraktiv sind aufgrund großer Integration, können auf den zweiten Blick in einem ganz anderen Licht erscheinen. Der Wert von Architekturentscheidungen besteht dann nicht nur darin, was man sofort erreicht, sondern vor allem darin, was man an neuen Möglichkeiten eröffnet, und dass man sich so wenig Alternativen wie möglich verschließt.

Diese fundamental andere Sichtweise wird in den nächsten Jahren wahrscheinlich dazu führen, dass der Wert hoch integrierter Lösungen anders bewertet wird. Es wird immer wichtiger werden, Offenheit zu bewahren, so dass man für viele Entscheidungen eine „Best of Breed“-Auswahl vornehmen und ohne extrem großen Aufwand auch wieder revidieren kann.

Um auf den Beginn zurückzukommen: Architektur und Denkweise von IT-Architekturen werden sich mehr denen extrem großer IT-Systeme (wie des Internets oder des Webs) angleichen. Es besteht natürlich immer noch ein Unterschied zwischen diesen und der IT-Architektur einer Organisation, aber der Trend zeigt ganz klar in diese Richtung.

©2026Alle Rechte bei MEDIENHAUS Verlag GmbH

Unsere Website verwendet Cookies, um Ihnen den bestmöglichen Service zu bieten. Durch die weitere Nutzung der Seite stimmen Sie der Verwendung zu. Weitere Infos finden Sie in unserer Datenschutzerklärung.

ok