Sobald das Wort „Souveränität“ fällt, denken die meisten sofort an Open Source. Der Gedanke liegt nahe: Nur wenn ich den Quellcode einsehen kann, bin ich wirklich unabhängig. Nur wenn eine Software quelloffen ist, kann ich sie überall betreiben, migrieren oder ersetzen.
Wir bei TCG Process sehen das differenzierter. Unsere Software ist proprietär und unsere Kunden sind trotzdem souverän. Das ist kein Widerspruch, sondern eine Frage der Architektur.
Inhaltsverzeichnis
- Bedeutung digitale Souveränität in der Praxis
- Souceränität & OCTO
- Mehr wert ist als reine Lizenzoffenheit
- Fazit
Was digitale Souveränität in der Praxis wirklich bedeutet
Cloud-Souveränität bedeutet die volle Kontrolle über Daten, Identitäten, Infrastruktur und Betriebsprozesse. Eine proprietäre Anwendung kann souverän betrieben werden, wenn sie auf einer offenen, kontrollierbaren Cloud-Plattform läuft, offene Standards unterstützt und keine unkontrollierten Herstellerabhängigkeiten schafft.
Digitale Souveränität wird oft auf die Lizenzfrage reduziert. In der Praxis geht es aber um etwas anderes, die Fähigkeit, selbst zu entscheiden.
Wo eine Anwendung läuft (on-premises, Private Cloud, Public Cloud, im eigenen Rechenzentrum).
Wie Daten gespeichert und verarbeitet werden.
Mit wem ein System spricht und welche Prozesse daran angebunden werden können.
Ob man den Anbieter wechseln könnte, ohne dabei die eigene Systemlandschaft neu aufbauen zu müssen.
Genau an diesen Punkten setzt unsere technische Architektur an. Unabhängig davon, dass der Quellcode selbst nicht offengelegt ist.
Digitale Souveränität & OCTO 2026
Die genannten Prinzipien stecken bei uns in der Produktentwicklung. Bislang war der Betrieb von OCTO auf Windows Server und Microsoft SQL Server beschränkt. Mit OCTO 2026 öffnen wir die Plattform. Zusätzlich zur bisherigen Umgebung können nun auch PostgreSQL als Datenbank und Linux-Container für das Deployment genutzt werden und damit Infrastrukturen wie Kubernetes oder OpenShift.
Das ist mehr als eine technische Fußnote. Es ist die Voraussetzung dafür, dass unsere Software auch in Rechenzentren betrieben werden kann, die ihre Infrastruktur bewusst auf Open-Source-Produkten aufgebaut haben. Losgelöst von den großen, oft nicht-europäischen Cloud-Konzernen. Betreiber, die auf Souveränität setzen, sind damit nicht auf einen bestimmten Hyperscaler angewiesen, um unsere Plattform einzusetzen.
Mit OCTO haben wir ein System geschaffen, das in genau dieser Open-Source-Infrastruktur betrieben werden kann und in dem die Datenhoheit jederzeit beim Kunden bleibt. Die folgenden Abschnitte zeigen im Detail, worauf diese Souveränität technisch aufbaut.
Die technische Basis: portabel statt proprietär gebunden
Unsere Software basiert auf .NET Core und kann als Container in Kubernetes betrieben werden. Das ist bewusst so gewählt. Denn .NET Core ist plattformunabhängig und läuft auf Linux ebenso wie auf Windows, in jeder gängigen Public Cloud, in Kubernetes-Distributionen wie OpenShift oder Rancher oder in einem klassischen On-Premises-Rechenzentrum.
Für unsere Kunden bedeutet das, es gibt keine Bindung an eine bestimmte Cloud-Plattform und keinen versteckten Zwang zu proprietären Diensten eines einzelnen Hyperscalers. Wer heute in der Public Cloud betreibt und morgen aus regulatorischen oder strategischen Gründen zurück ins eigene Rechenzentrum oder in eine europäische Cloud wechseln möchte, kann das tun. Die Containerisierung macht den Betriebsort austauschbar.
Als Datenbank kann zusätzlich PostgreSQL genutzt werden. Auch das ist eine bewusste Entscheidung gegen den Lock-in. PostgreSQL ist ein offener, weit verbreiteter Standard, für den es keine proprietären Exportbarrieren gibt. Daten liegen in einem Format vor, das sich mit Standardwerkzeugen sichern, migrieren und auswerten lässt. Ganz ohne Abhängigkeit von einem einzelnen Hersteller-Ökosystem.
Offene Schnittstellen statt Blackbox
Der zweite Baustein unserer Souveränitätsstrategie sind offene Schnittstellen. Unsere Software kommuniziert über dokumentierte, standardbasierte REST APIs. Diese sind darauf ausgelegt, in bestehende Systemlandschaften integriert zu werden, statt sie zu ersetzen.
Das hat für unsere Kunden mehrere Vorteile:
Integration statt Isolation
Vorgelagerte und nachgelagerte Systeme lassen sich anbinden, ohne dass proprietäre Konnektoren oder exklusive Middleware nötig sind.
Automatisierung nach eigenen Regeln
Prozesse, die über unsere Plattform laufen, können von Kunden selbst orchestriert, überwacht und erweitert werden.
Kein Blackbox-Betrieb
Auch wenn der Quellcode nicht einsehbar ist, ist das Verhalten der Software über die API-Dokumentation transparent und nachvollziehbar.
Souveränität entsteht hier nicht durch Einblick in den Code, sondern durch die Fähigkeit, jederzeit selbst zu steuern, wie Daten hinein- und herausfließen.
Identitäten: keine eigene Nutzerverwaltung, sondern offene Standards
Zur Kontrolle über die eigene IT gehört auch die Kontrolle über Identitäten, also darüber, wer Zugriff auf welche Daten und Prozesse hat. Auch hier setzen wir bewusst nicht auf eine eigene, geschlossene Benutzerverwaltung, sondern auf offene Standards wie OIDC (OpenID Connect), OAuth 2.0 oder SAML.
Das bedeutet für unsere Kunden: Anmeldung und Berechtigungsvergabe laufen über den bereits vorhandenen Identity-Provider, ob Active Directory, Keycloak, Azure AD oder ein anderes System. Es entsteht kein zweiter, isolierter Nutzerbestand, den man separat pflegen und absichern muss und keine Abhängigkeit von einem herstellerspezifischen Login-Mechanismus. Wer den Identity-Provider wechselt, kann das tun, ohne unsere Plattform neu konfigurieren zu müssen. Die Anbindung folgt dem Standard, nicht einer proprietären Schnittstelle.
Geschäftslogik: transparent statt im Quellcode versteckt
Ein wichtiger Punkt, der bei der Souveränitätsfrage oft übersehen wird ist, dass die Geschäftslogik unserer Kunden bei OCTO nicht verborgen im proprietären Quellcode steckt. Sie wird über einzelne Aktivitäten offen und transparent aufgebaut. Nachvollziehbar für alle, die mit der Plattform arbeitet, nicht nur für unsere Entwickler.
Mit unserer Plattform OCTO modellieren und orchestrieren wir Arbeitsabläufe für die Dokumentenverarbeitung nach dem BPMN 2.0-Standard und nach Low-Code-Prinzipien. Konkret heißt das, dass Prozesse nicht in Code gegossen werden, den nur wir lesen können, sondern als Modelle abgebildet, die Kunden selbst einsehen, nachvollziehen und mitgestalten können. Über unsere Orchestrierungsplattform lassen sich zudem KI-Funktionen und andere Technologien mit bestehenden wie neuen Prozessen und Systemen vernetzen.
Die eigentliche Wertschöpfung, wie ein Dokument verarbeitet, geprüft und weitergeleitet wird, liegt nicht in einer Blackbox, sondern in einem offenen, standardbasierten Prozessmodell, das der Kunde jederzeit einsehen und anpassen kann.
Warum das mehr wert ist als reine Lizenzoffenheit
Open-Source-Software kann sehr wohl in eine faktische Abhängigkeit führen, etwa wenn sie nur von einem einzigen Anbieter kommerziell supportet wird, tief in ein spezifisches Cloud-Ökosystem eingebettet ist oder ihr Datenmodell proprietäre Erweiterungen nutzt, die den Wechsel erschweren. Umgekehrt kann proprietäre Software, die auf offenen Standards aufbaut, austauschbar, prüfbar und portabel bleiben.
Genau das ist unser Ansatz bei TCG Process. Die technologische Basis unserer Plattform ist unser geistiges Eigentum. Die Geschäftslogik der Kunden selbst entsteht dagegen transparent, über Aktivitäten und BPMN-2.0-Modelle, nicht versteckt im Code. Betrieb, Datenhaltung und Integration folgen offenen, etablierten Standards.
Kunden erhalten damit eine Lösung, die
- überall lauffähig ist, wo Kubernetes betrieben wird
- Daten in einem offenen Format vorhält
- über offene Schnittstellen angebunden werden kann
- Im Ernstfall migrierbar bleibt, ohne dass Prozesse oder Daten in einem geschlossenen System gefangen sind
Fazit
Digitale Souveränität ist keine Frage der Lizenz, sondern der Architektur. Wer .NET Core, Kubernetes, PostgreSQL und offene REST-Schnittstellen konsequent einsetzt, hat die Kontrolle, über den Betriebsort, über die Daten und über die Integration in die eigene IT-Landschaft. Genau diese Kontrolle ist es, die am Ende zählt. Nicht, ob man den Quellcode lesen kann, sondern ob man jederzeit selbst entscheiden kann, wie und wo man arbeitet.
