Netzwerkarchitektur

Stand: August 2026

Widrigkeiten 2026: Woran globale Solution-Architektur-Projekte hängen bleiben

Wer 2026 in einem internationalen Konzern eine Solution Architecture plant, verliert die meiste Zeit nicht mehr bei der Technologieauswahl. Verzögert wird dort, wo IT auf OT trifft, wo (gerade in internationalen Betrieben) Regulatorik Freigaben erzwingt und wo niemand mehr genau weiß, was im Netz eigentlich hängt. Dieser Artikel beantwortet eine Frage aus der Praxis: Warum dauern globale Architekturprojekte heute so viel länger als geplant und was lässt sich auf Netzwerk- und OT-Ebene konkret dagegen tun?

Von Jens Thies · IT by PASSION

Der Engpass hat sich verschoben: von der Technik zur Freigabe

Vor zehn Jahren scheiterten Architekturprojekte an Technik: falsche Plattform, unterschätzte Last, inkompatible Schnittstellen. 2026 sieht das anders aus. Die Plattformen sind ausgereift, Referenzarchitekturen für Cloud, Edge und Industrie 4.0 existieren, und mit OPC UA hat sich in der Produktion ein tragfähiger Interoperabilitätsstandard etabliert. Verzögert wird heute in den Phasen davor und dazwischen: bei der Bestandsaufnahme, bei Governance-Freigaben, bei Sicherheits- und Datenschutz-Reviews und bei der Abstimmung zwischen IT-Organisation und Produktionsbetrieb.

In meinen Projekten zeigt sich ein wiederkehrendes Muster: Das eigentliche Lösungsdesign - Zielbild, Datenflüsse, Komponenten - ist in Wochen erledigt. Die Monate davor gehen für Discovery drauf, die Monate danach für Freigabezyklen. Wer Projektpläne realistisch aufsetzen will, muss diese beiden Blöcke einpreisen, nicht das Design.

Widrigkeit 1: IT/OT-Konvergenz beginnt mit einer Inventur, die keiner machen will

Der größte einzelne Verzögerungsfaktor in Industrieumgebungen ist die Verbindung von Produktionsanlagen mit Cloud-, KI- und ERP-Plattformen. Das Problem ist selten das Zielbild, sondern der Ausgangszustand. Typische Befunde aus der Asset Discovery:

  • Steuerungen und Anlagen mit Lebenszyklen von 15 bis 30 Jahren, deren Netzwerkanbindung nie dokumentiert wurde. Oft mit flachen Netzen, in denen Engineering-Stationen, HMIs und SPSen im selben Broadcast-Segment liegen.
  • Proprietäre Protokolle (Profinet, EtherNet/IP, Modbus TCP, S7-Kommunikation), die sich nicht ohne Weiteres durch Firewalls oder über geroutete Segmente führen lassen, weil sie auf Layer-2-Nachbarschaft oder feste Latenzen angewiesen sind.
  • Unklare Zuständigkeiten: Das Anlagennetz „gehört" dem Maschinenlieferanten, dem Instandhalter oder niemandem - jedenfalls nicht der IT.

Für die Solution Architecture bedeutet das: Bevor irgendein Datenfluss Richtung Cloud designt werden kann, braucht es eine belastbare Netz- und Asset-Inventur. Passive Discovery über Mirror-Ports oder TAPs ist hier der richtige Weg - aktive Scans können ältere Steuerungen zum Absturz bringen. Diese Phase dauert in einem Werk realistisch mehrere Wochen, über einen globalen Werksverbund Monate. Projekte, die sie überspringen, holen sie später unter Zeitdruck nach, dann aber mit Produktionsrisiko.

Dazu kommt der Faktor Downtime: Integrationstests an realen Anlagen brauchen Wartungsfenster, und die gibt es in vielen Werken meißt nur ein- bis zweimal im Jahr. Ein verpasstes Fenster verschiebt den Rollout nicht um Tage, sondern um Monate. Wer das in der Architekturplanung nicht als harten Meilenstein führt, plant an der Realität vorbei.

Widrigkeit 2: Regulatorik ist 2026 keine Ankündigung mehr, sondern geltendes Recht

Die zweite große Bremse sind regulatorische Anforderungen, die inzwischen unmittelbar wirken und in Architekturentscheidungen hineinreichen.

NIS2 gilt - ohne Übergangsfrist

Das deutsche NIS2-Umsetzungsgesetz (NIS2UmsuCG) ist seit dem 6. Dezember 2025 in Kraft, die Registrierungsfrist beim BSI ist am 6. März 2026 abgelaufen. Betroffen sind rund 29.500 Unternehmen - darunter viele Fertigungsbetriebe, Maschinenbauer und Zulieferer, die sich bislang nicht als KRITIS verstanden haben. Für Architekturprojekte heißt das: Risikomanagement, Meldeprozesse und technische Maßnahmen wie Segmentierung, Zugriffskontrolle und Backup-Konzepte sind keine optionalen Qualitätsmerkmale mehr, sondern Prüfpunkte, an denen Freigaben hängen. Seit dem 17. März 2026 ergänzt zudem das KRITIS-Dachgesetz Anforderungen an die physische Resilienz kritischer Anlagen.

EU AI Act: teilweise verschoben, aber nicht vom Tisch

Beim EU AI Act hat der „Digital Omnibus" (Verordnung (EU) 2026/1744, in Kraft seit Ende Juli 2026) die vollen Hochrisiko-Pflichten nach Anhang III auf den 2. Dezember 2027 verschoben, für KI in regulierten Produkten auf August 2028. Die Transparenzpflichten gelten dagegen seit dem 2. August 2026. In der Projektpraxis ändert die Verschiebung wenig am Aufwand: Wer KI-Funktionen in eine Architektur einplant, muss Systeminventar, Risikoklassifizierung und Daten-Governance ohnehin jetzt aufbauen - sonst wird 2027 aus der Verschiebung ein Rückstau.

Data Act und Datenhoheit

Der EU Data Act ist seit dem 12. September 2025 anwendbar und macht unter anderem Cloud-Wechselfähigkeit zur Vertragspflicht; Wechselgebühren entfallen ab Januar 2027 vollständig. Zusammen mit regionalen Datenresidenz-Anforderungen (etwa in China oder im US-Kontext) zwingt das globale Konzerne, Datenhaltung und KI-Workloads regional zu denken. Architektonisch bedeutet das: keine zentrale „One Cloud"-Landezone mehr, sondern regionalisierte Deployments - mit allem, was das für WAN-Design, Breakout-Standorte, Latenz und Betriebsmodelle nach sich zieht.

Widrigkeit 3: Zero Trust trifft auf ein Brownfield, das dafür nie gebaut wurde

Zero Trust ist 2026 in praktisch jeder Konzern-Security-Strategie gesetzt. In der OT kollidiert das Konzept aber mit der Realität: Anlagen ohne Benutzerkontext, geteilte Engineering-Accounts, Systeme ohne MFA-Fähigkeit, Patchstände, die sich nur im Jahreswartungsfenster ändern lassen. Wer versucht, IT-Zero-Trust-Muster eins zu eins in die Produktion zu tragen, produziert Verzögerungen - oder Stillstände.

Die tragfähige Antwort liegt auf Netzwerkebene. Wo identitätsbasierte Kontrollen am Endpunkt nicht möglich sind, übernehmen kompensierende Kontrollen im Netz, Zonen und Conduits nach IEC 62443, Mikrosegmentierung dort, wo die Netzstruktur es hergibt, kontrollierte Übergänge zwischen den Ebenen des Purdue-Modells, gehärtete Jump-Hosts für Fernzugriffe statt direkter VPN-Tunnel in die Anlagenebene. Das ist weniger elegant als ein durchgängiges Identity-Modell, aber es ist umsetzbar, auditierbar und mit NIS2 wie IEC 62443 vereinbar. Projekte, die diese Übersetzungsleistung (Zero-Trust-Prinzipien in OT-taugliche Netzkontrollen) früh einplanen, verlieren später deutlich weniger Zeit in Security-Reviews.

Auch hier kann in einigen Fällen die schrittweise Implementierung von NetFoundry OpenZiti das Maß aller Dinge sein, muss jedoch ebenso genau geprüft werden.

Widrigkeit 4: Plattformvielfalt und die unterschätzte Netzwerkfrage

Große Unternehmen betreiben heute parallel zwei bis drei Hyperscaler, SaaS-Plattformen, On-Premises-Kubernetes und Edge-Cluster in den Werken. Jede dieser Plattformen bringt eigenes IAM, eigenes Netzwerkmodell und eigene Observability mit. Für den Solution Architect entsteht daraus ein Integrationsproblem, das häufig auf der untersten Ebene übersehen wird: dem Netz.

KI- und IoT-Anwendungen scheitern in der Umsetzung selten am Modell, sondern an Latenz, Bandbreite und Segmentierung. Ein Inferenz-Workload, der Kameradaten aus der Linie verarbeitet, gehört an die Edge und nicht, weil es modern klingt, sondern weil der Rückweg über das zentrale Rechenzentrum die Latenzbudgets sprengt und OT-Netzsegmente nicht ungefiltert in die Cloud "leaken" dürfen. Solche Entscheidungen (Edge vs. Cloud, lokaler Breakout vs. zentrales WAN, dedizierte OT-DMZ pro Werk) müssen in der Architekturphase fallen. Werden sie vertagt, tauchen sie in der Umsetzung als Change Requests wieder auf - jeder davon mit eigenem Freigabezyklus.

Widrigkeit 5: Die derzeitige politische und wirtschaftliche Lage weltweit

Lieferzeiten für Server, Grafikkarten, RAM, ASICs u.v.m. verlängern sich stetig weiter. Ebenso steigen die Preise. Die Kosten eines Server im September 2025 sind bis Juni 2026 um ein vier- bis fünffaches gestiegen und die Preise steigen weiter. Ebenso für Firewalls und andere Sicherheitsgeräte. Server können z.T. nur ohne RAM gekauft werden. Mit jedem Monat einer Verlängerung einer Lieferzeit verlängert sich auch die Ausführung des Projekts. Wie weit das noch geht, kann derzeit niemand wirklich abschätzen.

Rechnen Sie von Anfang an den X-fachen Preis der benötigten Hardware ein? Ist das zu viel oder zu wenig? Verzögert sich darum auch der Wifi-Site-Survey des Anbieters mit den Spezialisten und Hardware dafür?

Was in der Praxis gegen die Verzögerungen hilft

Aus den Projekten der letzten Jahre lassen sich einige Muster ableiten, die den Unterschied machen:

  1. Discovery vor Design. Eine strukturierte Architecture-Discovery-Phase (Assets, Netze, Datenflüsse, Verantwortlichkeiten) gehört an den Projektanfang - mit eigenem Budget und eigenem Zeitfenster. Sie ist keine Verzögerung, sie verhindert welche.
  2. Gemeinsame IT/OT-Teams statt Übergabepunkte. Solange IT plant und OT „nur" umsetzt, entstehen an jeder Schnittstelle Rückfragen und Eskalationen. Gemischte Architektur-Teams mit Werksvertretern verkürzen Entscheidungswege messbar.
  3. Security und Compliance ab Tag 1. NIS2-Anforderungen, IEC-62443-Zonenkonzepte und Datenresidenz-Vorgaben gehören in die erste Architekturskizze, nicht in den finalen Review. Nachträglich eingebaute Sicherheit ist der teuerste Weg.
  4. Wartungsfenster als harte Meilensteine führen. Downtime-Fenster der Werke gehören in den Projektplan wie Vertragstermine. Wer sie kennt, plant Integrationstests rückwärts von dort.
  5. Architektur als lebendes Artefakt. Bei monatlich wechselnden Business-Prioritäten trägt kein Big Design Up Front. Ein gepflegtes Architektur-Repository mit versionierten Entscheidungen (Architecture Decision Records) hält Reviews kurz, weil Gremien nachvollziehen können, was sich warum geändert hat.
  6. Hardware gleich oder zeitnah bestellen. Sobald wirklich klar ist, welche Hardware benötigt wird, sollte sie bestellt werden. Die Lieferung verzögert sich? Dann sollte mit dem Lieferanten verhandelt werden, dass die Lizenzen erst ab Einsatz und nicht ab Kauf anfangen, zeitlich abzulaufen..

Fazit

Die Widrigkeiten globaler Solution-Architektur-Projekte 2026 sind zum größten Teil organisatorischer und regulatorischer Natur: unbekannte Brownfield-Bestände, IT/OT-Zuständigkeitslücken, verbindlich gewordene Regulatorik und Freigabeprozesse, die auf diese Gemengelage nicht vorbereitet sind. Die Technik ist selten das Problem. Wer Discovery, Segmentierung und Compliance von Anfang an als Architekturaufgaben behandelt statt als nachgelagerte Pflichten, gewinnt genau die Monate zurück, die diese Projekte heute typischerweise verlieren. Was die derzeitige globale politische und wirtschaftliche Lage betrifft: alle Betroffenen eines Unternehmens sollten sich über die Vorgehensweise gemeinsam beraten und einigen.

Hinweis

Dieser Artikel gibt die persönliche fachliche Einschätzung des Autors zum Stand bei Veröffentlichung wieder. Er ersetzt keine Beratung im Einzelfall. Angaben zu Normen, Fristen, Versionen und Herstellerfunktionen sollten vor einer Entscheidung geprüft werden. Alle Inhalte ohne Gewähr.