Digitale Souveränität durch Standardsoftware erreichen

Dieser Artikel ist Teil einer Reihe.

• Teil 1: Digitale Souveränität – Ein Definitionsversuch
• Teil 2: CIO-Fragestellungen zur digitalen Souveränität
• Teil 3: Digitale Souveränität: Warum die Architektur zählt und wie Sie Ihr Unternehmen resilient machen
• Teil 4: EU-Datenverordnung: Der Anfang vom Ende der Cloud-Monokultur?
• Teil 5: Dateninventare im EU Data Act: Die Demokratisierung der IoT-Geräte
• Teil 6: Der Weg zur heterogenen Cloud Plattform
• Teil 7: Digitale Souveränität durch Standardsoftware erreichen (dieser Artikel)
• Teil 8: Die Souveränitätslücke: Zwischen Tiananmen und Trump
• Teil 9: Lokal denken, Vorsprung sichern: On-Premise-LLMs als strategischer Hebel
• Teil 10: Von Datenfriedhöfen zu Wissenslandschaften
• Teil 11: Digitale Souveränität als Selbstverständnis

Ein Gedankenexperiment: Stellen wir uns zwei Unternehmen, um es konkreter zu machen zwei IT-Beratungen, vor, mit sehr unterschiedlichen strategischen Ausrichtungen. Unternehmen A möchte vollständig unabhängig sein und entwickelt seine gesamte IT-Landschaft individuell: Von der Zeiterfassung über die Rechnungserstellung bis zum Knowledge Management. Keine Abhängigkeiten, alles in eigener Hand. Unternehmen B verfolgt die entgegengesetzte Strategie: Es will schnell am Markt agieren, keine Zeit in Individualentwicklung investieren und setzt ausschließlich auf fertige Standardbausteine: Die vollständige ERP-Suite eines großen Anbieters ist daher die Wahl.

Welches dieser Unternehmen ist nun souverän? Schaut man genauer hin, merkt man schnell: Keines von beiden. Unternehmen A hat sich durch seine Autarkie selbst blockiert – Ressourcen sind überlastet, Reaktionsfähigkeit praktisch nicht vorhanden. Unternehmen B sitzt im „goldenen Käfig“ seines Anbieters – jede Änderung kostet Zeit, Geld und Freiheiten. Beide haben am Markt kaum noch echte Handlungsoptionen.

Digitale Souveränität bedeutet also nicht Autarkie. Sie bedeutet, handlungsfähig zu bleiben: jederzeit bewusst entscheiden zu können, wo Standardlösungen genügen – und wo individuelle Entwicklungen notwendig sind, um das eigene Geschäftsmodell zu stärken.

Vereinfacht gesagt, haben wir es mit einem Trade-off zwischen Ressourcenoptimierung (durch den Einsatz von Standardsoftware) und Autarkie zu tun. Der Sweet Spot der Handlungsfähigkeit liegt in der Mitte – und muss bewusst austariert werden.

Doch damit nicht genug: Selbst ein geplanter Mix aus Standardsoftware und Eigenentwicklung kann scheitern, wenn dieser „Best-of-Breed“-Ansatz nicht durch klare architektonische Leitplanken (Makroarchitektur) in ein wart- und erweiterbares System-of- Systems gelenkt wird. Ohne diese Vorgaben droht ein undurchsichtiger Flickenteppich unterschiedlich integrierter Standardsoftware-Komponenten, der sich kaum pflegen oder erweitern lässt – und der damit erneut Handlungsunfähigkeit erzeugt.

Wir benötigen also klare Regeln für die Planung und Integration von Standardsoftware. Beide Aspekte wollen wir im Folgenden beleuchten: Zuerst, wie Unternehmen mit Hilfe strukturierter Methoden entscheiden, wo Eigenentwicklung oder Standardsoftware sinnvoll ist. Danach, wie eine Makroarchitektur den Einsatz von Standardsoftware so steuert, dass Abhängigkeiten reduziert und Handlungsfähigkeit bewahrt werden.

Strategische Planung: Wo Standardsoftware sinnvoll ist

Um Standardsoftware sinnvoll einsetzen zu können, braucht es zunächst Transparenz über die eigene IT-Landschaft. Ziel ist, genau zu verstehen, welche fachlichen Fähigkeiten ein Unternehmen benötigt, welche davon strategisch entscheidend sind und wo Effizienz durch Standardisierung im Vordergrund stehen kann. So entsteht eine belastbare Entscheidungsgrundlage: Wo entwickeln wir selbst – und wo setzen wir auf Standardsoftware?

Der erste Schritt ist die Erstellung einer Landkarte der fachlichen Fähigkeiten, oft als Capability Map bezeichnet. Sie zeigt, welche Bausteine – von Kundenprozessen über interne Verwaltungsfunktionen bis hin zu branchenspezifischen Kernprozessen – das Unternehmen benötigt und wie sie entlang der Wertschöpfungskette miteinander verbunden sind.

Um diese Landkarte zu entwickeln, bietet sich die Kombination zweier bewährter Ansätze an: TOGAF als Rahmenwerk liefert die strategische Struktur, Begriffe und Phasenmodelle, während Domain-driven Design (DDD) mit praxisnahen Werkzeugen wie Event Storming oder dem Domain Modeling Starter Process hilft, die fachlichen Zusammenhänge konkret und gemeinsam mit den Fachexperten zu erarbeiten. Ergänzend können Domain Storytelling-Interviews, die Analyse bestehender Systeme und branchenübliche Referenzmodelle wertvolle Erkenntnisse liefern.

Das Ergebnis ist eine hierarchische Capability Map, die die identifizierten Fähigkeiten ordnet und entlang der Wertschöpfungskette visualisiert. Sie bildet die Grundlage, um fundierte Entscheidungen zu treffen: Wo lohnt sich eine Eigenentwicklung, weil sie unsere Differenzierung stärkt, und wo setzen wir bewusst auf Standardlösungen, um Geschwindigkeit und Effizienz zu gewinnen?

Abbildung „Capability Map“ zeigt (gekürzt), wie eine Capability Map konkret für eine IT- Beratung aussehen könnte (auf Basis von ArchiMate). Entlang des definierten Value Streams von „Acquire Project“ bis „Close Project“ werden die benötigten Capabilities hierarchisch angeordnet. So lässt sich schnell erkennen, welche Fähigkeiten für den gesamten Wertschöpfungspozess relevant sind.

Die Bewertung dieser Capabilities erfolgt mithilfe bewährter Verfahren wie Wardley Maps, den DDD Core-Domain-Charts Marktabgrenzung jeder Capability zu reflektieren. So lassen sich drei Gruppen unterscheiden:

• Core Capabilities: Bereiche, in denen wir besser sein müssen als der Markt – hier lohnt sich Eigenentwicklung.
• Supporting Capabilities: Unterstützende Funktionen, die wichtig, aber nicht differenzierend sind – hier kann Standardsoftware sinnvoll sein.
• Commodity Capabilities: Austauschbare Bereiche, bei denen Effizienz im Vordergrund steht – hier ist Standardsoftware der Standardweg.

In unserem Beispiel der IT-Beratung ist die Capability „Time & Effort Tracking“ im Bereich Generic eingeordnet, während „Project Execution & Steering“ als Core gilt, da sie direkt die Wertschöpfung im Kundenprojekt beeinflusst. „Time & Effort Tracking“ hingegen folgt weitgehend standardisierten Prozessen und bietet wenig Differenzierungspotenzial, sodass Standardsoftware hier sinnvoll ist.

Diese Analyse mündet in einer Make-or-Buy-Strategie, die für jede Capability festlegt, ob sie intern entwickelt oder durch Standardlösungen abgedeckt wird.

Eine eingefärbte Capability Map (z. B. Blau für Eigenentwicklung, Grün für Standardsoftware) schafft Transparenz und dient als zentrales Steuerungsinstrument für die weitere Planung.

Damit entsteht eine IT-Landschaft, in der Standardsoftware gezielt dort eingesetzt wird, wo sie Freiräume schafft – und Eigenentwicklung dort stattfindet, wo sie den größten Mehrwert liefert. Dies ist der erste Schritt, um Standardsoftware nicht zufällig, sondern bewusst und souverän einzusetzen.

Architektonische Leitplanken für mehr Freiheit

Die Entscheidung, wo Standardsoftware eingesetzt wird, ist nur der erste Teil. Genauso wichtig ist, wie diese Standardsoftware eingebettet wird. Ohne klare Architekturvorgaben führt selbst die klügste Make-or-Buy-Strategie schnell zu einem unübersichtlichen, schwer zu ändernden Flickenteppich.

Deshalb braucht es eine Makroarchitektur: übergreifende Leitlinien, die für alle Systeme gelten – unabhängig davon, ob es sich um Eigenentwicklungen oder Standardprodukte handelt. Diese Architektur beschränkt sich auf eine überschaubare Anzahl zentraler Themengebiete, sorgt aber dafür, dass es an den entscheidenden Schnittstellen gemeinsame Standards gibt. So entsteht Homogenität innerhalb eines heterogenen System- of-Systems: Einzelne Systeme können unabhängig voneinander entwickelt oder ersetzt werden, ohne die Gesamtlandschaft zu destabilisieren.

Besonders beim Einsatz von Standardsoftware ist dies essenziell. Integrationsrichtlinien müssen gewährleisten, dass die Kopplung zwischen Systemen möglichst lose bleibt, um Anbieter bei Bedarf ohne großen Aufwand wechseln zu können. In der Praxis haben sich asynchrone, eventgetriebene Architekturen als wirksames Muster bewährt, da sie Systeme entkoppeln und eine flexible Reaktion auf Veränderungen ermöglichen.

Entsprechend sollten Unternehmen bei der Auswahl von Standardsoftware darauf achten, dass diese über geeignete APIs verfügt und im besten Fall bereits eigenständig Events veröffentlicht – etwa über Webhooks.

Ein häufiger Fehler besteht darin, proprietäre Datenstrukturen direkt in andere Systeme weiterzuleiten. Dadurch entstehen schwer auflösbare Abhängigkeiten, die spätere Anbieterwechsel extrem teuer und riskant machen. Stattdessen sollten eingehende Daten über Wrapper in unternehmenseigene Formate transformiert werden. Zwar erhöht dies zunächst den Integrationsaufwand, langfristig reduziert es jedoch die Komplexität und erleichtert die Wiederverwendbarkeit.

Schließlich ist auch bei der Auswahl der zentralen Integrationskomponenten – beispielsweise des Event Brokers – darauf zu achten, dass sie auf offenen und standardisierten Formaten basieren. Proprietäre Protokolle an dieser kritischen Stelle würden das gesamte System erneut in eine Abhängigkeit bringen, die nur schwer auflösbar ist. Ein offener, idealerweise Open-Source-basierter Ansatz schützt die langfristige Unabhängigkeit.

Exemplarisch für unsere IT-Beratung ergibt sich damit eine Umsetzung, die die internen Events aus der eingekauften Standardsoftware für „Time & Effort Tracking“ über einen Adapter aufbereitet und an den zentralen Event Bus (z. B. realisiert mit Apache Kafka) sendet. Die selbst entwickelte Lösung für „Project Execution & Steering“ kann anschließend auf „Time Tracked“-Events lauschen und Forecasts für den jeweiligen Manager generieren – ohne eine direkte Abhängigkeit zum Anbieter der Standardsoftware.

So bleibt die Integration flexibel, und neue oder geänderte Systeme können mit überschaubarem Aufwand angebunden werden.

Mit diesen Regeln entsteht ein Rahmen, der Standardsoftware nahtlos in die IT-Landschaft integriert, ohne die Handlungsfähigkeit einzuschränken.