Netzwerkarchitektur

Stand: Januar 2026

Warum Netzwerkarchitektur eine Business-Entscheidung ist und nicht nur eine IT-Entscheidung

Ob ein Unternehmen liefern kann, wie schnell es neue Standorte und Geschäftsmodelle anbindet und wie weit sich ein Sicherheitsvorfall ausbreitet, all das wird in der Netzwerkarchitektur entschieden. Oft geschieht dies Jahre bevor der Fall eintritt. Trotzdem wird das Netz in vielen Häusern noch als reiner Kostenblock der IT geführt und nach Hardware-Abschreibungszyklen geplant. Das ist ein Managementfehler mit bezifferbaren Folgen: Ausfallkosten, verlorene Kundeninteraktionen, verzögerte Projekte und seit Dezember 2025 auch eine persönliche Verantwortung der Geschäftsleitung. Dieser Beitrag ordnet ein, an welchen Stellen Architekturentscheidungen unmittelbar auf das Geschäft wirken und welche Fragen die Geschäftsführung dazu stellen sollte.

Von Jens Thies · IT by PASSION

Das Netz ist keine Infrastruktur im Hintergrund mehr, sondern Betriebsvoraussetzung

Praktisch jeder Umsatzprozess läuft heute über das Netzwerk. Die Auftragsannahme im ERP, die Maschinensteuerung in der Fertigung, die Logistikanbindung, der Webshop, die Telefonie, die Cloud-Dienste, ebenso die Fernwartung. Fällt das Netz aus, fällt nicht „die IT" aus, es fällt das Unternehmen aus. Die Größenordnung ist gut dokumentiert: Eine 2025 veröffentlichte Studie im Auftrag von Fluke beziffert die Verluste deutscher Hersteller durch ungeplante Ausfallzeiten auf rund 44 Milliarden Euro pro Jahr mit durchschnittlichen Kosten von etwa 1,5 Millionen Euro je Stillstandsstunde. Splunk kommt in seiner Downtime-Untersuchung auf durchschnittliche jährliche Ausfallkosten von rund 255 Millionen Euro je betroffenem deutschen Großunternehmen, und der Siemens-Report „True Cost of Downtime" schätzt die Verluste der 500 größten Unternehmen weltweit auf rund 11 Prozent ihres Umsatzes.

Entscheidend ist jedoch folgendes: Ob ein technischer Fehler oder ein Angriff eine dieser teuren Stunden auslöst oder eine ganze Woche, ist keine Frage des Zufalls, sondern der Architektur. Ein sauber segmentiertes Netz mit definierten Fehlerdomänen begrenzt einen Vorfall auf eine Zelle, eine Linie, einen Standort. Ein historisch gewachsenes, flaches Netz (in dem Office-IT, Server, Produktion und Gebäudetechnik in wenigen großen Broadcast-Domänen zusammenhängen) macht aus jedem lokalen Problem ein Unternehmensproblem. Diese Weiche wird nicht im Krisenstab gestellt, sondern Jahre vorher im Architekturentwurf.

Vier Hebel, über die Architektur auf das Geschäft wirkt

Umsatz und Lieferfähigkeit

Verfügbarkeit ist eine Architektureigenschaft, kein Produktmerkmal, das man nachträglich kauft. Redundante Wege, getrennte Fehlerdomänen, unabhängige Stromversorgung der Netzknoten, saubere Layer-3-Grenzen statt gestreckter Layer-2-Konstrukte über Standortgrenzen hinweg, das sind die unspektakulären Entscheidungen, die darüber bestimmen, ob ein Komponentenausfall unbemerkt bleibt oder die Produktion steht. In OT-Umgebungen kommt hinzu: Verlorene Fertigungsstunden lassen sich anders als verzögerte Büroarbeit nicht nachholen. Eine Stunde Stillstand einer Montagelinie ist endgültig verlorener Output in einer Just-in-time-Kette mit Vertragsstrafen oft mit Folgekosten weit über den reinen Produktionswert hinaus.

Kundenerlebnis

Jede digitale Interaktion mit Kunden (über ein Portal, Konfigurator, API-Anbindungen, Service-Hotline, Tracking) läuft über Netzstrecken, deren Latenz, Priorisierung und Ausfallsicherheit in der Architektur festgelegt sind. Wer Standorte über unterdimensionierte Leitungen ohne Quality of Service anbindet oder alle Internet-Übergänge durch ein zentrales, überlastetes Rechenzentrum zwingt, produziert träge Anwendungen und abgebrochene Sitzungen, die im Vertrieb als „schlechter Service" ankommen. Umgekehrt sind lokale Internet-Breakouts, sauberes Traffic-Engineering und redundante Provider-Anbindungen keine Technik-Feinheiten, sondern direkte Stellgrößen für die wahrgenommene Qualität digitaler Angebote.

Time-to-Market

Wie schnell ein neuer Standort produktiv wird, eine zugekaufte Firma integriert ist oder eine neue Maschinenlinie ans Netz geht, hängt weniger vom Projektmanagement ab als von der Architektur, auf die diese Projekte treffen. Ein standardisiertes Zielbild, einheitliche Adress- und Segmentierungskonzepte, definierte Übergabepunkte zwischen IT und OT, automatisierte Provisionierung, dokumentierte Firewall-Regelwerke, reduziert die Anbindung eines Standorts von Monaten auf Wochen. Fehlt das Zielbild, wird jedes Projekt zur Einzelanfertigung: Adresskonflikte bei Übernahmen, handgepflegte Sonderregeln, Abhängigkeit von einzelnen Wissensträgern. Diese technische Schuld taucht in keiner Bilanz auf, bremst aber jede strategische Initiative von der Cloud-Migration bis zum neuen datengetriebenen Serviceangebot.

Sicherheit und Haftung

Mit dem NIS2-Umsetzungsgesetz, das am 6. Dezember 2025 ohne Übergangsfrist in Kraft getreten ist, ist Cybersicherheit in Deutschland formal Chefsache geworden. Rund 30.000 Unternehmen fallen in den Anwendungsbereich. Das sind deutlich mehr als die bisherigen KRITIS-Betreiber, darunter viele Mittelständler aus Fertigung, Maschinenbau, Chemie und Logistik ab 50 Beschäftigten oder 10 Millionen Euro Umsatz. Die Registrierungsfrist beim BSI lief bereits im März 2026 ab; bei Verstößen drohen Bußgelder bis 10 Millionen Euro oder 2 Prozent des weltweiten Umsatzes. Vor allem aber verpflichtet das Gesetz die Geschäftsleitung persönlich, die Risikomanagementmaßnahmen zu billigen und ihre Umsetzung zu überwachen. Delegieren lässt sich diese Verantwortung nicht.

Aus Architektursicht ist der Punkt einfach: Fast alle geforderten Maßnahmen (Risikobeherrschung, Angriffsflächenreduktion, Erkennung, Eindämmung von Vorfällen) setzen ein strukturiertes Netz voraus. Zonen und Übergänge nach IEC 62443, kontrollierte IT/OT-Übergabepunkte, nachvollziehbare Kommunikationsbeziehungen und Zero-Trust-Prinzipien sind die technische Grundlage, auf der ein Risikomanagement überhaupt glaubwürdig wird. Wer auf einem flachen, undokumentierten Netz ein ISMS betreibt, dokumentiert im Ernstfall vor allem, dass die organisatorischen Maßnahmen ohne technisches Fundament blieben. Das impliziert gegenüber Aufsicht, Cyberversicherer und Kunden-Audits eine schlechte Position.

Warum diese Entscheidungen auf die C-Level-Agenda gehören

Drei Eigenschaften unterscheiden Architekturentscheidungen von gewöhnlichen IT-Beschaffungen. Erstens ihre Reichweite: Netzarchitekturen leben 7 bis 10 Jahre. In der OT mit Anlagenlaufzeiten von 15 bis 25 Jahren noch oft deutlich länger. Wer heute ein Segmentierungskonzept festlegt oder eben darauf verzichtet, legt fest, mit welchem Risiko- und Kostenprofil das Unternehmen bis weit in das nächste Jahrzehnt arbeitet. Eine spätere Korrektur im laufenden Betrieb ist möglich, aber um ein Vielfaches teurer als die richtige Weichenstellung am Anfang.

Zweitens die Zielkonflikte: Verfügbarkeit, Sicherheit, Flexibilität und Kosten lassen sich nicht gleichzeitig maximieren. Ob ein Standort eine redundante Anbindung erhält, ob eine Produktionszelle bei einem Vorfall automatisch isoliert werden darf, ob Fernwartungszugriffe von Maschinenherstellern über eine kontrollierte Zone laufen müssen, das sind Abwägungen zwischen Geschäftsrisiko und Investition. Solche Abwägungen kann die IT vorbereiten und bewerten, treffen muss sie die Geschäftsführung, denn sie verantwortet das Risiko.

Drittens die Haftung: Spätestens seit NIS2 ist die Frage, ob die Netzarchitektur dem Stand der Technik entspricht, keine interne Fachdiskussion mehr, sondern Gegenstand von Nachweispflichten. Die Geschäftsleitung muss die Maßnahmen nicht selbst entwerfen, aber sie muss verstehen, was sie billigt. Dafür benötigt sie eine Architektur, die sich erklären und belegen lässt.

Fünf Fragen, die die Geschäftsführung stellen sollte

Ein belastbares Bild der eigenen Lage entsteht nicht aus Technik-Reports, sondern aus wenigen geschäftlich formulierten Fragen an IT- und OT-Verantwortliche:

  • Was kostet uns eine Stunde Netzausfall je Standort, je Produktionslinie, je Kernprozess? Wenn diese Zahl niemand nennen kann, fehlt die Grundlage für jede Investitionsentscheidung.
  • Wie weit trägt ein einzelner Fehler? Welche Bereiche stehen still, wenn ein zentraler Switch, eine Firewall oder ein kompromittierter Client betroffen ist? Ist diese Ausbreitung bewusst so entschieden worden?
  • Wie lange dauert es, einen neuen Standort oder eine Akquisition vollständig anzubinden? Woran hängt diese Dauer konkret?
  • Nach welchem Kriterium priorisieren wir Netzinvestitionen? Nach dem Alter der Hardware oder nach dem Geschäftsrisiko, das eine Komponente abdeckt?
  • Können wir unsere Architektur gegenüber BSI, Cyberversicherer und Kunden-Audits nachvollziehbar mit aktueller Dokumentation der Zonen, Übergänge und Kommunikationsbeziehungen darstellen? Wie geschieht das zukünftig?

Die Antworten zeigen schnell, ob Architektur im Unternehmen als das behandelt wird, was sie ist: eine Investitionsentscheidung mit langfristiger Geschäftswirkung.

Fazit: Architektur ist Strategie in technischer sowie organisatorischer Form.

Netzwerkarchitektur entscheidet über Lieferfähigkeit, Kundenerlebnis, Geschwindigkeit und Haftungsrisiko. Vier Größen, die unbestritten auf die Geschäftsleitungsebene gehören. Die Konsequenz ist nicht, dass Vorstände Routingtabellen lesen müssen. Die Konsequenz ist, dass Architekturentscheidungen wie andere strategische Investitionen behandelt werden: mit einem geschäftlich begründeten Zielbild, bezifferten Risiken, bewussten Abwägungen und regelmäßiger Überprüfung. Unternehmen, die das Netz weiter als reine Betriebsausgabe führen, treffen die Business-Entscheidung trotzdem (nur unbewusst, und meist zu den schlechteren Konditionen).

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.