Über den Sommer hatte ich endlich Zeit, mein Referenzmodell für Datenarchitekturen um ein konkretes Beispiel zu erweitern. Nicht, weil es „noch ein Framework“ braucht – sondern weil wir dringend eine neue Haltung zur Daten Architektur brauchen.
Denn was heute unter dem Schlagwort digitale Souveränität diskutiert wird, ist in Wahrheit ein Architekturproblem. Und zwar eines, das wir nicht mit Tools oder Cloud-Native oder Souveränitäts-Stempeln lösen werden.
Viele Architekturen, die ich sehe, sind in Wahrheit Einkaufslisten. Tools, Plattformen, Services – hübsch visualisiert, aber ohne strategische Tiefe.
Was mir aber fehlt, ist ein Capability-getriebener Ansatz, der nicht fragt: Was können wir kaufen?, sondern:
Was müssen wir können?
Mit dem Referenzmodell versuch ich genau das zu entwickeln:
- Prinzipien wie Cloud-First, Data Quality First oder Data Ethics geben Orientierung.
- Value Streams wie Data to Insights oder Data Impact zeigen, wo Wert entsteht.
- Capabilities wie Data Governance, DataOps oder Security machen sichtbar, was wir beherrschen müssen – unabhängig vom Toolstack.
Die Diskussion um EU-Clouds, Schrems II und den US Cloud Act ist zweifellos wichtig – doch sie greift zu kurz, wenn wir nicht gleichzeitig unsere Datenarchitekturen hinterfragen. Denn digitale Souveränität entsteht nicht durch Standortwahl allein, sondern durch die Fähigkeit, unsere Systeme flexibel, nachvollziehbar und strategisch zu gestalten.
Eine souveräne Architektur ist weit mehr als nur „compliant“. Sie muss anpassungsfähig sein, sowohl technisch als auch rechtlich. Sie sollte es ermöglichen, Plattformen zu wechseln, ohne die eigene Datenkompetenz zu verlieren. Und sie muss Abhängigkeiten nicht nur dokumentieren, sondern aktiv gestaltbar machen. Das gelingt nur, wenn wir modular denken und unsere Architekturen so bauen, dass sie sich weiterentwickeln lassen – statt sie in monolithischen Strukturen zu zementieren.
Dabei geht es nicht nur um den vielzitierten Vendor Lock-in. Ja, die Abhängigkeit von einzelnen Anbietern kann problematisch sein – etwa wenn Schnittstellen proprietär sind, die Datenhoheit unklar bleibt oder Anbieter unter fremden Jurisdiktionen stehen. Doch nicht jeder Lock-in ist per se schlecht. In manchen Fällen ist die Bindung an einen Anbieter eine bewusste strategische Entscheidung: etwa wenn dieser eine hohe Innovationsgeschwindigkeit bietet, verlässliche Betriebsmodelle etabliert hat oder komplexe Integrationen deutlich vereinfacht.
Die entscheidende Frage lautet also nicht, ob wir uns binden – sondern wie bewusst wir diese Bindung eingehen. Mit dem Referenzmodell versuche ich genau das: Es soll transparent machen, welche Fähigkeiten wir auslagern, welche wir intern behalten und wie wir Exit-Strategien gestalten können, falls sich technische, rechtliche oder politische Rahmenbedingungen ändern.
Was kommt als Nächstes?
Ich werde das Modell weiterentwickeln – mit mehr Beispielen, mehr Kontext, mehr Praxis.
Denn Architektur ist kein Zustand, sondern ein Prozess. Und Souveränität ist kein Ziel, sondern ein Prinzip.
📥 Das vollständige Modell gibt’s hier: https://codeberg.org/Alexander_von_Boguszewski/DataArchitecture