Die Art, wie Unternehmen über Technologie sprechen, hat sich verändert. Die Diskussionen, die früher nur in den technischen Abteilungen geführt wurden, finden nun Eingang in Verwaltungsratspräsentationen, White Papers der Regierung und Beschaffungsrichtlinien. Im Kern geht es dabei fast immer um denselben Begriff: Souveränität.
Die digitale Souveränität wandelt sich von einem abstrakten Ziel zu einer klaren Priorität. Regierungen, Unternehmen und öffentliche Institutionen suchen eine Antwort auf eine altbekannte Frage, die zunehmend drängt:
Wie behalten wir in einer Zeit zunehmender Komplexität, sich ändernder Bedrohungen und steigender Erwartungen von Bürgern und Kunden die Kontrolle über unsere digitalen Systeme?
Es steht viel auf dem Spiel. Die Abhängigkeit von Hyperscale-Cloud-Anbietern, proprietären Plattformen und Infrastrukturen Dritter macht Regulierungsbehörden nervös. Führungskräfte sind besorgt wegen Schwachstellen in Lieferketten, unerwartetem Vendor Lock-in und stetig steigenden Kosten für die Instandhaltung alternder Systeme. Architekten und Ingenieure einer ganzen Generation von Teams sind erschöpft, da sie unter der Last von Systemen ächzen, die sie übernommen haben, aber nicht vollständig verstehen.
Obwohl Souveränität ein rege diskutiertes Thema ist, wird sie nach wie vor häufig missverstanden.
Der Begriff digitale Souveränität wird heute in einem breiten Kontext verwendet. Je nach Person, die ihn benutzt, bezieht er sich auf Anforderungen an den Datenstandort, die nationale Cloud-Infrastruktur, Open-Source-Verpflichtungen, Beschaffungsrichtlinien oder einfach den vagen Wunsch, weniger abhängig von grossen US- oder chinesischen Technologiefirmen zu sein.
|
«Digitale Souveränität ist die Freiheit, zu wählen – jetzt und insbesondere später.» Stefan Minder |
|
Damit sich Souveränität steuern lässt, muss sie definiert sein. Ein häufig verwendeter Ansatz stammt von der Schweizer Bundesverwaltung:
«Digitale Souveränität bedeutet, als Staat über die erforderliche Kontroll- und Handlungsfähig-keit im digitalen Raum zu verfügen, um die Erfüllung staatlicher Aufgaben sicherzustellen.»
Diese Definition ist bewusst breit gefasst. Das Netzwerk SDS orientiert sich an einer engeren Definition, die am Digital Summit 2018 in Deutschland vorgestellt wurde:
«Digitale Souveränität eines Staates oder einer Organisation umfasst zwingend die vollständige Kontrolle über gespeicherte und verarbeitete Daten sowie die unabhängige Entscheidung darüber, wer darauf zugreifen darf. Sie umfasst weiterhin die Fähigkeit, technologische Komponenten und Systeme eigenständig zu entwickeln, zu verändern, zu kontrollieren und durch andere Komponenten zu ergänzen.»
Zwei Aspekte der Definition des Netzwerks SDS sind besonders interessant:
Erstens: Der Datenstandort allein ist keine Gewähr für Souveränität. Speichert ein Unternehmen seine Daten auf Servern im Inland, bedeutet das nicht automatisch, dass es kontrollieren kann, wer unter welchen rechtlichen Bedingungen oder über welchen technischen Kanäle auf die Daten zugreift. Die volle Kontrolle über gespeicherte und verarbeitete Daten zu behalten (sowie die Entscheidungsbefugnis, wer darauf zugreift), ist deutlich schwieriger, als Compliance-Checklisten vermuten lassen.
Zweitens und für Architekten und Ingenieure vielleicht noch wichtiger: Die Definition umfasst ausdrücklich die Fähigkeit, technologische Komponenten und Systeme unabhängig zu entwickeln, zu verändern, zu kontrollieren und zu erweitern. Dies ist weder eine Beschaffungs- noch eine gesetzliche Vorgabe. Es ist vielmehr eine elementare betriebliche und architektonische Frage, ob ein Unternehmen seine Systeme tatsächlich nutzen kann oder sie nur auf dem Papier besitzt..
Dieser Unterschied ist in der Praxis zentral. Ein Unternehmen kann alledie Lizenzrechte für den Source Code eines Systems besitzen, aber dennoch komplett unfähig sein, ihn weiterzuentwickeln. Die Gründe können vielfältig sein: Die internen Wissensträger sind weg, die Architektur ist zu komplex, um sie anzupassen, oder die Betriebskosten zehren alle verfügbaren Ressourcen auf. In diesem Fall ist Souveränität eher eine gesetzliche Fiktion denn betriebliche Realität.
Richtig verstanden umfasst die digitale Souveränität drei voneinander untrennbare Dimensionen:
Technologische Souveränität
Dies ist die Fähigkeit, Systeme zu verstehen, zu verändern, zu erweitern und zu ersetzen, wenn sich die Bedürfnisse ändern, ohne durch technische Altlasten, Vendor Lock-in oder unüberwindbare Komplexität eingeschränkt zu sein. Wer ein System besitzt, es aber nicht versteht, ist nicht souverän. Ist die Architektur zudem zu komplex, um es ohne Risiko anzupassen, kontrolliert das System das Unternehmen anstatt umgekehrt.
Datensouveränität
Dies umfasst die Fähigkeit zu kontrollieren, welche Daten gesammelt, wo sie gespeichert und wie sie verarbeitet werden sowie wer unter welchen Bedingungen darauf zugreifen kann. Die Einhaltung gesetzlicher Vorschriften ist nicht gleichbedeutend mit Datensouveränität. Das Schrems-II-Urteil von 2020 zeigt genau dies: Unternehmen, deren Datenvereinbarungen auf gesetzlichen Vereinbarungen anstatt auf Architekturentscheidungen basierten, sahen sich über Nacht einem Risiko ausgesetzt
Operative Souveränität
Dies bezeichnet die Fähigkeit, Systeme zu betreiben, zu überwachen und zu warten, wobei das Wissen und die Befugnis erhalten bleiben, jederzeit einzugreifen, Kursänderungen vorzunehmen oder Dienste bzw. Anbieter auszutauschen. Die operative Souveränität ist die unauffälligste Dimension, deren Vernachlässigung die grösste Gefahr birgt.
Kein Unternehmen ist komplett unabhängig – jedes Datencenter, jedes Netzwerk und jede Lieferkette schafft externe Abhängigkeiten. Entscheidend ist nicht, ob solche Abhängigkeiten bestehen, sondern ob sie verstanden werden, begrenzt und ersetzbar sind.
Unternehmen stellen oft nicht erst in einer Krise fest, dass sie die Kontrolle verloren haben, sondern bereits bei der Verlängerung von Beschaffungsverträgen. Nämlich dann, wenn sich herausstellt, dass das für den Betrieb ihrer Systeme erforderliche Wissen vollständig ausserhalb des Unternehmens liegt.
|
|
Daniel Säuberli |
Souveränität ist eine strukturelle Eigenschaft. Deshalb müssen alle drei genannten Dimensionen gleichzeitig gegeben sein. Geht eine verloren, schwächt dies mittelfristig die anderen beiden. Systeme, die ein Unternehmen nicht anpassen kann, werden zu Systemen, die sich nicht warten lassen. Datenkonfigurationen, die von externer Infrastruktur abhängig sind, führen zu einem Hebeleffekt, der die architektonischen Gestaltungsmöglichkeiten einschränkt.
Digitale Souveränität bedeutet nicht wirtschaftliche Unabhängigkeit. Es geht nicht darum, alles intern zu entwickeln oder externe Dienstleistungen und Partnerschaften aus Prinzip abzulehnen. Digitale Souveränität ist auch kein Bekenntnis gegen die Cloud. Wenn die Abhängigkeiten genau bekannt sind und echte Ausstiegsmöglichkeiten bestehen, können Cloud-Plattformen selbstbestimmt genutzt werden. Es handelt sich auch nicht um eine einmalige Zertifizierung. Souveränität ist kein Zustand, den man einmal erreicht und dann passiv aufrechterhält. Es ist eine Eigenschaft, deren Erhalt aktive, kontinuierliche Architektur- und Governance-Entscheidungen erfordert.
Unternehmen müssen sich in Bezug auf die Souveränität die folgende Frage stellen: Wenn unser wichtigster Anbieter morgen wegfällt, wenn unser leitender Architekt nächsten Monat das Unternehmen verlässt oder wenn unser Budget um ein Drittel gekürzt wird – was würde dann tatsächlich zusammenbrechen und wie schnell könnten wir uns davon erholen?
Die Antwort auf diese Frage verrät mehr über die Souveränität eines Unternehmens als jedes Compliance-Dokument oder jede Technologie-Strategie.
Die meisten Unternehmensprozesse sind darauf ausgelegt, einzelne, klar abgegrenzte Probleme zu lösen. Eine Sicherheitsprüfung hat einen bestimmten Umfang. Ein Migrationsprojekt hat eine Frist und eine Compliance-Prüfung eine Checkliste. Bei der Souveränität ist dies nicht der Fall. Sie ist ein Zustand, der entweder aufrechterhalten wird oder nach und nach verloren geht. Souveränität ist eine Meta-Anforderung. Genau das macht ihre Handhabung so schwierig.
Die obige Definition verdeutlicht dies. Ein Unternehmen ist dann souverän, wenn es die vollständige Kontrolle hat über seine Daten sowie die Entscheidungsbefugnis, wer auf diese Daten zugreift, und die Fähigkeit, die eigenen Systeme weiterzuentwickeln, anzupassen, zu kontrollieren und zu ersetzen. Alle drei Bedingungen müssen gleichzeitig erfüllt sein. Dies kann sich ändern, ohne dass Alarmzeichen wahrnehmbar wären.
Bis eine solche Verschlechterung auffällt, lässt sie sich in der Regel nicht mehr rückgängig machen.
Die Entscheidung für eine firmeneigene Integrationsschicht erscheint sinnvoll angesichts des Drucks, vierteljährlich liefern zu müssen. Ein Einstellungsstopp, der nie vollständig aufgehoben wird, führt dazu, dass ein Team von einem einzigen Architekten abhängig ist, der über das betriebliche Fachwissen für ein kritisches System verfügt. Ein Lizenzmodell, das bei zehntausend Nutzenden bezahlbar erschien, lässt sich bei einer Million Nutzenden strukturell nicht mehr kündigen. Keiner dieser Fälle deutet auf ein Versagen der Souveränität hin. Jede Entscheidung ist schlicht ein Kompromiss zu dem Zeitpunkt, an dem sie gefällt wird.
Aus diesem Grund wird Souveränität so oft missverstanden: Unternehmen beurteilen sie zu einem bestimmten Zeitpunkt, normalerweise bei der Beschaffung oder gelegentlich bei einem Audit. Ein zufriedenstellendes Ergebnis betrachten sie dann als dauerhaft. Doch ein System, das heute bei jedem Kriterium für Souveränität gut abschneidet, kann in drei Jahren ernsthaft gefährdet sein, wenn man bei aktuellen Entscheidungen systematisch auf kurzfristige Bequemlichkeit setzt anstatt auf langfristige Kontrolle.
Die Frage lautet nie «Sind wir souverän?», sondern «In welche Richtung gehen wir, und wie schnell?».
Diese neue Sichtweise hat praktische Konsequenzen: Souveränität lässt sich weder komplett an die Rechts- oder die Compliance-Abteilung delegieren noch lässt sie sich durch eine einzige architektonische Entscheidung gewährleisten, wie durchdacht diese auch sein mag. Stattdessen erfordert Souveränität kontinuierliches, funktionsübergreifendes Engagement: von Ingenieuren, die täglich Designentscheidungen treffen, von Architekten, die strukturelle Muster festlegen, von Beschaffungsteams, die Anbieterbeziehungen bewerten, und von leitenden Organen, die sich der kumulativen Kosten eingeschränkter Entscheidungen bewusst sind.
Souveränität ist die Summe tausend kleiner Entscheidungen. Genau deshalb lohnt es sich, es richtig zu machen. Die häufigste Bedrohung liegt nicht in der Abhängigkeit von Dritten. Sie liegt darin, dass Systeme still und leise zu komplex, zu teuer und zu anfällig für Weiterentwicklungen werden.
Bei den meisten Unternehmen geht die Souveränität nicht durch ein plötzliches Ereignis verloren. Sie wird schleichend ausgehöhlt – mit jeder Entscheidung, mit jedem Release.
Im Laufe der Jahre werden massgeschneiderte Systeme immer umfangreicher. Das Umsetzen von Änderungswünschen erfordert mehr Zeit. Das Know-how beschränkt sich auf eine Handvoll Einzelpersonen. Sogar wenn ein Unternehmen den Code «besitzt», gilt dies nicht zwingend für die Fähigkeit, ihn weiterzuentwickeln. Dies führt zu einer Situation, die zahlreiche Teams aus dem privaten und dem öffentlichen Sektor heute beobachten: Systeme bestimmen die Strategie, anstatt sie zu unterstützen.
Ein wichtiges Alarmzeichen ist die Mittelzuweisung. Wird der Grossteil des IT-Budgets dafür aufgewendet, Altsysteme am Laufen zu halten, ist der Spielraum für strategische Anpassungen gering. Innovation kommt zum Stillstand. Die Risiken mehren sich. Das System bestimmt anstatt das Unternehmen.
Diese stille Abhängigkeit ist der am meisten unterschätzte Gegenspieler der Souveränität. Sein Name: Komplexität.
Die Komplexität steigt durch einzelne rationale Entscheidungen: eine individuelle Integration hier, ein intern entwickelter Service dort. Ein Framework, das ursprünglich wegen seiner Schnelligkeit gewählt wurde und nun Spezialisten erfordert. Eine Datenbank, die sich zu einem De-facto-API für Dutzende angebundene Systeme entwickelt hat. Nichts davon schien anfänglich riskant. Zusammen führen diese Faktoren zu einem System, das niemand ganz versteht, an das sich niemand heranwagen will und das immer mehr Ressourcen verbraucht, um funktionsfähig zu bleiben.
Geht der Grossteil des Budgets dafür drauf, das System am Leben zu erhalten, ist es mit der Souveränität nicht weit her. Das Unternehmen sitzt in der Falle.
Souveränität wird oft als rechtlicher oder politischer Begriff verstanden. In der Praxis ist sie jedoch auch und vor allem eine architektonische Eigenschaft, d.h. die langfristige Fähigkeit zu steuern, was man geschaffen hat.
Die Schwierigkeit dabei ist, dass diese Fähigkeit auf keinem Dashboard erscheint. Es gibt keinen Messwert für Souveränität und keine Prüfung, die ein einwandfreies Ergebnis liefert. Indes sind gewisse Signale messbar: die strukturellen Eigenschaften eines Systems, die als Ganzes Aufschluss darüber geben, ob der Handlungsspielraum eines Unternehmens grösser oder kleiner wird.
Jede Architekturentscheidung wirkt sich auf diese Fähigkeit aus. Zu deren Beurteilung können sich Unternehmen an gewissen strategischen Signalen orientieren:
| Strategisches Signal | Die relevante Frage |
| Gesamtbetriebskosten TCO |
|
| Komplexität |
|
| Austauschbarkeit |
|
| Betriebsoberfläche |
|
| Interoperabilität |
|
| Beobachtbarkeit |
|
Diese Signale liefern keine eindeutige Antwort, sondern zeigen eine Richtung auf. Da die Souveränität sich laufend verändert, kommt der Richtung eine höhere Bedeutung zu als einzelnen Messwerten.
Ein einzelnes Zeichen lässt nie auf das grosse Ganze schliessen. Ein System kann bei der Austauschbarkeit gut abschneiden und dafür schlecht bei der Betriebsoberfläche. Es kann beobachtbar, aber hochkomplex sein. Es geht nicht darum, jeden Faktor für sich zu optimieren, sondern darum, alle zusammen als Muster zu lesen und zu verstehen, wie sich das Muster verändert.
Frameworks und Tools zur Unterstützung dieser Art von Bewertung sind im Entstehen begriffen. Plattformen wie soversanity.ch bieten einen strukturierten Ausgangspunkt für Unternehmen, die von einer intuitiven Herangehensweise zu einer systematischeren Auswertung dieser Signale übergehen wollen. Der Bereich der Sovereignty-as-Architecture ist noch jung. Bislang erfasst kein Tool seine ganze Komplexität. Doch die Richtung ist klar: Unternehmen, die heute mit der Messung beginnen, werden morgen handlungsfähiger sein.
Die Schweiz hat bedeutende gesetzliche Schritte in Richtung Open Source unternommen. Der Bund hat gemäss dem Bundesgesetz über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBAG) den Auftrag, Software wo immer möglich als Open Source zu veröffentlichen. Dies ist eine wichtige und begrüssenswerte Entwicklung, da sie eine klare Richtung vorgibt und die Unabhängigkeit fördert.
|
«Eine stärkere digitale Souveränität dank Open-Source-Technologien fördert nicht nur die Widerstandsfähigkeit unseres Landes, sondern ermöglicht es auch, die Wettbewerbsfähigkeit des IKT-Sektors zu verbessern, attraktive Arbeitsplätze zu schaffen und die Wertschöpfung in der Schweiz zu sichern.» Prof. Dr. Matthias Stürmer
|
|
Doch Open Source allein bedeutet nicht «souverän».
Ein System kann vollständig «open source» sein und dennoch:
zu komplex, als dass es ein Team von angemessener Grösse betreiben könnte
so eng gekoppelt, dass der Ersatz einer Komponente es erfordert, fünf andere neu zu entwickeln
in der Praxis vom Fachwissen eines einzigen Anbieters abhängen
von einer Stiftung verwaltet werden, deren Roadmap nicht auf die Bedürfnisse des Unternehmens abgestimmt ist
Open Source befasst sich mit der rechtlichen Dimension der Souveränität: dem Recht auf Einsichtnahme, Veränderung und Weitergabe. Die operative, architektonische oder Governance-Dimension wird nicht automatisch berücksichtigt. Eine Codebasis, die man besitzt, aber weder versteht noch ausführen oder weiterentwickeln kann, bringt keinen Mehrwert für die Souveränität. Es ist vielmehr eine Verbindlichkeit mit einer offenen Lizenz.
Was über Open Source hinaus benötigt wird, ist ein Bekenntnis zu modularen, austauschbaren Bausteinen – Systeme, die jedes Unternehmen einsetzen, betreiben und weiterentwickeln kann, ohne dass die ursprünglichen Autoren oder ein bestimmter Anbieter weiterhin beteiligt sein müssen. Dies legt die Messlatte höher und erfordert von Anfang an architektonische Disziplin.
Die Wahl von Architektur und Technologie schafft die Voraussetzungen für Souveränität. Doch mit den richtigen Bedingungen allein ist es nicht getan. Was sie aufrechterhält, sind Governance-Entscheidungen: wie Systeme finanziert, wie die Prioritäten für die Entwicklung gesetzt, wie Teams strukturiert und wie Abhängigkeiten im Laufe der Zeit bewertet werden.
Governance hält das Gefüge zusammen. Und genau in diesem Punkt scheitert die Souveränität in den meisten Unternehmen.
Eine auf Souveränität ausgerichtete Governance erfordert:
Explizite Prüfungen der Abhängigkeiten
Eine regelmässige Beurteilung, welche Abhängigkeiten irreversibel geworden sind und was es kosten würde, sie zu beenden
Disziplin bei der Mittelzuweisung
Reservieren eines bedeutenden Teils der IT-Investitionen für die strategische Entwicklung, nicht nur für die betriebliche Wartung
Erhalten von Fähigkeiten
Sicherstellung, dass das Wissen und die Fähigkeiten der internen Teams zum Betrieb der Kernsysteme erhalten bleiben, auch wenn externe Anbieter beteiligt sind
Dokumentation von Entscheidungen und Wissen
Sicherstellung, dass Entscheidungen, Systemkonfigurationen und Betriebsprozesse aufgezeichnet und im gesamten Unternehmen weitergegeben werden
Beschaffungskriterien, die architektonische Werte widerspiegeln
Bewertung von Anbietern nicht nur nach Features und Preis, sondern nach den Souveränitätseigenschaften der Komponenten wie Portabilität, Interoperabilität, Betriebstransparenz und Ausstiegsmöglichkeit
Laufende Überprüfung der Architektur
Behandlung der Souveränität als eine Eigenschaft, die es aktiv zu pflegen gilt, und nicht als Status, der einmal erreicht wurde und von dem man annehmen kann, dass er bestehen bleibt
Die Souveränität entsteht aus der Art und Weise, wie wir unsere Systeme finanzieren und weiterentwickeln, und nicht nur in den von uns gewählten Tools.
Aus diesem Grund muss die Debatte über digitale Souveränität über die Technologie-Teams hinaus auch die Bereiche Beschaffung, Finanzen und die Unternehmensleitung einbeziehen. Die Architektur-Entscheidungen sind wichtig. Die Governance-Entscheidungen bestimmen, ob diese architektonischen Eigenschaften im Laufe der Zeit tatsächlich beibehalten werden.
Unternehmen, die die Souveränität über einen längeren Zeitraum aufrechterhalten, sind in einem bestimmten Punkt diszipliniert: Sie behandeln die Betriebskosten als architektonischen anstatt betrieblichen Faktor. Sie treffen in der Design-Phase bewusste Entscheidungen, damit Systeme verständlich, kontrollierbar und entwicklungsfähig bleiben. Einige Praktiker haben begonnen, diese Prinzipien als betriebliche Leichtigkeit oder kurz LowOps zu bezeichnen. Die Bezeichnung ist weniger wichtig als die Disziplin, die sie beschreibt.
Diese Disziplin stützt sich auf fünf Grundsätze:
Secure by Design
Sicherheit muss eingebaut sein. Systeme mit weniger beweglichen Teilen haben weniger Fehlerquellen. Wenn die Eigenschaften der Sicherheit von ständigen manuellen Eingriffen abhängen, verschlechtern sie sich, sobald die Aufmerksamkeit auf etwas anderes gelenkt wird.
Souveräne Systeme sind so konzipiert, dass der sichere Weg der Standardweg ist.
Minimale Betriebsoberfläche
Jede Komponente, die zu einem System hinzugefügt wird, verursacht Kosten, die weit über die anfängliche Installation hinausgehen: für Überwachung, Instandhaltung, Aktualisierungszyklen, potenzielle Fehler und das erforderliche Fachwissen, um das System intakt zu halten.
Souveräne Systeme sind so gestaltet, dass diese Oberfläche bewusst minimiert wird. Braucht es für den Betrieb einer Komponente ein spezielles Team, ist sie ein Kandidat für eine Vereinfachung oder einen Ersatz.
Automation First
Manuelle Prozesse sind der Gegenspieler eines nachhaltigen Betriebs. Sie erfordern die Verfügbarkeit von Menschen, bringen Schwankungen mit sich und führen zu viel undokumentiertem Wissen, das mit Mitarbeitenden das Unternehmen verlässt.
Das Ziel ist ein System, bei dem Routinevorgänge keinerlei menschliche Entscheidungen mehr erfordern. Pipelines ersetzen Verfahren. Die Automatisierung ersetzt die Rituale.
Ersetzbar by Design
Jede Komponente sollte unter der Annahme entwickelt werden, dass sie irgendwann ersetzt wird. Das bedeutet Einhalten von offenen Standards wo immer möglich, dokumentierte Verträge und zustandsloses Design sowie Dateneigentum getrennt von der Verarbeitungslogik.
Ein auf Ersetzbarkeit ausgelegtes System ist eines, das sich ohne organisatorisches Trauma weiterentwickeln lässt.
Beobachtbar by Default
Man kann nicht steuern, was man nicht sieht. Überwachung, Protokollierung und Rückverfolgung müssen vom ersten Tag an vorhanden sein.
Beobachtbare Systeme verringern die für die Reaktion auf Vorfälle erforderlichen Fachkenntnisse, machen die Kapazitätsplanung überschaubar und liefern die Grundlage für Governance-Entscheidungen.
Diese Grundsätze gewährleisten die langfristige Flexibilität des Budgets und verringern die Anfälligkeit des Systems. Sie stellen zudem sicher, dass die Kosten für den Betrieb in einem angemessenen Verhältnis zum erbrachten Wert stehen und nicht zu der bei der Errichtung erzeugten Komplexität.
Die Frage, die man sich bei jedem System stellen sollte, ist einfach: Erfordert sein Betrieb einen übermässigen Aufwand? Lautet die Antwort ja, ist die Souveränität gefährdet.
Digitale Souveränität ist eine Meta-Anforderung.
Sie wird nicht durch Absichtserklärungen, Angleichung der regulatorischen Vorgaben oder isolierte technologische Entscheidungen erreicht. Sie entsteht – oder erodiert – durch die Strukturen, die Unternehmen aufbauen, und die Entscheidungen, die sie im Laufe der Zeit treffen. Entscheidend ist nicht, wo die Systeme gehostet oder wie sie lizenziert werden, sondern ob sie unter realen Bedingungen verständlich, bedienbar und entwicklungsfähig bleiben.
Souveränität ist dann gegeben, wenn die Architektur die Komplexität begrenzt, die Ersetzbarkeit gewährleistet und den Betriebsaufwand im Verhältnis zum Nutzen hält. Sie besteht fort, wenn die Governance diese Eigenschaften vor kurzfristigem Druck schützt.
Die Schlüsselfrage ist folglich nicht, ob sich ein Unternehmen zur Souveränität bekennt, sondern ob seine aktuellen Entscheidungen seine künftige Handlungsfreiheit erhöhen oder verringern.