Autor: Firma innoQ Deutschland

Digitale Souveränität als Selbstverständnis

Digitale Souveränität als Selbstverständnis

Wie Umsetzungsteams aus der "Wir-sind-nicht-Google-Falle" entkommen und gemeinsam Verantwortung übernehmen für europäische Antworten auf europäische Probleme.

Der Artikel wendet den Begriff „digitale Souveränität“ auf Umsetzungsteams als Netzwerke von Menschen mit je eigenen Fähigkeiten, Wünschen, Bedürfnissen und Visionen an. Ausgehend von der Prämisse, dass die Basis für technische und organisatorische Souveränität komplexer Systeme in den Fähigkeiten der Menschen besteht, die diese Systeme aufbauen, analysiert der Artikel Eigenschaften schlagkräftiger Umsetzungsteams und einige Stellschrauben, an denen Organisationen drehen können, um auf der operativen Ebene souveräner zu werden. Wie überwinden wir als Einzelpersonen und als Teams in der europäischen digitalen Industrie das Gefühl, dass wir Google, Meta und Co. immer nur hinterherlaufen, und wie ermächtigen wir uns mehr und mehr, im Sinne unserer europäischen Wertvorstellungen eigene Lösungen für eigene Probleme zu finden?

Wir sind nicht Google?

Wir sind nicht Google. Dieser Satz ist in der IT oft zu hören. Wenn wir über digitale Souveränität sprechen, dann muss er uns innehalten lassen, denn er kann Ausdruck eines Selbstverständnisses sein, das mit Souveränität nichts zu tun hat. Vorweg: Es ist richtig, Nutzerbasis und Wichtigkeit einer Software realistisch einzuschätzen: Eine interne Konstruktionssoftware für ein mittelständisches deutsches Unternehmen hat andere Anforderungen an Skalierbarkeit und Durchsatz als Google – geschenkt. Aber da schwingt oft noch etwas anderes mit. Wir sind nicht Google. Selbstzweifel. Neid. "Die Amerikaner sind uns softwaretechnisch Lichtjahre voraus, das holen wir nicht mehr ein. Im Silicon Valley sind mehr Ressourcen, technische Intelligenz und Macht konzentriert als wir hier im altmodischen Europa je versammeln könnten." Dieses Gefühl, dass wir nur kleine Brötchen backen, während andere die „echte“ Software bauen (und damit ein Heidengeld verdienen), die wir täglich nutzen und ohne die wir, mit Verlaub, aufgeschmissen wären: Windows/MacOS/iOS, MS365, die Google-Suite, AWS, ChatGPT/Claude… was kommt als nächstes? Die gespannte Vorfreude, wenn der Apple-CEO in Kalifornien vor der Weltpresse auf die Bühne tritt… fast wie Weihnachten! Nur warum eigentlich nicht in Berlin? In Paris? London? Warum sind es immer „die Amerikaner“, die das Rad der Zeit vorantreiben?

Zu tun gäbe es genug

Nicht falsch verstehen: Das ist kein Plädoyer dafür, in Europa „das nächste Facebook zu bauen“. Unsere Rahmenbedingungen sind andere. Souveränität hat für uns, im ganz altmodischen Sinne, etwas mit Verantwortung zu tun; und vielleicht ist Digitalkapitalismus auch gar nicht so unser Ding. Aber das heißt nicht, dass es hier nichts zu tun gäbe. Könnte zum Beispiel GenAI das ur-europäische Dickicht aus Regularien und Gesetzen navigierbar machen? Für Normalsterbliche? Es suchen doch gerade alle ganz wuselig nach Nägeln für diesen Hammer. Hier wäre einer – wohlgemerkt, für die kommende europäische Hammer-KI, die genau den gleichen horrenden Energiehunger haben wird wie ihre amerikanischen und chinesischen Geschwister. Wie der gestillt und bestenfalls eingehegt werden kann, möglichst ohne gleich ein Atomkraftwerk neben das Rechenzentrum zu stellen… ungeklärt. Und dann (Verzeihung bitte) noch die ganz große Moralkeule: Irgendwo in der Welt wurde der menschgemachte Klimawandel im letzten November abgewählt. Wärmer wird es aber immer noch und Lösungen, auch digitale, sind gefragt. Green IT anyone?

Die Liste wäre beliebig fortzusetzen — der Punkt ist: Wenn wir digitale Souveränität einmal herauslösen aus dem Kontext einer bedrohlichen globalpolitischen „Zeitenwende“, aus dem ihre Notwendigkeit im deutschen Diskurs für gewöhnlich abgeleitet wird, dann können wir sie positiver verstehen, konstruktiver: Dann machen uns nicht unaufhörlich die Alarmsirenen im Hinterkopf kirre, und wir agieren nicht wie Getriebene sondern, ganz genau, souverän. So verstanden ist digitale Souveränität die intellektuelle und organisatorische Kapazität, komplizierte Probleme selbst digital zu lösen.

Ja, das beinhaltet die Fähigkeit, europäische Alternativen für Google, AWS und MS365 zu entwickeln. Vor allem aber ist das die Fähigkeit, Herausforderungen jeglicher Art anzupacken – die oben genannten sind da nur Beispiele. Sich das zu trauen ist eine strategische Entscheidung, durch die aber noch keine Welt verändert ist. Die beste Idee ist wertlos, wenn sie nicht zur rechten Zeit und mit angemessenen Mitteln umgesetzt wird. Eins ist sicher: Damit das gelingen kann, muss das Wir-sind-nicht-Google-Mindset aus den Köpfen verschwinden – auf allen Ebenen, aber vor allem bei den Umsetzungsteams. Schauen wir uns genauer an, was souveräne Entwicklungsteams auszeichnet, und an welchen Stellschrauben wir drehen können, um Souveränität auf der operativen Ebene zu fördern.1

Das souveräne Team

Wir nähern uns der Sache von außen: Ein Team von Informatiker:innen und Fachexpert:innen entwickelt Software für eine Organisation, die digital souverän sein will. Unser Team möchte das unterstützen. Wie können wir beurteilen, ob es das tut?

Der Blick des Zielstrebers

Da wir zunächst annehmen, dass wir die inneren Abläufe des Teams nicht kennen, bleibt uns nur der Blick aufs Ergebnis. Reflexhaft ziehen wir die Standardmetriken Effektivität und Effizienz heran: Ein Team, das genau das liefert, was gebraucht wird, ist effektiv. Wenn es dabei nicht mehr Ressourcen verbraucht als nötig, ist es effizient. Das sind Eigenschaften, die wir umgangssprachlich als Ausdruck von Souveränität bezeichnen würden. Und es sind Eigenschaften, die der Organisation als ganzer helfen, ihre Ziele zu erreichen, sowie Erreichbarkeit und Ressourcenbedarf künftiger Ziele einzuschätzen. Die Organisation wird sich dadurch seltener als andere verkalkulieren. Die Qualität ihrer Software wird ihr einen Wettbewerbsvorteil verschaffen. Ihre Teams sind in der Lage, für Probleme adäquate Lösungen zu finden und diese umzusetzen – ohne, oder mit Unterstützung von außen in angemessenem Maße. All das zahlt darauf ein, dass die Menschen in der Organisation sich selbst als souverän erleben; und es qualifiziert die Organisation als digital souverän im oben vorgeschlagenen konstruktiven Sinne.

Effektivität und Effizienz sind schön für Menschen, die Menschen und Prozesse verwalten, denn sie sind messbar (Effizienz) und entscheidbar (Effektivität) – allerdings erst in der Rückschau. Vom Ergebnis ausgehend kann ich beurteilen, ob der Weg dahin gut gewesen ist. Ich kann Zahlen anschauen und „ja“ sagen, „so machen wir das wieder“ – oder eben „nein, das war nicht gut“. Ich kann zwar unterwegs schon anfangen zu messen, Vergleichswerte heranziehen, und mich im Steuern und Gegensteuern versuchen. Aber die unbequeme Wahrheit ist: Meine Zahlen werden mir wenig dabei helfen, mein Team zu beschleunigen. Niemand mag es, gemessen zu werden, beurteilt und dann in eine Richtung geschubst. Außerdem stimulieren Zahlen und Diagramme intrinsische Motivation nur bedingt – wenn überhaupt.

Schlagkraft

Nehmen wir an, unser Team agiert tatsächlich souverän. Wir schauen auf das Ergebnis und stellen fest: Das war effektiv und effizient. Welche Eigenschaften hat das Team dann wahrscheinlich? Wir suchen nach Qualitäten, die flüchtiger sind als das in Zahlen fassbare. Frei assoziiert und ungeordnet: Energie – Lern- und Leidensfähigkeit – Einsatzbereitschaft – Fachwissen – technische Kompetenz – Disziplin – gute Teamdynamik – Entscheidungsfreude und -fähigkeit – Identifikation mit dem Produkt – Geduld – … Die Menge ist nicht scharf begrenzt und keineswegs vollständig: Viele schwer messbare Qualitäten, die wir der Einfachheit halber mit dem energischen Wort Schlagkraft zusammenfassen werden. Schlagkräftige Menschen und Teams werden sich sehr wahrscheinlich als souverän erweisen. Ein schlagkräftiges Team kann liefern – rasch und präzise, und nicht nur einmal. Ein schlagkräftiges Team will liefern. Und wahrscheinlich tut es das sogar mit jedem Mal überzeugender.

Das Dumme ist, dass ich Schlagkraft nicht herbei-organisieren kann. Es gibt sie einfach nicht, die drei goldenen Regeln der Teambildung, die meine Entwickler über Nacht zum Dreamteam zusammenschweißen werden. Schlagkraft entzieht sich einer genauen Definition, und damit jeder wiederholbaren Strategie, sie herbeizuführen — und das ist gut so. Das sind Menschen, die unsere Software entwickeln: eigentümliche, komplizierte Wesen mit je eigenen Stärken, Schwächen, Wünschen und Visionen. Ganz zu schweigen vom Team, diesem fragilen sozialen System, von dem am Anfang niemand mit Sicherheit sagen kann, welche Dynamiken es entwickeln wird.

Schlagkraft des Teams setzt Schlagkraft des Einzelnen voraus. Schlagkraft des Einzelnen setzt aufgabenspezifische Fachkompetenz voraus – und individuelle Reife: Ich muss gelernt haben, meine Energie auszurichten und dosiert einzusetzen. Ich muss erlebt haben, wie be-stärkend es ist, Verantwortung zu übernehmen, und wie befriedigend, meinen eigenen Teil zu einem großen Ganzen beigetragen zu haben. Ich habe wahrscheinlich verstanden, dass weder der Obstkorb noch der in-house-Barista hinreichende Kriterien für ein gutes Arbeitsumfeld sind. Vielleicht ist es mir am Ende des Tages sogar wichtiger, zuzupacken und etwas zu schaffen, als mich wohl zu fühlen… Es ist klar, dass wir uns solche Menschen nicht backen können. Wir können das alles auch irgendwie schlecht unter „Was du mitbringst“ in Stellenausschreibungen auflisten: „Du brennst für XY“ fühlt sich auf gut Neudeutsch einfach cringe an; und wenn wir anfangen, Nachweise für Lebenserfahrung oder geleistete Therapiestunden einzufordern, wird uns erst HR den Vogel zeigen, und dann der DSGVO-Beauftragte.

Zusammengefasst: Wir wollen schlagkräftige Teams, weil die warscheinlich effektiv und effizient, lies: souverän sind. Schlagkraft entsteht und wirkt auf einer Ebene, die sich der Beurteilung und der managenden Manipulation von außen entzieht. Das heißt aber nicht, dass wir machtlos sind: Schlagkraft ist Ausdruck des ungehemmten Zusammenspiels verschiedener gesunder, grundmeschlicher Eigenschaften. Schlagkräftig zu sein fühlt sich einfach gut an, und wenn ich Inspiration und Gelegenheit dazu habe, werde ich mich wahrscheinlich mit der Zeit zu einer schlagkräftigeren Person entwickeln. Welche Rahmenbedingungen sind dafür günstig? Wie könen wir unseren Entwicklern und Teams Gelegenheit dazu geben, aus sich selbst heraus souveräner zu werden?

Stellschrauben und Fußangeln

Es seien im Folgenden wahllos und ungeordnet Beobachtungen aus unserem eigenen Projektalltag herausgegriffen, die in diesen Kontext passen. Sie können den Blick für Randbedingungen schärfen, die Entwicklungsteams mittelfristig schlagkräftiger machen – oder eben nicht. Viele davon sind Dinge, „die ja jeder weiß“ – die aber zu oft unter den Tisch fallen, weil sie als weich und schwer beeinflussbar gelten.

Keep it simple, stupid

Jeder Entwickler, der sich schon mal in eine große, unbekannte Codebasis einlesen musste, wird bestätigen: KISS ist grundsätzlich eine gute Idee. Auf der organisatorischen Ebene wird das Konzept seltener angewendet. Dabei liegen die Vorteile auf der Hand: Je einfacher Organisationsstrukturen und Prozesse sind, desto weniger kommt es zu Indirektion und Reibungsverlusten. Je weniger Zeit die Teams dafür aufwenden, unnötig komplizierte Strukturen zu verstehen oder sogar selbst aufzubauen, desto mehr Zeit bleibt für die eigentliche Arbeit. Wohlgemerkt, das ist kein Appell für Anarchie: Arbeitsteilung muss organisiert werden – aber jedes Team ist anders, und die Grundannahme sollte sein, dass eine Gruppe erwachsener Menschen mit einem klaren Ziel vor Augen in der Lage ist, sich ad hoc selbst zu organisieren – anhand weniger etablierter Grundprinzipien. Wenn ich einem Team dieses Vertrauen entgegenbringe, wird es ein Bewusstsein für Autonomie und Entscheidungsmacht über die eigenen Abläufe entwickeln – eine Grundvoraussetzung für energisches Handeln und Entscheidungsfreude.

Keine Scheu vor Hierarchien

Das ist auch kein Plädoyer dafür, Hierarchien abzuschaffen. Flache Hierarchien sind wahrscheinlich eine gute Idee, weil sie effizienter sind als lange Befehlsketten. Keine Hierarchien – das endet im Chaos. Wo es darauf ankommt, dass Dinge trotz widriger Umstände und begrenzter Ressourcen funktionieren, da gibt es Hierarchien2. Die Schwierigkeiten mit Hierarchien liegen nicht darin, dass Dinge an anderer Stelle entschieden werden. Probleme entstehen, (a) wenn Entscheidungen zu lange dauern, weil sie die Befehlskette hoch- und wieder runterwandern, (b) wenn die Teams Ziele, die zwei, drei Ebenen weiter oben postuliert wurden, nicht verstehen oder sich nicht damit identifizieren können, und (c) wenn der schale Beigeschmack von Unterordnung und Machtgefälle zu stark ist, der jedes Gefühl persönlicher Souveränität zersetzen kann. Verstehen wir Hierarchien aber nicht vertikal („die da oben“) sondern horizontal, dann geht es nicht um Hackordnungen, sondern um klare Aufgabenzuteilung: Diese Entscheidung trifft X, weil er dafür qua Expertise gut geeignet ist, und die Zeit hat, den organisatorischen Kontext im Blick zu behalten. Betrifft die Entscheidung Einheiten außerhalb des näheren Umfeldes, dann schalte ich Y ein, die die Dinge aus größerem Abstand mit weiterem Blickfeld sieht. Lange Rede kurzer Sinn: Hierarchien sind wirklich besser als ihr Ruf, solange sie nicht durch Dynamiken belastet sind, die sachfremd und ungesund sind.

Sinnvolle Ziele mit Identifikationspotenzial

Die Weisheit ist nicht neu: Wenn ich viele intelligente Menschen dazu bringen will, in dieselbe Richtung zu laufen, muss ich ihnen dafür einen Grund geben. Ich muss klare Ziele formulieren, und diese Ziele müssen geeignet sein, intrinsische Motivation zu wecken. Zu diesem alignment innerhalb großer Organisationen haben sich viele kluge Menschen Gedanken gemacht – gerade weil es oft eine Herausforderung bleibt. Wer viel mit Menschen zu tun gehabt hat, die Software bauen (oder andere komplizierte Engineering-Aufgaben bewältigen), der weiß, dass diese Menschen oft ein tiefes inhaltliches Interesse an ihrer Arbeit haben, und dass ihnen die Aufgaben an sich oft wichtiger sind als finanzieller Erfolg. Wenn es in einer Organisation einen Wert hat, qualitativ hochwertige, nachhaltige Software zu bauen, die sinnvolle Dinge für Menschen tut, dann wird es dieser Organisation vergleichsweise leicht fallen, ihre Teams dazu zu bringen, sich mit ihren Aufgaben und Produkten zu identifizieren. Umgekehrt fördert eine Unternehmenskultur, in der Umsatz das wichtigste Ziel ist, und in der entsprechende Kennzahlen und Diagramme das zentrale Steuerungsvehikel sind, bei den kreativ und konzeptionell arbeitenden Menschen auf der Umsetzungsebene eher innere Distanz zum eigenen Tun.

Fordern, wenn es sinnvoll ist

Das Schöne ist: Wenn Teams sich mit ihren Zielen identifizieren, kann Leistung durchaus eingefordert werden, sogar über das gewöhnliche Maß hinaus. Den Over-Nighter, wenn ein Feature einfach fertig werden muss, oder wenn ein unvorhergesehenes Problem den Produktivgang verzögert, haben die meisten Softwareentwickler:innen schon erlebt. Bei echter Identifikation mit dem eigenen Tun ist so etwas absolut möglich. Der Witz ist ja: Es fühlt sich – ausreichend Erholungsphasen vorausgesetzt – gut an, über die eigenen Grenzen hinaus zu gehen, um etwas zu leisten, das man vorher für unmöglich gehalten hat. Je umfassender ich meine kreative Energie in die Aufgabe gießen kann, desto besser, selbst wenn die Trägheit der Masse und eine gewisse Bequemlichkeit mir vorher sagen werden: Streng dich nicht an. Schlagkraft heißt eben auch Lust zu schaffen. Es versteht sich von selbst, dass sich davon niemand dazu verleiten lassen sollte, ein Team zu verbrennen. Regelmäßige Überlastungsphasen sind desktruktiv und deuten auf Defizite in der Planung oder im Prozess hin, die unbedingt behoben werden müssen.

Knappheit als Ansporn

Die Fülle der finanziellen Mittel ist in der IT verglichen mit vielen anderen Branchen noch immer enorm. Unser Beruf kann deshalb sehr bequem sein. Machen uns unsere hohen Gehälter produktiver? — Es gibt ein schönes Zitat von Leonard Bernstein: „Um etwas großes zu schaffen, braucht es zwei Dinge: Eine gute Idee, und zu wenig Zeit.“ Ressourcen sind immer begrenzt – aber vorausgesetzt, was ich tun will ist wirklich „groß“ (oder in unserem Kontext: sinnvoll und erstrebenswert), kann gerade das Bewusstsein, dass „es knapp wird“, einen ungemeinen Energieschub bewirken. Wenn also die Zeit drängt, dann gilt es, das Bewusstsein dafür bis in die Teams hinein zu tragen – aber bitte mit Begründung! „Wir haben richtig Stress weil X sich Ende des Quartals im Steuerungskommitee vor Y verantworten muss“ – na ja, hoffen wir, dass die Teammitglieder X mögen…

Entscheidungsfreude

Softwareentwicklung ist eine Abfolge von fachlichen und technischen Entscheidungen, durchsetzt von Phasen, in denen Entscheidungen umgesetzt, getestet, angepasst, oder verworfen werden. Wenn Entscheidungen zu lange dauern, oder gar regelmäßig in der Befehlskette nach oben delegiert werden, dann ist etwas faul. Zwei mögliche Ursachen sind (a) vertikal, also als Machtgefälle verstandene Hierarchien, verbunden mit dem Misstrauen, dass „das Management“ Entscheidungen nicht mittragen wird und (b) mangelndes Vertrauen der Teammitglieder untereinander, das dazu führt, dass zu viele Personen in Entscheidungsprozesse eingebunden sein wollen. Ersteres ist, wenn der Zustand chronisch ist, wahrscheinlich ohne externe Unterstützung nicht mehr zu lösen. Für letzteres hilft, ein Bewusstsein dafür zu schaffen, dass die Aufteilung (nicht primär von Aufgaben-, sondern) von Verantwortungsbereichen ein Team langfristig effizienter macht, und kein Zeichen von Misstrauen in die Fähigkeiten einzelner Teammitglieder ist. Der Kerngedanke von „wir machen das gemeinsam“ ist nicht „wir beschäftigen zehn Gehirne mit Problemen, für die zwei Gehirne ausreichend wären“, sondern „wir koordinieren die Arbeit von zehn Gehirnen so, dass die Lösungen für die sieben Probleme, die sie auf unterschiedlichen Ebenen bearbeitet haben, am Ende gut ineinandergreifen“.

In Köpfe investieren

Zu guter Letzt ein Aufruf, der uns bei INNOQ am Herzen liegt, und der als Quintessenz all dieser Überlegungen gelten kann: Das größte Kapital eines digital souveränen Unternehmens sind seine Mitarbeiter:innen. In ihre Intelligenz, in ihre fachliche und technische Kompetenz, in ihre Problemlösungsfähigkeiten und Lernbereitschaft, in ihre Vertrautheit mit modernen Werkzeugen, aber auch in ihr persönliches Wachstum, in ihre Begeisterungsfähigkeit und Resilienz zu investieren, zahlt sich langfristig aus. Teams, die gemeinsam lernen und die Mittel bekommen, an ihren gegenwärtigen Herausforderungen tatsächlich zu wachsen, werden die kommenden Herausforderungen besser bewältigen, und die dann folgenden noch besser, und so weiter. Ich will wissen, dass das Unternehmen, dessen Zielen ich einen großen Teil meiner Lebenszeit widme, nicht nur meine Arbeitskraft mietet, sondern mit mir eine langfristige Partnerschaft eingeht. Ich will, dass dieses Unternehmen ein Interesse daran hat, dass ich meine Fähigkeiten stärke und neue gewinne – zu unser beider Nutzen! Dann wird aus „ich arbeite für euch und ihr bezahlt mich dafür“ ein echtes Geben und Nehmen, und ich mache mir die Ziele des Unternehmens nach und nach zu eigen. Wenn es einer Organisation im Bereich der digitalen Industrie gelingt, so eine Dynamik mit möglichst vielen ihr angehörenden Personen zu entwickeln, dann trägt langfristig das immer schlagkräftigere Zusammenwirken der Einzelpersonen signifikant zur konstruktiv verstandenen digitalen Souveränität der Organisation bei.

1: Die folgenden Beobachtungen sind auf kreativ und konzeptionell arbeitende Teams jedweder Art anwendbar. Wir beschränken uns hier aufgrund eigener Vertrautheit und im Sinne der Gegenständlichkeit auf die Domäne Softwareentwicklung.

2: Im militärischen Kontext käme niemand auf die Idee, Entscheidungen, die innerhalb von Minuten, vielleicht Sekunden getroffen werden müssen, einem Kommitee zu übertragen. Und die Berliner Philharmoniker, ein Team von hochspezialisierten Handwerkern von Weltrang, entscheiden nicht basisdemokratisch, wie Brahms IV gespielt werden soll. Warum? Weil sie wissen, dass sie für ein sehr mediokres Ergebnis unendlich viel Zeit in Diskussionen verbrennen würden: Zeit, die es in der Branche Kultur nicht gibt, ganz einfach, weil es kein Geld gibt.

Fazit

Digitale Souveränität ist kein Synonym für technologische Unabhängigkeit. Letztere ist vielmehr ein natürlicher Nebeneffekt von Souveränität im konstruktiven Sinne, also von hoher intellektueller und organisatorischer Problemlösungskapazität. Wer diese fördern will, muss bei den Menschen und Teams ansetzen, die die eigentliche Arbeit machen. Individuelle und kollektive Schlagkraft als undefinierbare aber evokative Eigenschaft souveräner Teams kann nicht direkt gesteuert, aber durch vorteilhafte Randbedingungen langfristig gefördert werden. Wie genau? Das ist ohne genaue Kenntnis der Menschen und organisatorischen Eigenheiten unmöglich zu sagen.

Fragen für den Anfang:

  • Welche Art von Vertrauen möchte ich selbst entgegengebracht bekommen?
  • Welche Prozesse und Organisationsstrukturen sind bei uns komplizierter als nötig?
  • Welche Metriken brauche ich wirklich?
  • Was ist mir wichtig, wie deckt sich das mit den Werten meiner Organisation, und wie können wir gemeinsam dafür sorgen, dass diese Werte glasklar und unmittelbar begreiflich sind?

Autor: Florian Kretlow, Senior Consultant, INNOQ Deutschland GmbH

Dieser Artikel ist Teil des INNOQ Technology Briefings – unserem Report für Technologieentscheider:innen. Jetzt herunterladen und mehr zum Thema digitale Souveränität erfahren.

Über die innoQ Deutschland GmbH

INNOQ ist ein Technologie-Beratungsunternehmen. Wir beraten ehrlich, denken innovativ und entwickeln leidenschaftlich gern. Das Ergebnis sind erfolgreiche Softwarelösungen, Infrastrukturen und Geschäftsmodelle. Unsere Leistungen teilen sich in folgende Schwerpunkte auf:

– Strategie- und Technologieberatung
– Softwarearchitektur und -entwicklung
– Data & AI
– Entwicklung digitaler Produkte
– Digitale Plattformen und Infrastrukturen
– Wissenstransfer, Coaching und Trainings

Unsere Standorte sind Monheim (bei Düsseldorf), Berlin, Hamburg, Zürich, Offenbach, Köln und München.

Firmenkontakt und Herausgeber der Meldung:

innoQ Deutschland GmbH
Krischerstr. 100
40789 Monheim am Rhein
Telefon: +49 (2102) 77162-100
Telefax: +49 (2102) 7716-01
http://www.innoq.com

Ansprechpartner:
Stefanie Heinrich
Head of Marketing
E-Mail: stefanie.heinrich@innoq.com
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

Der Weg zur heterogenen Cloud Plattform

Der Weg zur heterogenen Cloud Plattform

Die digitale Transformation bringt für Unternehmen sowohl Herausforderungen als auch Chancen mit sich. Um zukunftssichere und flexible IT-Infrastrukturen zu schaffen, setzen immer mehr Unternehmen auf Multi-Cloud- oder hybride Cloud-Strategien. Hierbei geht es nicht nur um Kostenreduktion, sondern auch darum, innovative Dienste verschiedener Anbieter mit regulatorischen Anforderungen – insbesondere im Bereich Datenschutz – in Einklang zu bringen. Dieser Artikel zeigt Ihnen, wie Sie mit gezielten Integrationsstrategien die Vorteile von Multi-Cloud nutzen können, um Ihre bestehende Infrastruktur zu optimieren, technische Abhängigkeiten zu reduzieren und dabei den geschäftlichen Erfolg langfristig zu sichern.

Viele Unternehmen stehen bei der Integration von On-Premise-Systemen mit Cloud-Plattformen vor erheblichen Herausforderungen – insbesondere, wenn neue Infrastrukturen organisatorisch und technisch eingeführt werden. Diese Transformationen waren in der Regel mit großen Herausforderungen verbunden, vor allem in Bezug auf den organisatorischen und technischen Umgang mit neuen Cloud-Infrastrukturen. Ein unüberlegter Strategiewechsel birgt Risiken: Er kann Transformationsprojekte gefährden und wertvolle Ressourcen binden.

Statt bestehende Strategien zu ersetzen, ist es sinnvoller, die Cloud-Infrastruktur gezielt zu erweitern, indem mehrere Anbieter integriert werden. Beispielsweise kann die Kombination einer US-Cloud und europäischer Cloud-Anbieter Unternehmen den Zugriff auf innovative Dienste sichern und gleichzeitig sicherstellen, dass regulatorische Vorgaben – etwa im Bereich Datenschutz – eingehalten werden. So entsteht eine flexible, zukunftssichere Plattform, die sowohl den geschäftlichen als auch den technischen Anforderungen gerecht wird.

Grundlagen der Multi-Cloud-Verbindung: Der erste Schritt zur Integration

Auf den ersten Blick mögen die notwendigen Schritte und Technologien zur Nutzung mehrerer Cloud-Anbieter komplex erscheinen. Doch die gute Nachricht ist: Die meisten Ansätze und Tools dafür existieren bereits und werden zum Teil direkt von den Cloud-Anbietern bereitgestellt. Nahezu alle Anbieter stellen Dienste bereit, um ein On-Premise-Netzwerk mit der Cloud effizient zu verbinden – dieselben Lösungen lassen sich auch einsetzen, um Netzwerke zwischen verschiedenen Cloud-Anbietern aufzubauen.

Nachdem die Netzwerkverbindung zwischen Cloud-Anbietern als zentrale technische Voraussetzung keine nennenswerte Herausforderung ist, stellt sich die Frage: Wie lassen sich Anwendungen und Daten geschäfts- und regelkonform in eine heterogene Cloud-Infrastruktur integrieren?

Im Folgenden betrachten wir zwei unterschiedliche Strategien – die API-Only-Integration und die Data-Only-Integration –, die Ihnen helfen kann, technische und regulatorische Anforderungen reibungslos in Einklang zu bringen.

API-Only-Integration: Die einfache Lösung für modulare Systeme

Diese Integrationsvariante eignet sich besonders für Systeme, die auf Anwendungsebene modular aufgebaut sind, wie z. B. Microservices oder Self-Contained Systems (SCS). In diesem Ansatz wird die Logik in einem separaten System implementiert. Je nach Komplexität kann dies durch die Entwicklung eines Microservices oder eines vollständig neuen SCS realisiert werden.

Die API-Only-Integration ist dabei die einfachste Art der Integration, da sie keine direkte Netzwerkverbindung über VPN zwischen den beteiligten Systemen voraussetzt. APIs können über das Internet aufgerufen und durch entsprechende Sicherheitsmaßnahmen geschützt werden. Dies reduziert die infrastrukturellen Anforderungen und ermöglicht eine flexible Verbindung zwischen den beteiligten Komponenten.

Auch das Deployment gestaltet sich unkompliziert, da die jeweiligen Bereitstellungsmechanismen der genutzten Cloud-Anbieter direkt verwendet werden können. Ein bedeutender Vorteil dieser Variante ist ihre Flexibilität: API-Only-Integrationen ermöglichen sowohl den Zugriff von europäischen Clouds auf US-basierte Dienste als auch umgekehrt.

Die API-Only-Integration ist eine hervorragende Wahl für modular aufgebaute Systeme, die eine hohe Agilität und Flexibilität erfordern. Sie bietet eine einfache Möglichkeit, unabhängige Services miteinander zu verknüpfen. Allerdings sollten Unternehmen sicherstellen, dass die API-Integrationen robust gegen Latenz und Sicherheitsrisiken sind, insbesondere bei sensiblen Daten oder längeren Netzwerkstrecken. Genau hier setzt die Data-Only-Integration an, die sich stärker auf die Datenhaltung und spezielle regulatorische Anforderungen fokussiert.

Data-Only-Integration: Die Herausforderung der Multi-Cloud-Datenhaltung

Eine Data-Only-Integration erfordert besondere Voraussetzungen und Abwägungen. Vor der Umsetzung muss geprüft werden, ob eine kurzfristige Speicherung der Daten in einem Fremdsystem, z. B. aus technischen Gründen wie Caching, zulässig ist. Außerdem sind mögliche Auswirkungen auf Qualitätsziele zu evaluieren, da VPN-Tunnel tendenziell langsamer sind als eine Standleitung. Aktuell bietet keine Cloud eine Standleitung zu einer anderen Cloud an. Die Verbindung muss zudem redundant aufgebaut werden, um Ausfälle zu vermeiden.

Bei dieser Variante liegt der Fokus darauf, wo die Daten gespeichert werden. Sie ermöglicht es, flexibel auf Anforderungen zu reagieren, wie z. B. der verpflichtenden Speicherung sensibler Daten in einer europäischen Cloud. Zusätzlich erleichtert diese Methode eine spätere Migration der Anwendung in eine andere Cloud-Umgebung. Ein weiterer Anwendungsfall ist, wenn ein notwendiger Dienst in der US-Cloud verfügbar ist, jedoch (noch) nicht in einer europäischen Cloud angeboten wird.

Im Gegensatz zur API-Only-Integration vermeidet die Data-Only-Integration eine unnötige Aufteilung der Anwendung in mehrere Deployment-Einheiten, was zusätzliche Komplexität (wie strikte Reihenfolgen beim Deployment oder eine Verteilung des Datenmodels) mit sich bringen würde. Stattdessen wird ausschließlich die Datenhaltung in der europäischen Cloud realisiert, während die Komponenten mit der Applikationslogik in der US-Cloud betrieben werden. Da Datenbankzugriffe kritische Schnittstellen darstellen, die die Qualitätsziele unmittelbar beeinflusst, ist eine stabile Netzwerkverbindung essenziell. Die sichere direkte Anbindung von Datenbanken über das Internet ist zwar technisch möglich, birgt jedoch hohe Sicherheitsrisiken.

Zum Umsetzen der Datenhaltung aus einer anderen Cloud stehen verschiedene Lösungsansätze zur Verfügung, abhängig von der eingesetzten Technologie und den Anforderungen an Performance, Verfügbarkeit sowie der Richtlinie zur temporären Datenspeicherung. So können beispielsweise ganze Datenbanken in einem anderen Netzwerk bei einem anderen Anbieter betrieben werden. Dies stellt eine einfache Lösung dar, kann jedoch zu Performance-Einbußen führen, die durch Caching oder den Einsatz von Read-Instanzen kompensiert werden können.

Eine andere Möglichkeit besteht in der Nutzung von sogenannten „Remote-Tables“ bei unterstützenden Datenbanksystemen. Hierbei wird lediglich ein spezifischer Teil des Datenmodells – wie beispielsweise Tabellen mit sensiblen Daten – in eine andere Cloud ausgelagert. Dieser Ansatz ist für die Anwendung transparent und begrenzt potenzielle Latenzprobleme auf einen kleinen Teil des Datenmodells.

Die Umsetzung dieser Variante erfordert aufgrund der Abhängigkeiten und technischen Anforderungen etwas mehr Aufwand im Deployment. Lösungen wie „Infrastructure as Code“ (IaC) und die Unterstützung eines dedizierten Plattform-Teams sind hier entscheidend. Sie ermöglichen es, externe Datenhaltung nahtlos in die bestehende Infrastruktur zu integrieren. Manche US-Cloud-Anbieter bieten sogar erweiterbare IaC-Lösungen an, um Ressourcen in fremden Umgebungen bereitzustellen und so die Komplexität zu minimieren.

Strategievergleich: Beide Strategien im Überblick

Die Wahl der passenden Integrationsstrategie hängt stark von den Anforderungen Ihres Unternehmens ab. Im Idealfall können beide Ansätze kombiniert werden, um sowohl technologische als auch regulatorische Anforderungen effizient und flexibel zu erfüllen.

Die Data-Only-Integration ist ideal, um bestehende Systeme schnell und flexibel an neue Anforderungen – wie die Speicherung sensibler Daten in einer bestimmten Region – anzupassen. Im Gegensatz dazu eignet sich die API-Only-Integration hervorragend für die Integration neuer Systeme oder von Alt-Systemen, die in eine moderne Architektur migriert werden.

Von einer künstlichen Aufteilung in isolierte Systeme rate ich dringend ab, da dies zusätzliche Komplexität und potenzielle Probleme verursachen kann. Eine klare und zielgerichtete Strategie ist entscheidend für den Erfolg.

Ein Überblick über die beiden Integrationsarten und ihre Eigenschaften:

API-Only-Integration

  • Zielsetzung: Integration von Cloud-Anbietern über die Bereitstellung von Schnittstellen.
  • Architekturvoraussetzungen: Perfekt für modulare Systeme wie Microservices und SCS.
  • Einschränkungen: Gefahr einer künstlichen Systemaufteilung, falls eine Abhängigkeit zu einem Cloud-Anbieter besteht.
  • Deployment: Nutzung nativer Technologien der jeweiligen Cloud-Anbieter.

Data-Only-Integration

  • Zielsetzung: Speicherung der Daten bei verschiedenen Cloud-Anbietern.
  • Architekturvoraussetzungen: Systeme, die eine Datenhaltung in einer anderen Cloud erfordern; geeignet zur Vorbereitung eines Cloud-Wechsels.
  • Einschränkungen: Datenschutzanforderungen und Qualitätsziele (z.B. Latenz, Verfügbarkeit) müssen berücksichtigt werden.
  • Deployment: Integration externer Ressourcen über „Infrastructure as Code” (IaC).

Hiermit können Sie besser abschätzen, welche Strategie – API-Only oder Data-Only – für Ihre spezifischen Anwendungsfälle sinnvoll ist. Wichtig ist, dass Sie eine klare Richtung für Ihre Integrationsstrategie festlegen und unnötige Komplexität vermeiden.

Handlungsempfehlungen

Die Integration mehrerer Cloud-Anbieter in eine heterogene Plattform bietet Unternehmen enorme Chancen, sowohl technische als auch regulatorische Anforderungen zu adressieren. Die beiden vorgestellten Integrationsstrategien – die API-Only-Integration und die Data-Only-Integration – eröffnen flexible Möglichkeiten, bestehende Systeme anzupassen und neue Lösungen in einer hybriden Architektur effizient zu gestalten.

Die wichtigsten Punkte lassen sich zusammenfassen:

  • API-Only-Integration ermöglicht eine schnelle und modulare Verbindung zwischen Cloud-Diensten und eignet sich ideal für neue und migrierte Systeme.
  • Data-Only-Integration bietet eine effektive Möglichkeit, die Datenhaltung an gesetzliche Vorgaben anzupassen und Systeme ohne unnötige Aufteilung flexibel zu erweitern.
  • Beide Ansätze können kombiniert werden, um sowohl technische als auch organisatorische Ziele effizient zu erreichen.

Ein klarer und durchdachter Plan ist der Schlüssel zur erfolgreichen Umsetzung. Vermeiden Sie jedoch unnötige Komplexität, etwa durch die Aufteilung geschlossener Systeme, da dies die Entwicklungs-, Wartungs- und Betriebskosten erhöhen kann.

1. Analyse Ihrer Anwendungen: Identifizieren Sie, welche Anwendungen betroffen sind, und bewerten Sie ihre Abhängigkeit von spezifischen Cloud-Diensten.

2. Evaluierung der Anbieter: Prüfen Sie, welcher europäische Cloud-Anbieter die besten Dienste für Ihre Anforderungen bietet. Achten Sie dabei insbesondere auf die Erfüllung gesetzlicher Anforderungen, wie z. B. Datenschutz.

3. Segmentierung der Dienste: Überlegen Sie, welche Dienste oder Daten in eine europäische Cloud migriert werden können und welche in ihrer bestehenden Umgebung verbleiben müssen.

4. Planung der Integration: Entscheiden Sie auf Basis Ihrer Analyse, wo sich API-Only- oder Data-Only-Integrationen am besten umsetzen lassen. Führen Sie dazu eine Machbarkeitsbewertung durch, die Performance, Sicherheitsstandards und Latenz berücksichtigt.

5. Einbindung eines Plattform-Teams: Stellen Sie sicher, dass Sie über ein erfahrenes Team verfügen, das „Infrastructure as Code“ (IaC) nutzen kann, um eine nahtlose Integration und effizientes Deployment zu gewährleisten.

Fazit

Abschließender Tipp: Starten Sie mit einem Pilotprojekt. Wählen Sie eine Anwendung oder einen Dienst mit überschaubarem Risiko aus, um erste Erfahrungen mit der heterogenen Cloud-Infrastruktur zu sammeln. Skalieren Sie anschließend auf Basis der dort gewonnenen Erkenntnisse. Mit einer schrittweisen Vorgehensweise und klar definierten Rahmenbedingungen wird es Ihnen gelingen, eine erfolgreiche und anpassungsfähige Cloud-Strategie zu implementieren.

Sobald es Ihnen gelingt, erfolgreich zwei Cloud-Anbieter zu integrieren, ist der nächste Schritt zur Einbindung weiterer Anbieter naheliegend – insbesondere für Unternehmen, die ihre Cloud-Strategie zukunftssicher gestalten möchten.

Ein wesentlicher strategischer Vorteil ergibt sich daraus, dass europäische Cloud-Anbieter zwar einzeln oft ein eingeschränkteres Dienstportfolio haben als etwa große US-Anbieter, sie jedoch zusammen eine ähnliche Vielfalt abdecken können. Während ein Anbieter unter anderem mit fortschrittlichen KI-Diensten überzeugt, bietet ein anderer starke Lösungen für klassische Laufzeitumgebungen.

Durch eine Multi-Cloud-Strategie können Unternehmen somit gezielt die besten Dienste verschiedener Anbieter kombinieren, um nicht nur die technologische Bandbreite zu maximieren, sondern auch eine kosteneffiziente Lösung zu implementieren. Dies reduziert die unternehmerische Abhängigkeit („Vendor Lock-in“) von einem einzelnen Anbieter erheblich und bietet zugleich die Flexibilität, auf regulatorische Anforderungen oder Marktveränderungen flexibel zu reagieren.

Neben der technologischen Optimierung erlaubt die Multi-Cloud-Strategie auch eine Optimierung der Gesamtkosten: Der Wettbewerb zwischen den Anbietern eröffnet zusätzlichen Spielraum für eine kostengünstige Gestaltung Ihrer Plattform ohne Kompromisse bei der Funktionalität.

Mit einer erfolgreichen Multi-Cloud-Strategie legen Sie den Grundstein für eine resiliente, skalierbare und anpassungsfähige IT-Infrastruktur, die den wandelnden Anforderungen Ihres Unternehmens gerecht wird – auf technischer, regulatorischer und wirtschaftlicher Ebene.

Autor: Philipp Beyerlein, Senior Consultant, INNOQ Deutschland GmbH

Dieser Artikel ist Teil des INNOQ Technology Briefings – unserem Report für Technologieentscheider:innen. Jetzt herunterladen und mehr zum Thema digitale Souveränität erfahren.

Über die innoQ Deutschland GmbH

INNOQ ist ein Technologie-Beratungsunternehmen. Wir beraten ehrlich, denken innovativ und entwickeln leidenschaftlich gern. Das Ergebnis sind erfolgreiche Softwarelösungen, Infrastrukturen und Geschäftsmodelle. Unsere Leistungen teilen sich in folgende Schwerpunkte auf:

– Strategie- und Technologieberatung
– Softwarearchitektur und -entwicklung
– Data & AI
– Entwicklung digitaler Produkte
– Digitale Plattformen und Infrastrukturen
– Wissenstransfer, Coaching und Trainings

Unsere Standorte sind Monheim (bei Düsseldorf), Berlin, Hamburg, Zürich, Offenbach, Köln und München.

Firmenkontakt und Herausgeber der Meldung:

innoQ Deutschland GmbH
Krischerstr. 100
40789 Monheim am Rhein
Telefon: +49 (2102) 77162-100
Telefax: +49 (2102) 7716-01
http://www.innoq.com

Ansprechpartner:
Stefanie Heinrich
Head of Marketing
E-Mail: stefanie.heinrich@innoq.com
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

Governance-Methodik für digitale Souveränität

Governance-Methodik für digitale Souveränität

In einer zunehmend vernetzten Welt, in der digitale Infrastrukturen das Rückgrat unserer Wirtschaft und Gesellschaft bilden, rückt das Thema der digitalen Souveränität immer stärker in den Fokus. Für Entscheider:innen im deutschsprachigen Raum geht es dabei um weit mehr als die reine Auswahl von Cloud-Anbietern. Es geht um strategische Handlungsfähigkeit, Resilienz und die Fähigkeit, die eigene digitale Zukunft aktiv zu gestalten. Dieser Artikel beleuchtet, wie eine robuste Governance-Methodik Unternehmen dabei unterstützen kann, digitale Souveränität nicht nur zu verstehen, sondern auch praktisch umzusetzen – ohne dabei Komfort oder Innovationskraft einzubüßen.

Digitale Souveränität: Ein vielschichtiger Ansatz

Der Begriff der digitalen Souveränität wird oft auf die Frage reduziert, ob Daten in europäischen Rechenzentren liegen oder ob Software von europäischen Anbietern stammt. Dies ist zweifellos ein wichtiger Aspekt, greift aber zu kurz. Digitale Souveränität ist ein multidimensionales Konzept, das tief in die operationellen und strategischen Entscheidungsprozesse von Unternehmen hinein wirkt. Sie beeinflusst nicht nur die technologische Landschaft, sondern hat weitreichende Auswirkungen auf die interne Governance und das Staffing von internen, aber auch externen Mitarbeiter:innen. Die Kernfrage, die sich Unternehmen stellen müssen, ist: Wer hat zu welchem Zeitpunkt welche Kontrolle über unsere kritischen digitalen Assets und Prozesse? Diese Kontrolle geht über rein technische Aspekte hinaus und umfasst juristische, organisatorische und personelle Dimensionen. Wenn wir beispielsweise interne Teams oder externe Dienstleister beauftragen, müssen wir uns klar machen, welche Verantwortlichkeiten wir abgeben und welche wir behalten wollen. Dies erfordert eine präzise Definition von Verantwortlichkeiten und deren Grenzen.

Verantwortlichkeiten verorten und abgrenzen: Der Schlüssel zur Kontrolle

Eine effektive Governance-Methodik im Kontext digitaler Souveränität beginnt mit der klaren Verortung und Definition von Verantwortlichkeiten. Es ist entscheidend zu verstehen, welche Teile der digitalen Wertschöpfungskette kritisch für die eigene Handlungsfähigkeit sind und wo Abhängigkeiten bestehen. Hier spielen Fragen der Verfügbarkeit, des Datenschutzes, der Datensicherheit und der strategischen Relevanz eine zentrale Rolle.

Konkrete Ansatzpunkte für die Verantwortungsabgrenzung sind:

  • Definition von Domänen und Verantwortungsbereichen: Unternehmen sollten ihre Geschäftsprozesse in klare Domänen unterteilen. Jede Domäne sollte eine oder mehrere verantwortliche Einheiten (Teams, Abteilungen) haben, die für die digitale Souveränität innerhalb dieser Domäne zuständig sind. Dies kann sich in Form von eigenständigen Systemen oder Services manifestieren, die eine hohe Autonomie und damit auch Kontrollierbarkeit ermöglichen.
  • Klare Schnittstellen und Verträge: Wenn Verantwortlichkeiten delegiert werden, sei es an interne Teams oder externe Partner:innen, müssen die Schnittstellen und die damit verbundenen Service Level Agreements (SLAs) und Verträge detailliert ausgearbeitet werden. Dies gilt insbesondere für Aspekte wie Datenhaltung, Zugriffsberechtigungen, Auditierbarkeit und Exit-Strategien.
  • Regelmäßige Überprüfung und Auditierung: Die einmalige Definition von Verantwortlichkeiten ist nicht ausreichend. Eine fortlaufende Überprüfung und Auditierung der Umsetzung ist notwendig, um sicherzustellen, dass die definierten Grenzen eingehalten werden und die gewünschte Souveränität gewahrt bleibt.

Vendor Management unter dem Aspekt digitaler Souveränität

Die Auswahl von Vendoren ist ein kritischer Hebel zur Gestaltung digitaler Souveränität. Über die rein funktionalen und Kostenaspekte hinaus sollten Unternehmen Klassifizierungen einführen, die die digitale Souveränität explizit berücksichtigen.

Mögliche Klassifizierungskriterien könnten sein:

  • Strategische Relevanz: Wie kritisch ist der Dienst oder das Produkt des Vendors für unsere Kernprozesse und unsere zukünftige Innovationsfähigkeit? Gleiches gilt für die Domänen, in denen man mit Unterstützung von externen Vendoren Software entwickeln lässt. Eine hohe strategische Relevanz erfordert eine engere Kontrolle und eine höhere Sensibilität für Souveränitätsfragen.
  • Resilienz und Ausfallsicherheit: Wie robust ist der Vendor gegenüber geopolitischen Veränderungen, Cyberangriffen oder Naturkatastrophen? Dies beinhaltet die Überprüfung der Infrastruktur, der Sicherheitskonzepte und der Notfallpläne.
  • Datenschutz und Compliance: Entspricht der Vendor den geltenden Datenschutzbestimmungen (z.B. DSGVO) und anderen relevanten regulatorischen Anforderungen (z.B. DORA, NIS-2)? Hier ist ein besonderer Fokus auf die physische Lokation der Daten und die juristische Gerichtsbarkeit des Anbieters zu legen.
  • Lieferkettenrisiken: Welche Abhängigkeiten bestehen in der Lieferkette des Vendors selbst? Woher stammen die Komponenten und Dienstleistungen, die der Vendor zur Verfügung stellt?
  • Lock-in-Potenzial: Wie leicht ist es, von einem Vendor zu einem anderen zu wechseln oder eine Lösung inhouse zu betreiben? Open-Source-Lösungen oder offene Standards können hier Vorteile bieten.
  • Transparenz und Auditierbarkeit: Wie transparent ist der Vendor hinsichtlich seiner Prozesse, Sicherheitsmaßnahmen und seiner eigenen Governance? Sind Audits durch unabhängige Dritte möglich? Diese Klassifizierungen sollten nicht nur bei der Erstauswahl, sondern auch während der gesamten Vertragslaufzeit regelmäßig überprüft werden. Unternehmen können hier Checklisten und Scoring-Modelle entwickeln, die in den Beschaffungsprozess integriert werden.

Wardley Maps als strategisches Hilfsmittel

Um die Komplexität der digitalen Souveränität zu handhaben und strategische Entscheidungen zu treffen, können visuelle Werkzeuge wie Wardley Maps einen wertvollen Beitrag leisten. Wardley Maps ermöglichen es, die Wertschöpfungskette eines Unternehmens zu visualisieren und die Evolution ihrer Komponenten von "Genesis" über "Custom Build" und "Product" hin zu "Commodity" darzustellen.

Wie Wardley Maps im Kontext digitaler Souveränität helfen können:

  • Abhängigkeiten sichtbar machen: Wardley Maps zeigen explizit, welche Komponenten (z.B. Cloud-Dienste, Software-Lösungen, Infrastruktur) das Unternehmen nutzt und wie sie miteinander verbunden sind. Dies hilft, strategisch relevante Abhängigkeiten zu identifizieren, die möglicherweise ein Souveränitätsrisiko darstellen.
  • Risiken bewerten: Indem man die Reife und den Grad der Kommoditisierung von Komponenten analysiert, kann man potenzielle Lock-in-Effekte oder fehlende Alternativen erkennen. Eine reife, als Commodity verfügbare Komponente birgt in der Regel weniger Souveränitätsrisiken als eine hochspezialisierte, kundenspezifische Lösung.
  • Alternativen identifizieren: Die Map kann aufzeigen, wo europäische Alternativen oder Open-Source-Lösungen existieren, die ein höheres Maß an Souveränität bieten könnten (z.B. GAIA-X, Matrix-Protokoll, Nextcloud, STACKIT oder OVHCloud).
  • Strategische Entscheidungen ableiten: Basierend auf der Map können Unternehmen entscheiden, welche Komponenten sie selbst entwickeln, welche sie einkaufen, welche sie als Commodity betrachten und wo sie gegebenenfalls auf europäische Anbieter umsteigen sollten. Dies kann auch die Entscheidung beeinflussen, ob man eine Komponente selbst betreibt oder als Managed Service einkauft.
  • Kommunikation mit Stakeholder:innen: Die visuelle Natur der Wardley Maps erleichtert die Kommunikation komplexer Abhängigkeiten und strategischer Optionen mit verschiedenen Stakeholder:innen, von der Geschäftsführung bis zu den Entwicklungsteams.

Praktische Umsetzung im Unternehmen: Die digitale Zukunft aktiv gestalten

Die Umsetzung einer souveränen IT-Strategie erfordert mehr als nur technologische Anpassungen. Es ist ein kultureller Wandel, der organisatorische und personelle Hebel in Bewegung setzt.

Organisatorische Anpassungen:

  • Etablierung eines Souveränitäts-Boards: Ein interdisziplinäres Gremium aus IT, Recht, Einkauf und Business kann die Einhaltung der Souveränitätskriterien überwachen und strategische Entscheidungen koordinieren.
  • Stärkung von Autonomie und Verantwortlichkeit der Teams: Eine moderne Organisationsstruktur kann die Autonomie und Verantwortlichkeit der Teams stärken, was eine agile Berücksichtigung von Souveränitätsaspekten ermöglicht. Teams, die für spezifische Domänen verantwortlich sind, können eigenständig über die Umsetzung von Souveränitätsanforderungen entscheiden.
  • Förderung von interner Expertise: Um Abhängigkeiten zu reduzieren, ist der Aufbau von internem Know-how essenziell. Dies betrifft nicht nur technische Fähigkeiten, sondern auch Expertise in den Bereichen Recht, Compliance und Vendor-Management.

Technische Maßnahmen:

  • Architekturentscheidungen bewusst treffen: Ziel ist es, Architekturen zu schaffen, die Resilienz, Portabilität und Kontrolle ermöglichen.
  • Open Source und offene Standards: Der Einsatz von Open-Source-Lösungen und die Adhärenz an offene Standards können das Lock-in-Potenzial reduzieren und die Austauschbarkeit von Komponenten erleichtern.
  • Multi-Cloud und Hybrid-Cloud-Strategien: Eine Diversifizierung der Cloud-Anbieter kann das Risiko von Abhängigkeiten minimieren.

Kultureller Wandel:

  • Bewusstsein schaffen: Mitarbeiter:innen auf allen Ebenen müssen für die Bedeutung digitaler Souveränität sensibilisiert werden.
  • Experimentierfreude fördern: Ermutigen Sie Teams, europäische Alternativen oder Open-Source-Lösungen auszuprobieren und Best Practices zu teilen.
  • Kontinuierliches Lernen: Digitale Souveränität ist kein statisches Ziel, sondern ein fortlaufender Prozess.

Fazit

Unternehmen müssen bereit sein, kontinuierlich zu lernen und sich an neue Entwicklungen anzupassen. Digitale Souveränität ist kein "Nice-to-have", sondern eine strategische Notwendigkeit in der heutigen digitalen Landschaft. Sie bietet Unternehmen die Chance, resilienter, handlungsfähiger und zukunftssicher zu werden. Eine durchdachte Governance-Methodik, die über die reine technische Betrachtung hinausgeht und Aspekte wie Verantwortungsabgrenzung, Vendor-Management und strategische Planung mittels Tools wie Wardley Maps integriert, ist der Schlüssel zur erfolgreichen Gestaltung der eigenen digitalen Zukunft.

Dieser Artikel ist Teil des INNOQ Technology Briefings – unserem Report für Technologieentscheider:innen. Jetzt herunterladen und mehr zum Thema soziotechnische Architekturen erfahren.

Über den Autor:

Michael Plöd ist ein Fellow bei INNOQ. Seine derzeitigen Schwerpunkte sind Domain-driven Design, Team Topologies, sozio-technische Architekturen und die Transformation von IT-Organisationen in Richtung Collaboration und lose gekoppelte Teams. Michael ist Autor des Buches „Hands-on Domain-driven Design – by example” auf Leanpub, Übersetzer des Buches Team Topologies ins Deutsche für O’Reilly und ein regelmäßiger Speaker auf nationalen und internationalen Konferenzen.

 

Über die innoQ Deutschland GmbH

INNOQ ist ein Technologie-Beratungsunternehmen. Wir beraten ehrlich, denken innovativ und entwickeln leidenschaftlich gern. Das Ergebnis sind erfolgreiche Softwarelösungen, Infrastrukturen und Geschäftsmodelle. Unsere Leistungen teilen sich in folgende Schwerpunkte auf:

– Strategie- und Technologieberatung
– Softwarearchitektur und -entwicklung
– Data & AI
– Entwicklung digitaler Produkte
– Digitale Plattformen und Infrastrukturen
– Wissenstransfer, Coaching und Trainings

Unsere Standorte sind Monheim (bei Düsseldorf), Berlin, Hamburg, Zürich, Offenbach, Köln und München.

Firmenkontakt und Herausgeber der Meldung:

innoQ Deutschland GmbH
Krischerstr. 100
40789 Monheim am Rhein
Telefon: +49 (2102) 77162-100
Telefax: +49 (2102) 7716-01
http://www.innoq.com

Ansprechpartner:
Stefanie Heinrich
Head of Marketing
E-Mail: stefanie.heinrich@innoq.com
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

EU Data Act: Der Anfang vom Ende der Cloud-Monokultur?

EU Data Act: Der Anfang vom Ende der Cloud-Monokultur?

Was hat die EU jemals für uns getan? … also außer Reise- und Arbeitsfreiheit, Roaming-Abschaffung, Verbraucherschutz, Binnenmarkt, Erasmus und vielem mehr. Aber eben auch: überbordende Bürokratie, langsame Entscheidungsprozesse, Überregulierung bis hin zum überstrapazierten Flaschendeckel – längst Lieblingssymbol all jener, die Europa für jeden Innovationsrückstand verantwortlich machen.

Das nächste Thema, welches die Gemüter erhitzen dürfte, ist die EU-Datenverordnung (Verordnung (EU) 2023/2854, auch EU Data Act). Er wird strategische Bedeutung für europäische Unternehmen haben – und für alle, die in Europa wirtschaften wollen.

Wer 2025 Cloud-Infrastruktur in Europa betreibt, sitzt in der Regel auf amerikanischem Fundament. AWS, Azure (Microsoft) und Google Cloud kontrollieren große Teile der europäischen Unternehmens-IT – tief integriert, teils bewusst in Kauf genommen, teils zunehmend als Risiko erkannt. Ein Anbieterwechsel ist technisch aufwändig, teuer oder schlicht unrealistisch.

Genau hier setzen jene Teile der EU-Datenverordnung an, die wir uns näher anschauen wollen: der Kampf gegen Cloud-Lock-ins und strukturelle Abhängigkeit von US-Hyperscalern.

Vorweg: Ja, es wird reguliert. Ja, es wird Aufwand bedeuten – vor allem für die Großen. Aber darum soll es hier nicht gehen. Uns interessiert: Was könnte der Data Act positiv verändern – die negativen Seiten werden wahrscheinlich mit reichlich Flaschendeckelvergleichen auf LinkedIn besprochen.

Von Föderation zu Konzentration: Was schiefgelaufen ist

Die ursprüngliche Erwartung des Internets war ein Netzwerk vieler Rechner, betrieben von vielen Akteuren – technisch dezentral, offen, föderiert. Unternehmen setzten tatsächlich eine Zeit lang auf eigene Infrastruktur, betrieben Rechenzentren, Server und Netzwerke selbst – nicht aus Überzeugung, sondern weil es keine echte Alternative gab. Erst mit dem Aufstieg der Hyperscaler und ihren attraktiven Komplettangeboten verlagerte sich der Fokus: weniger Betrieb, mehr Fachlichkeit.

Heute ist die Public Cloud der Standard – nicht nur, weil sie den Betrieb vereinfacht, sondern weil ihre Angebote für Startups ebenso attraktiv sind wie für große Unternehmen: zum Start günstig, skalierbar, sofort verfügbar. Die Kosten sind oft minutiös aufgeschlüsselt – aber trotzdem selten intuitiv vorhersehbar. Kaum jemand baut heute freiwillig alles selbst – oft auch, weil das Know-how dafür fehlt.

Der Preis der Bequemlichkeit

Im europäischen Cloud-Markt dominieren heute im Wesentlichen drei US-Anbieter: AWS, Azure und Google Cloud. Viele Unternehmen nutzen deren Angebote seit Jahren, weil sie leistungsfähig, schnell verfügbar und gut integriert sind. Vendor-Lock-in wurde dabei oft bewusst in Kauf genommen.

Auch wenn zu Beginn auf offene Standards oder bekannte Open-Source-Produkte gesetzt wurde, schleichen sich über die Zeit proprietäre Dienste ein. Services wie AWS Lambda, Googles BigQuery oder Azure App Services sind bequem – aber schwer zu ersetzen, sobald sie Teil der Systemarchitektur sind. Ein Wechsel ist technisch möglich, aber selten realistisch, da aufwändig und vom Aufwand schwer abschätzbar.

Und selbst bei Diensten wie Amazon S3, das oft als portabel gilt, weil es zahlreiche S3-kompatible Nachimplementierungen gibt, entsteht Abhängigkeit auf einem anderen Weg: über das Preismodell. Wer große Datenmengen abziehen will, zahlt hohe Egress-Kosten. Das allein reicht in vielen Fällen, um den Wechsel wirtschaftlich unattraktiv zu machen.

Von Lock-in zu Exit-ready – regulatorisch verpflichtend

Genau an diesem Punkt greift die EU-Datenverordnung ein. Ziel ist es unter anderem, strukturelle Abhängigkeiten von einzelnen Cloud-Anbietern abzubauen – über verbindliche Rahmenbedingungen, deren Einhaltung auch durch Sanktionen durchgesetzt wird. Die Verordnung schreibt vor, dass Anbieter Interoperabilität sicherstellen müssen und technische Hürden für einen Wechsel aktiv beseitigen sollen.

Lock-in durch proprietäre Formate, inkompatible APIs oder absichtlich unklare Migrationspfade sollen damit nicht mehr möglich sein – jedenfalls nicht legal. Bestehende Hindernisse müssen laut Artikel 23 nachgebessert werden.

Mehr noch: Wenn die technischen Voraussetzungen für eine Migration gegeben sind, müssen Anbieter die Wechselkosten gering halten – und ab dem 12. Januar 2027 sogar vollständig darauf verzichten.

Für viele Entscheider:innen dürfte das genau zur richtigen Zeit kommen. Mit der neuen US-Regierung machte sich zu Beginn eine spürbare Unruhe breit – die oft völlige Abhängigkeit von US-Hyperscalern wurde plötzlich als echtes Risiko wahrgenommen.

Wahrscheinlich sind auch 2027 nicht alle APIs portabel, nicht alle Systeme austauschbar. Aber wer heute neue Services einführt, sollte sich fragen: Wie tief ist diese Lösung mit proprietären Mechanismen der Plattform verknüpft? Gibt es realistische Migrationspfade? Die Datenverordnung verpflichtet zwar künftig zur Interoperabilität – aber wie viel davon später nutzbar ist, hängt maßgeblich von den Architekturentscheidungen ab, die heute getroffen werden.

Wenn Infrastruktur beweglich wird – entstehen neue Spielräume

Mittelfristig bis langfristig könnten die neuen Vorgaben besonders für regulierte Unternehmen zum echten Vorteil werden. Finanzaufsichten verlangen seit Jahren, dass Exit-Szenarien technisch und organisatorisch vorbereitet sind. Bisher war das schwer umzusetzen – unter anderem, weil viele technische Voraussetzungen auf Seiten der Anbieter schlicht fehlten. Die EU-Datenverordnung schafft hier Klarheit: Anbieter werden verpflichtet, den Wechsel ihrer Kunden technisch zu ermöglichen und wirtschaftlich tragbar zu gestalten. Für CTOs bedeutet das: Wo Wechsel technisch möglich werden, rücken Exit-Fähigkeit und standardisierte Schnittstellen wieder in den Fokus – auch als Architektur-Entscheidung, nicht nur als langfristige Theorie.

Auch Multi-Cloud-Strategien könnten dadurch realistischer werden. Was heute oft an Schnittstellen, Inkompatibilitäten oder fehlender Portabilität scheitert, dürfte in Zukunft leichter lösbar sein. Für POs bedeutet das: Anbieterwechsel oder hybride Deployments könnten in Zukunft nicht nur technisch machbar sein – sondern auch roadmap-fähig.

Und wer jetzt selbst vor der Aufgabe steht, Data-Act-Anforderungen umzusetzen, sollte das nicht nur als Compliance-Projekt sehen. Es lohnt sich, die technischen Grundlagen zu nutzen, um intern sinnvolle Datenprodukte zu bauen – ein echter Mehrwert, nicht nur auf dem Papier.

Das betrifft auch Governance-Strukturen: Wenn Anbieterwechsel zukünftig nicht nur erlaubt, sondern durchsetzbar sind, müssen Ausschreibungen, Vertragslaufzeiten und Exit-Regeln neu gedacht werden – auch auf CIO-Ebene.

Vielleicht sorgt die EU-Datenverordnung am Ende nicht nur für weniger Lock-in, sondern auch dafür, dass europäische Cloud-Anbieter wie IONOS, OHVcloud oder Open Telecom Cloud endlich mehr sind als nette Alternativen in Fußnoten, da ein Wechsel einfacher geworden ist.

Viele technische Details des Data Acts sind noch offen. Was genau gilt als „Rohdaten“? Wer entscheidet, ob ein Anbieter technisch wirklich wechselbar ist – oder nicht? Auch das deutsche Durchführungsgesetz existiert bislang nur als Referentenentwurf der vorherigen Regierung. Einige Vorgaben greifen erst 2027, andere warten noch auf Präzisierung. Aber: wer jetzt wartet, verpasst die Chance, Systeme so zu gestalten, dass spätere Handlungsfähigkeit möglich ist – ohne panische Umbauten.

tl;dr – Was gilt, was kommt, was zu tun ist

Kostentreiber identifizieren und Alternativen prüfen.

Viele Cloud-Dienste sind über die Jahre zu festen Bestandteilen der Systemlandschaft geworden – oft aus wirtschaftlicher und technischer Vernunft, bislang jedoch kaum mit Blick auf Wechselbarkeit, weil ein Anbieterwechsel in der Praxis zu viele Hürden hatte. Jetzt ist ein sinnvoller Zeitpunkt, große Abhängigkeiten und Kostenpunkte sichtbar zu machen und zu bewerten, ob sich mittelfristig Alternativen lohnen könnten. Die Datenverordnung schafft erstmals einen regulatorischen Rahmen, der solche Überlegungen realistisch macht.

Cloud-Verträge auf Wechselhürden prüfen.

Viele bestehende Verträge enthalten Klauseln, die einen späteren Anbieterwechsel erschweren – etwa eingeschränkten Datenzugang, unklare Exit-Regelungen oder die ausschließliche Nutzung proprietärer Formate. Die Datenverordnung stärkt die Position von Kunden und schafft absehbar mehr Durchsetzungskraft, wenn solche Hürden den Wechsel faktisch verhindern.

Wichtige Termine:

  • 2. Januar 2024: Inkrafttreten der EU Datenverordnung / Verordnung (EU) 2023/2854
  • 12. September 2025
    • die EU-Datenverordnung gilt offiziell
    • Kapitel IV regelt missbräuchliche Vertragsklauseln beim Datenzugang und der Datennutzung zwischen Unternehmen – diese Vorgaben gelten ab sofort für alle neuen Verträge.
    • Kapitel III beschreibt die Pflichten von Dateninhabern, wenn sie laut Unionsrecht zur Bereitstellung von Daten verpflichtet sind – relevant ab jetzt für alle neuen Gesetze, die solche Pflichten enthalten.
  • 12. September 2026: Alle vernetzten Produkte und die dazugehörigen Dienste müssen die Vorgaben aus Artikel?3 Absatz?2 erfüllen. Das heißt: Nutzerinnen und Nutzer müssen vor Vertragsabschluss klar darüber informiert werden, welche Daten erzeugt werden können – inklusive Art, Format, Umfang, Echtzeitfähigkeit, Speicherort und -dauer, Zugriffsrechte, Löschmöglichkeiten sowie über die dafür vorgesehenen technischen Mittel und Nutzungsbedingungen.
  • 12. September 2027: Kapitel IV gilt auch für bestehende Verträge, die am oder vor dem 12.?September?2025 abgeschlossen wurden – wenn sie unbefristet sind oder mindestens bis zum 11.?Januar?2034 laufen.

Autor: Daniel Bornkessel, Senior Consultant INNOQ Deutschland GmbH

Dieser Artikel ist Teil des INNOQ Technology Briefings – unserem Report für Technologieentscheider:innen. Jetzt herunterladen und mehr zum Thema digitale Souveränität erfahren.

Über die innoQ Deutschland GmbH

INNOQ ist ein Technologie-Beratungsunternehmen. Wir beraten ehrlich, denken innovativ und entwickeln leidenschaftlich gern. Das Ergebnis sind erfolgreiche Softwarelösungen, Infrastrukturen und Geschäftsmodelle. Unsere Leistungen teilen sich in folgende Schwerpunkte auf:

– Strategie- und Technologieberatung
– Softwarearchitektur und -entwicklung
– Data & AI
– Entwicklung digitaler Produkte
– Digitale Plattformen und Infrastrukturen
– Wissenstransfer, Coaching und Trainings

Unsere Standorte sind Monheim (bei Düsseldorf), Berlin, Hamburg, Zürich, Offenbach, Köln und München.

Firmenkontakt und Herausgeber der Meldung:

innoQ Deutschland GmbH
Krischerstr. 100
40789 Monheim am Rhein
Telefon: +49 (2102) 77162-100
Telefax: +49 (2102) 7716-01
http://www.innoq.com

Ansprechpartner:
Stefanie Heinrich
Head of Marketing
E-Mail: stefanie.heinrich@innoq.com
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

INNOQ Technology Day 2025

INNOQ Technology Day 2025

Die Technologieberatung INNOQ mit Sitz in Monheim am Rhein lädt am 20. November 2025 zur sechsten Ausgabe des Technology Day ein. Mit jährlich mehr als 1.000 Teilnehmer:innen ist das Online-Event eine der größten IT-Konferenzen Deutschlands. Sie richtet sich an IT-Entscheider:innen, Software-Architekt:innen und Entwickler:innen, die sich über aktuelle Technologie-Trends und Best Practices austauschen möchten.

Praxisnahe Einblicke in aktuelle IT-Herausforderungen

Der Technology Day bietet mehr als 20 Sessions (Vorträge, Diskussionen und interaktive Trainings) in 6 parallelen Tracks zu den drängendsten Themen der Software-Entwicklung. Das Programm verbindet technische Deep Dives mit strategischen Perspektiven und basiert auf der praktischen Projekterfahrung der INNOQ-Expert:innen.

Programm-Highlights

Zwei Keynotes

"Increasing your skill in programming in the age of AI" mit Prof. Dr. Felienne Hermans (Vrije Universiteit Amsterdam): Die Informatikdidaktik-Professorin und Entwicklerin der Programmiersprache Hedy zeigt, wie KI die Art, wie wir Software entwickeln, fundamental verändert – und auf welche grundlegenden kognitiven Fähigkeiten es auch weiterhin ankommt. Hermans, Autorin des Buches "The Programmer’s Brain" und Preisträgerin des Niederländischen Preises für ICT-Forschung 2021, verbindet wissenschaftliche Erkenntnisse mit praktischen Ansätzen.

"Die Macht der Perspektive – Surreale 3D-Räume zwischen Hollywood und Hirngespinst" mit Till Nowak: Der Künstler und Filmemacher, bekannt für Kurzfilme wie The Centrifuge Brain Project sowie seine Arbeit an Blockbustern wie Black Panther, Guardians of the Galaxy Vol. 2 und König der Löwen, gibt Einblicke in die Schnittstelle zwischen Technologie und kreativer Vision.

Außerdem stehen Talks zu diesen Themen auf dem Programm: Softwarearchitektur und -entwicklung, Architekturstrategie, Digitale Souveränität, Digitale Barrierefreiheit, Web Security sowie Data & AI.

Training Bites: Kompaktes Wissen direkt anwendbar

Zusätzlich zu den Fachvorträgen bietet der Technology Day Training Bites – kompakte Versionen der INNOQ-Schulungen, in denen Teilnehmer:innen sofort anwendbares Wissen zu Themen wie Agentic Software Engineering, Web Security und Accessibility erhalten.

„Wir teilen gern unsere Begeisterung für Softwarearchitektur und Technologie. Auf dem Technology Day 2025 geben wir nicht nur unsere praktischen Erfahrungen weiter. Aus den Diskussionen in den Sessions entstehen wertvolle Begegnungen, von denen wir selbst auch viel lernen.“
–Phillip Ghadir, Geschäftsführer INNOQ

Anmeldung ab sofort möglich

Die Teilnahme am INNOQ Technology Day ist kostenfrei. Interessierte können sich ab sofort unter https://technologyday.innoq.com anmelden. Die Plätze sind begrenzt. Die Veranstaltung findet online statt und ermöglicht so die Teilnahme von überall.

Über die innoQ Deutschland GmbH

INNOQ ist ein Technologie-Beratungsunternehmen. Wir beraten ehrlich, denken innovativ und entwickeln leidenschaftlich gern. Das Ergebnis sind erfolgreiche Softwarelösungen, Infrastrukturen und Geschäftsmodelle. Unsere Leistungen teilen sich in folgende Schwerpunkte auf:

– Strategie- und Technologieberatung
– Softwarearchitektur und -entwicklung
– Data & AI
– Entwicklung digitaler Produkte
– Digitale Plattformen und Infrastrukturen
– Wissenstransfer, Coaching und Trainings

Unsere Standorte sind Monheim (bei Düsseldorf), Berlin, Hamburg, Zürich, Offenbach, Köln und München.

Firmenkontakt und Herausgeber der Meldung:

innoQ Deutschland GmbH
Krischerstr. 100
40789 Monheim am Rhein
Telefon: +49 (2102) 77162-100
Telefax: +49 (2102) 7716-01
http://www.innoq.com

Ansprechpartner:
Stefanie Heinrich
Head of Marketing
E-Mail: stefanie.heinrich@innoq.com
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

Für die oben stehenden Pressemitteilungen, das angezeigte Event bzw. das Stellenangebot sowie für das angezeigte Bild- und Tonmaterial ist allein der jeweils angegebene Herausgeber verantwortlich. Dieser ist in der Regel auch Urheber der Pressetexte sowie der angehängten Bild-, Ton- und Informationsmaterialien. Die Nutzung von hier veröffentlichten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber.