Technische Integration nach der Akquisition · nicht-vertraulicher Überblick
Anforderungsdefinition auf Engineering-Seite, Architekturauswahl und Koordination der Umsetzung, um die Flugtest-Datenanalyse von Kopter in die Unternehmens-IT von Leonardo zu integrieren – ohne den Flugtestbetrieb anzuhalten.
01 — Kontext und Auslöser
Nach der Übernahme von Kopter durch Leonardo startete die Unternehmens-IT eine konzernweite Initiative zur Konsolidierung von IT-Diensten, Notebooks, Rechenzentren und Infrastruktur – vor allem, um doppelte Systeme abzubauen und die bestehende Schweizer Rechenzentrums-Infrastruktur stillzulegen. Treiber waren die Integration nach der Akquisition und Kosteneffizienz, nicht etwa Mängel in der Cybersicherheit auf Kopter-Seite.
Die Umgebung der Flugtest-Datenanalyse (FTDA) arbeitete jedoch unter grundlegend anderen Bedingungen als die Büro-IT: Flugtestkampagnen zu unterstützen erforderte lokale administrative Autonomie, eigene Python-Verarbeitungsketten, automatisierte Aufgabenplanung und die schnelle Bereitstellung von Flugdaten an die Engineering-Teams.
Als benannter IT-Ansprechpartner des FTDA-Teams habe ich das Flugtest-Engineering von der frühen Sondierungsphase an vertreten. Das Grundziel war klar: alle für den Flugtest nötigen betrieblichen Fähigkeiten innerhalb der Leonardo-Unternehmensumgebung erhalten und verbessern, ohne jede Betriebsunterbrechung.
Das war eine über mehrere Jahre laufende Aufgabe und keine einmalige Umstellung: Die Sondierung begann Ende 2023, die ersten Anforderungsentwürfe und die Gespräche mit den Beratern liefen im ersten Halbjahr 2024, die technische Umsetzung startete um Juni 2024, und Architektur-, Migrations- und Umsetzungsarbeiten setzten sich über 2025 und 2026 fort. Die Umgebung ist im Einsatz, einzelne Integrationspunkte werden noch abgeschlossen.
02 — Betriebliche Randbedingungen
Die FTDA-Systeme direkt in die Standard-Unternehmens-IT zu überführen war nicht praktikabel. FTDA brauchte Fernzugriff auf Server, flexible Installation von Python-Software und Paketen, automatisierte geplante Aufgaben, administrative Rechte für die Datenübernahme, Zertifikatsverwaltung für interne Dashboards und eine enge Anbindung an die Flugtest-Instrumentierung (FTI).
Die Unternehmensrichtlinien untersagen lokale Administratorrechte auf verwalteten Arbeitsplätzen strikt. Der Weg über IT-Helpdesk-Tickets für alltägliche Engineering-Skripte und geplante Aufgaben wurde geprüft, doch ein ticketbasiertes Modell war mit dem Umfang und dem Tempo der täglichen Skript- und Werkzeugarbeit, auf die der Flugtestbetrieb angewiesen ist, nicht vereinbar.
Hinzu kam: Während der Entwicklungskampagnen mussten die Daten das Leonardo-Engineering innerhalb von rund 2 Stunden nach der Landung erreichen, um Go/No-go-Entscheidungen für Folgeflüge zu stützen. Die zentrale Aufgabe war daher, ein Architektur- und Betriebsmodell zu finden, das strenge Cybersicherheitsregeln erfüllt, ohne die Beweglichkeit im Engineering zu ersticken.
03 — Architektur-Abwägungen
Vollständig verwaltete Unternehmensumgebung. Sie bot die Anbindung an Unternehmensdienste, beschränkte aber die für die FTDA-Automatisierung nötigen Administratorrechte – geplante Aufgaben, eigene Python-Werkzeuge und agile Skriptentwicklung.
Ein isoliertes Engineering-Netz, physisch und logisch von den Unternehmenssystemen getrennt. Es erhielt die volle betriebliche Autonomie, schuf aber eine Insel ohne direkte Verbindung zu Leonardo-Diensten und behinderte Datenverteilung und Fernzusammenarbeit erheblich.
Die gewählte Zielarchitektur. Ein etabliertes Leonardo-Modell mit einer abgetrennten Engineering-Zone samt lokaler administrativer Autonomie, über streng geregelte Firewalls und überwachte Pfade an die Unternehmensdienste angebunden.
Das Leonardo Business Network (LBN) war eine etablierte Unternehmensarchitektur. Auf Basis der betrieblichen FTDA-Anforderungen habe ich die drei Optionen bewertet und das LBN als Lösung für das Flugtest-Engineering ausgewählt. Die Fachteams von Leonardo verantworteten und implementierten Unternehmensnetz, Routing, virtuelle Desktops und Firewall-Richtlinien, während bei mir die Anforderungen auf Engineering-Seite, die technische Abnahme und das lokale FTDA-Firewall-Mapping lagen.
Gewähltes Betriebsmodell
Das gewählte LBN-Modell hält spezialisierte Flugtest-Engineering-Fähigkeiten in einer abgetrennten Umgebung und bindet sie über geregelte Schnittstellen an Leonardo-Unternehmensdienste an. Antoine verantwortete Anforderungen, Auswahl, technische Abnahme und Koordination auf Engineering-Seite; die Leonardo-Fachteams verantworteten die Umsetzung der Unternehmensinfrastruktur.
LBN
Leonardo
Freigegebene Flugtestergebnisse
04 — Rollenentwicklung und Verantwortung
Zunächst waren externe Berater beauftragt, Anforderungen aufzunehmen und Lösungswege zu prüfen. Ihr Mandat endete später. Nach ihrem Weggang wurde keine formale Projekt- oder Programmleitung für den FTDA-Strang benannt. Ohne formalen Titel habe ich die Umsetzungskoordination schrittweise faktisch übernommen: betriebliche Meilensteine definiert, ein Jira-Epic samt Aufgaben geführt, Blockaden über matrixorganisierte Teams nachverfolgt, Engpässe eskaliert, die technische Abnahme durchgeführt und die Umstellung der Nutzenden geleitet.
05 — Umsetzung und Abhängigkeitsmanagement
Nach dem Weggang der Berater habe ich den Engineering-Strang um eine einzige Leitfrage gebaut: „Was muss funktionieren, damit wir arbeiten wie zuvor?“
Die Umsetzung verlief entlang funktionaler Fähigkeiten statt eines starren linearen Zeitplans – mit gezielter Koordination, Jira-Nachverfolgung und Eskalation ohne hierarchische Weisungsbefugnis, um Abhängigkeiten zwischen Unternehmens-IT, Netzwerk, Cybersecurity, Cloud und Engineering aufzulösen.
Überführung der FTDA- und FTI-Abläufe in klare technische Kriterien für administrative Autonomie, Speicher, Fernzugriff und Bereitstellungszeit.
Bewertung dreier Netzmodelle gegen die betrieblichen Anforderungen und Auswahl des LBN als tragfähige Balance zwischen Sicherheit und Autonomie.
Integration der lokalen Hardware und Konfiguration der FTDA-Firewall für das IP-Adressmapping in das Leonardo-Unternehmensnetz.
Validierung und Rollout der Virtual Desktop Infrastructure, um den sicheren Fernzugriff auf interne Verarbeitungsrechner wiederherzustellen.
Spezifikation von rund 100 TB Cloud-Speicherkapazität und Durchsetzung des Zielrollouts über temporäre Behelfslösungen hinaus, mittels Eskalation.
Koordination der engineering-seitigen Migration des zentralen DIAdem-Datenzugriffsdienstes auf einen neuen Server im Konzernrechenzentrum, mit wiederhergestellten Zugängen, Verbindungsanleitungen und Lizenzen für rund 50 nachgelagerte Ingenieure.
Beibehaltung der bisherigen Zugänge, bis die Abläufe gegen die Abnahmeliste geprüft waren, Erstellung der Benutzerdokumentation und Umstellung der Nutzenden ohne Ausfallzeit.
Fortbestehende Engineering-Verantwortung für Weiterentwicklungen der Umgebung, neue Nutzende, Hardwareerneuerung und verbleibende Störungsbehebung.
06A — Blockade gelöst
Kontext: Die routinemässige Freigabe einer wesentlichen Netzwerkfreigabe für Code-Management und Auswertung lag wochenlang still, nachdem eine freigebende Person in der Kette ohne benannte Übergabe ausgeschieden war.
Vorgehen: Die mehrstufige Freigabekette über Cybersecurity und IT nachgezeichnet, den verwaisten Antrag in der Warteschlange gefunden, die zuständigen Abteilungsleitungen erneut eingebunden und eskaliert, bis der Prozess wieder lief.
Ergebnis: Der stockende Freigabeprozess wurde gelöst, und die beantragte Netzwerkfreigabe konnte den Governance-Prozess durchlaufen.
06B — Blockade gelöst
Kontext: Eine temporäre Dateiübertragungslösung hielt den Tagesbetrieb am Laufen, wodurch die Konzernteams den dauerhaften Cloud-Speicher-Rollout nachrangig behandelten.
Vorgehen: Die betrieblichen Grenzen und die langfristige Untauglichkeit der Übergangslösung aufgezeigt, kontinuierlich fachlich nachgehalten und den Engpass bis auf CIO-Ebene eskaliert.
Ergebnis: Die Priorität für den Rollout der dauerhaften Lösung mit rund 100 TB Cloudspeicher wurde wiederhergestellt.
07 — Betriebliche Kontinuität
Flugtestkampagnen liessen sich für eine IT-Integration nicht pausieren. Durchgehende betriebliche Kontinuität war eine nicht verhandelbare Anforderung.
Statt einer risikoreichen Umstellung wurden die bisherigen Notebooks und Netzpfade parallel zur neu ausgegebenen Konzern-Hardware weiterbetrieben.
Der Betrieb mit doppelter Hardware brachte vorübergehend administrativen Mehraufwand, bot aber einen garantierten Rückfallweg. Die bisherigen Zugänge blieben erhalten, bis die erforderlichen FTDA-Abläufe gegen die Abnahmeliste geprüft waren. Die Migration gelang mit null Betriebsunterbrechung im Flugtest.
08 — Kontrollierte Datenverteilung
Die Trennung der Engineering-Umgebung vom Büronetz bedeutete, den bisherigen direkten Zugriff auf Dateifreigaben durch einen konformen, automatisierten Verteilweg zu ersetzen.
Ich habe an der Definition des sicheren Verteilprozesses mitgewirkt, der freigegebene Flugdatensätze von lokalen LBN-Verarbeitungsrechnern in den Cloudspeicher des Konzerns und zu den nachgelagerten Engineering-Nutzenden bringt.
Flugtestdaten werden in der LBN-Zone übernommen und verarbeitet, wo administrative Autonomie und spezialisierte Python-Werkzeuge erhalten bleiben.
Verarbeitete Flugtestdatensätze werden über gesicherte ausgehende Pfade automatisch in die Cloud-Umgebung des Konzerns geladen.
Hochgeladene Pakete durchlaufen die Sicherheitsvalidierung und Zugriffskontrollen des Konzerns, bevor sie für berechtigte Nutzerkreise freigegeben werden.
Freigegebene Flugtestdaten erreichen rund 50 DIAdem-Fachleute, und verteilte Berichte gehen an bis zu rund 200 weitere Beteiligte.
Der Ablauf ist bewusst nicht vertraulich dargestellt; interne Adressen, Firewall-Konfigurationen, Cloud-Mandantennamen, Zugangsdaten und Sicherheitsprodukte bleiben ausgespart.
09 — Umfang und Grössenordnung
Diese Nutzerzahlen bezeichnen unterschiedliche Gruppen auf verschiedenen Nutzungsebenen und dürfen nicht zu einer künstlichen Gesamtzahl addiert werden; sie sind auch nicht dieselbe Gruppe wie die Datennutzenden in der Fallstudie zum Flugtest-Datenbetrieb. Die Hardware im Umfang (~15 Server und Arbeitsplätze sowie mehrere Speicherplattformen) wurde vor Ort integriert und neu konfiguriert statt physisch ersetzt. Die Architektur erhielt die betriebliche Fähigkeit, Flugtestdaten dem Engineering innerhalb von rund zwei Stunden nach der Landung bereitzustellen.
10A — Verantwortung nach der Übergabe
Ich bin weiterhin der zentrale Engineering-Ansprechpartner für die LBN-Umgebung: Bedarfe klären, Hardwareerneuerung koordinieren, Speicher- und Firewall-Anfragen betreuen und domänenübergreifende Abhängigkeiten lösen, etwa die Authentifizierung von Freigaben in gemischten Domänenumgebungen.
10B — Wiederverwendung der Architektur
Der bei der Hauptmigration etablierte Integrationsansatz wurde später für ein mobiles Offsite-LBN wiederverwendet und replizierte die Kernarchitektur für eine längere Flugtestkampagne abseits des Hauptstandorts.
11 — Was diese Integration verlangt hat
Die Arbeit bestand darin, spezialisierte betriebliche Anforderungen in eine Architekturentscheidung zu überführen, die Fachteams umsetzen konnten, und diese Entscheidung dann durch die Konzern-Governance zu bringen: Meilensteine entlang von Fähigkeiten, beharrliches Nachhalten von Blockaden, Eskalation bei stockenden Freigabeketten, technische Abnahme gegen betriebliche Kriterien und eine Umstellung, bei der der Flugtestbetrieb durchgehend weiterlief.
Der Bereich auf Engineering-Seite lag bei mir; Unternehmensnetz, virtuelle Desktops und Cloud-Umsetzung lagen bei den Fachteams von Leonardo. Was danach bei mir bleibt, ist die Umgebung selbst: ihre Weiterentwicklung, ihre neuen Nutzenden und die verbleibende Störungsbehebung.