Handlungsfähig bleiben, wenn Hersteller, Preise oder Lieferketten sich ändern: Plattformen auf offenen Standards, austauschbare Komponenten, betreibbar auch ohne Netzanbindung.
Kein Hersteller liefert auf Dauer alles, und keine Beschaffung deckt den gesamten Lebenszyklus ab. Entscheidend für die Handlungsfähigkeit ist deshalb nicht das Eigentum am System, sondern ob es ohne Mitwirkung des Herstellers betrieben, verändert und weiterentwickelt werden kann. Das setzt offene Schnittstellen und austauschbare Komponenten voraus, keine Vertragsklausel.
Digitale Souveränität verankern wir in der Systemarchitektur. Sie hat drei Ebenen: austauschbare Technologie, eigener Betrieb auch im getrennten Netz und die Kontrolle über Daten und Schlüssel.
Wir entwickeln Container-Plattformen im eigenen Rechenzentrum, in einer souveränen Cloud wie STACKIT oder air-gapped in getrennten Netzen ohne Internetanbindung. Durch eigene Registries, gespiegelte Artefakte und Abhängigkeiten sowie reproduzierbare Deployments über GitOps bleibt der Stack betriebsfähig – auch wenn eine externe Quelle wegfällt.
Nutzen Sie Sprach- und Erkennungsmodelle mit offenen Gewichten auf Ihrer eigenen Hardware, in getrennten Netzen oder an abgesetzten Standorten – ohne Verbindung zu externen Anbietern. Das Modell bleibt austauschbar, die Daten verlassen Ihre Umgebung nicht. Training und Daten versionieren wir reproduzierbar (z. B. mit MLflow und DVC), sodass Sie Ihr Modell auch unabhängig vom Hersteller weiterentwickeln können.
Bestandssysteme lösen wir schrittweise aus der Herstellerbindung: Bestandsaufnahme, Bewertung von Lizenz- und Abhängigkeitsrisiken, Zielarchitektur mit offenen Komponenten, Migration im laufenden Betrieb. Die Exit-Strategie wird mitgebaut, nicht nachträglich dokumentiert.
Interoperabilität entsteht über Standards, nicht über Integrationsprojekte. Wir setzen auf dokumentierte, versionierte Schnittstellen (OpenAPI, ereignisgetriebene Verträge), offene Geodatenformate (OGC, GeoJSON) und, wo einschlägig, auf NATO-Standardisierungsübereinkommen und die Datenmodelle des Multilateral Interoperability Programme. Datenhaltung und Anwendungslogik werden entkoppelt, damit neue Systeme angebunden und alte ersetzt werden können, ohne die Datenbasis neu aufzubauen.
Wir entwickeln für Sie Zugriffsverwaltung auf Open-Source-Basis: Rollen- und Rechtekonzepte, Mandantentrennung, Föderation zu bestehenden Verzeichnisdiensten, Multi-Faktor-Authentisierung und Betrieb auch an abgesetzten Standorten mit unzuverlässiger Verbindung.
Wir liefern standardmäßig mit maschinenlesbarer Software-Stückliste (SPDX/CycloneDX), signierten Artefakten, reproduzierbaren Builds und automatisiertem Schwachstellen-Scanning. Ergänzt durch Lizenz-Audits, Open-Source-Freigabeprozesse und ein klares Supportmodell sichern wir Ihre eigene Wartungsfähigkeit. So bereiten Sie sich auf Anforderungen von CRA sowie NIS-2 vor und identifizieren im Ernstfall betroffene Komponenten innerhalb von Stunden.
Wir bewerten Ihre Systemlandschaft und zeigen, welche Abhängigkeit kritisch ist und welche Komponente sich zuerst zu ersetzen lohnt. Sprechen Sie mit uns!
Wir verfügen über jahrelange Erfahrung als IT-Dienstleister in regulierten Umfeldern mit hohen Sicherheitsanforderungen, von Betreibern kritischer Infrastruktur bis zu Plattformen mit Millionen Nutzenden.
Wir bauen Systeme aus austauschbaren Komponenten und dokumentierten Schnittstellen. Damit bleibt die Entscheidung über die nächste Systemgeneration bei Ihnen: Preis-, Lizenz- oder Roadmap-Änderungen eines Herstellers wirken sich nicht unmittelbar auf Ihre Einsatzfähigkeit aus. Fällt ein Anbieter aus, ist der Weiterbetrieb möglich, im Extremfall über einen eigenen Wartungszweig.
Offener Quellcode bedeutet: keine Blackbox in kritischen Pfaden. Was in Ihren Systemen steckt, ist über maschinenlesbare Software-Stücklisten und signierte Artefakte jederzeit belegbar, gegenüber Prüfstellen und im Vorfallsfall innerhalb von Stunden. Als nach ISO/IEC 27001 zertifiziertes und nach TISAX auf höchster Vertraulichkeitsstufe geprüftes Unternehmen arbeiten wir selbst nach entsprechenden Vorgaben.
Offene Standards sind die Voraussetzung für Zusammenarbeit über Systemgrenzen und über Bündnispartner hinweg. Wir entkoppeln Datenhaltung von Anwendungslogik, damit neue Sensoren, Subsysteme oder Partnersysteme angebunden und alte ersetzt werden können, ohne dafür jeweils ein eigenes Herstellerprojekt aufzusetzen, und damit Ihre Datenmodelle über Systemgenerationen hinweg nutzbar bleiben.
Lizenzkosten skalieren nicht automatisch mit Nutzerzahl, Knoten oder Datenvolumen, und Support wie Weiterentwicklung bleiben über die gesamte Nutzungsdauer wettbewerblich vergebbar. Realistisch eingeordnet: Der Aufwand verschiebt sich von Lizenzen zu Betrieb und Kompetenzaufbau.
Diesen wirtschaftlichen Vergleich machen wir gemeinsam mit Ihnen, bevor die Architekturentscheidung fällt.
Für dmTECH haben wir eine vollautomatisierte Linux-Infrastruktur im eigenen Rechenzentrum aufgebaut: über 800 virtuelle Server, RedHat als Distribution, Lifecycle-Management mit Foreman, Konfiguration über Puppet, Delivery-Pipeline mit Jenkins. Vorher lief die strategische Plattform auf Windows. Ziel war von Anfang an, dass der Kunde die Plattform anschließend selbst betreibt und weiterentwickelt.
Für 1&1 Mail & Media haben wir den Betrieb containerisierter Workloads auf selbst betriebenen, georedundanten Kubernetes-Clustern auf eigener Hardware aufgebaut, bewusst ohne Public-Cloud-Abhängigkeit, bei durchgehender Verfügbarkeitsanforderung.
Für Open Grid Europe, Betreiberin eines überregionalen Gasfernleitungsnetzes, haben wir unter anderem die Inhaltsanalyse von Rechtstexten mit generativer KI und einen natürlichsprachigen Zugriff auf Unternehmensdaten umgesetzt, jeweils auf internen, nicht öffentlichen Beständen.
Das interne Managed-Services-Team von inovex hat eine Disaster-Recovery-Strategie auf Basis von STACKIT entworfen. Die internen Dienste laufen auf einer Private Cloud auf OpenStack-Basis auf dedizierter Hardware in einem Frankfurter Rechenzentrum, mit 60 bis 70 gehosteten Services. Auf der STACKIT Kubernetes Engine wurde eine Umgebung mit denselben Eigenschaften wie die internen Cluster aufgebaut. Backups ließen sich dort ohne Komplikationen wiederherstellen, und bei einer temporären Störung der eigenen Plattform wurden die GitLab Runner kurzfristig auf die STACKIT-Infrastruktur geschwenkt; der Notbetrieb funktionierte reibungslos.
Die Fähigkeit, ein System auch ohne Mitwirkung des Herstellers zu betreiben, zu verändern und weiterzuentwickeln. Das umfasst drei Ebenen: austauschbare Technologie, also Komponenten mit offenen Schnittstellen statt Herstellerbindung; eigener Betrieb, auch offline und in getrennten Netzen; und die Kontrolle über Daten und Schlüssel, einschließlich der Möglichkeit, Daten vollständig wieder herauszulösen. Der Serverstandort ist dabei nur eine Teilfrage. Ein System in einem deutschen Rechenzentrum, das ohne den Hersteller nicht mehr aktualisierbar ist, ist nicht souverän.
Ja, und in vielen kritischen Infrastrukturen ist es längst die Grundlage, von Betriebssystemen über Kryptobibliotheken bis zu Container-Plattformen. Entscheidend ist nicht die Lizenz, sondern der Umgang damit: geprüfte Herkunft der Komponenten, gepflegte Abhängigkeiten, signierte Artefakte, gespiegelte Registries ohne Abhängigkeit von externen Quellen, definierte Update-Pfade und eine belastbare Antwort auf die Frage, wer im Fehlerfall handlungsfähig ist. Offener Code hat dabei einen Vorteil, den proprietäre Software nicht bietet: Er lässt sich unabhängig prüfen und im Ernstfall selbst korrigieren.
Nein, die beiden Fragen betreffen unterschiedliche Ebenen. Nach dem Kerckhoffs-Prinzip soll die Sicherheit eines Verfahrens nicht auf der Geheimhaltung des Verfahrens beruhen, sondern auf Schlüsseln, Konfiguration und Betrieb. Eingestuft sind in der Regel Daten, Parametrierung und Einsatzkontext, nicht der Algorithmus; viele kryptografische Verfahren im Einsatz sind veröffentlicht und gerade deshalb geprüft. Der Umgang mit eingestuftem Material richtet sich nach den Vorgaben des Auftraggebers und den geltenden Geheimschutzvorschriften, unabhängig davon, ob der Quellcode offen ist.
Über den Vertrag mit dem Dienstleister oder Betreiber, nicht über die Lizenz. Open-Source-Lizenzen schließen Gewährleistung und Haftung fast immer aus; die Verantwortung für ein System übernimmt, wer es baut, betreibt und weiterentwickelt, und regelt sie vertraglich wie bei jeder anderen Software. Wo es sinnvoll ist, kommen kommerzielle Subscriptions für einzelne Komponenten hinzu, etwa für eine Distribution oder eine Datenbank. Der Unterschied zum proprietären Modell liegt nicht im Umfang der Verantwortung, sondern darin, dass sie neu vergebbar ist: Ein anderer Dienstleister kann den Support übernehmen, ohne dass das System ersetzt werden muss. Eine Lizenzfrage gehört dabei an den Anfang: Komponenten unter Copyleft-Lizenzen wie der GPL verpflichten bei der Weitergabe dazu, den Quellcode des betroffenen Teils mitzuliefern. Für den Auftraggeber als Empfänger ist das meist unkritisch. Relevant wird es, wenn solcher Code mit Teilen verbunden wird, die nicht offengelegt werden dürfen, oder wenn die Software an Dritte geht, etwa an Bündnispartner. Deshalb prüfen wir Lizenzen bei der Architekturentscheidung, nicht bei der Auslieferung.
Ja. Wer sich an herstellerspezifische Erweiterungen einer Distribution, an proprietäre Betriebswerkzeuge oder an eine einzige Managed-Variante bindet, hat den Lock-in nur verlagert. Die Lizenz des Kerns hilft dann wenig, wenn Konfiguration, Automatisierung und Betriebswissen an einen Anbieter gebunden sind. Die Prüffrage bei jeder Architekturentscheidung lautet deshalb: Welche Schnittstelle ist standardisiert, welche ist herstellerspezifisch, und was kostet der Wechsel? Ein ehrlicher Wechselkostenvergleich vor der Entscheidung ist der beste Schutz.
Das hängt von der Domäne ab. Im Führungs- und Lageinformationsumfeld sind es NATO-Standardisierungsübereinkommen (STANAG) und die Datenmodelle des Multilateral Interoperability Programme, im Geoumfeld die OGC-Standards, im Fahrzeugumfeld die NATO Generic Vehicle Architecture, bei unbemannten Systemen die STANAG-Regelungen zur Steuerung und Nutzlastanbindung. Auf Plattformebene kommen die offenen Industriestandards hinzu: OpenAPI, OpenTelemetry, OCI, SPDX beziehungsweise CycloneDX. Welche davon verpflichtend, welche empfohlen und welche in der Praxis tatsächlich implementiert sind, unterscheidet sich je Vorhaben und gehört vor die Architekturentscheidung, nicht dahinter.
Nein. Zwischen Eigenbetrieb und Public Cloud liegt der Betrieb bei einem Anbieter, der deutschem Recht unterliegt und keine Muttergesellschaft in einem Drittstaat hat, über die ein dortiger Zugriff möglich wäre. Dafür arbeiten wir unter anderem mit STACKIT zusammen, dem Cloud-Anbieter der Schwarz Gruppe mit Rechenzentren in Deutschland und Österreich. Für viele Vorhaben ist das der pragmatische Mittelweg: kein eigener Rechenzentrumsbetrieb, aber auch keine Abhängigkeit von einem außereuropäischen Anbieter. Welche Variante passt, entscheidet die Einstufung der Daten, nicht die Grundsatzfrage.
Die Bedrohungslage wartet nicht auf lange Entwicklungszyklen. Wir bringen Ihre Software in Release-Geschwindigkeit – souverän, sicher, einsatzbereit.