Why network architecture is a business decision, not just an IT decision

The network is no longer background infrastructure, it is an operational precondition

Practically every revenue-generating process today runs over the network: order intake in the ERP system, machine control on the shop floor, logistics connectivity, the web shop, telephony, cloud services, and remote maintenance. If the network goes down, it isn't just "IT" that goes down, it's the entire company. The scale of this is well documented: a 2025 study commissioned by Fluke put the losses suffered by German manufacturers due to unplanned downtime at around €44 billion per year, with average costs of roughly €1.5 million per hour of downtime. Splunk's downtime study found average annual downtime costs of around €255 million per affected large German enterprise, and Siemens's "True Cost of Downtime" report estimates the losses of the world's 500 largest companies at around 11 percent of their revenue.

What matters, however, is this: whether a technical fault or an attack triggers one of these costly hours or an entire week is not a matter of chance, but of architecture. A cleanly segmented network with defined failure domains contains an incident to a single cell, line, or site. A historically grown, flat network – in which office IT, servers, production and building systems are all lumped together in a few large broadcast domains – turns every local problem into a company-wide one. This fork in the road is not decided in the crisis team, but years earlier, at the architecture design stage.

Four levers through which architecture affects the business

Revenue and delivery capability

Availability is an architectural property, not a product feature you can purchase after the fact. Redundant paths, separate failure domains, independent power supply for network nodes, clean Layer 3 boundaries instead of Layer 2 constructs stretched across site boundaries – these are the unspectacular decisions that determine whether a component failure goes unnoticed or brings production to a halt. In OT environments, there is an added dimension: unlike delayed office work, lost manufacturing hours cannot be made up later. One hour of downtime on an assembly line is permanently lost output in a just-in-time chain, often with contractual penalties and follow-on costs far exceeding the pure production value.

Customer experience

Every digital interaction with customers – via a portal, configurator, API connections, service hotline, or tracking – runs over network paths whose latency, prioritisation and resilience are determined by the architecture. Connecting sites via undersized links without quality of service, or forcing all internet traffic through a central, overloaded data centre, produces sluggish applications and dropped sessions that sales teams experience as "poor service". Conversely, local internet breakouts, clean traffic engineering and redundant provider connections are not technical niceties, but direct levers for the perceived quality of digital offerings.

Time to market

How quickly a new site becomes operational, an acquired company is integrated, or a new production line goes live depends less on project management than on the architecture these projects encounter. A standardised target design, consistent addressing and segmentation concepts, defined handover points between IT and OT, automated provisioning, and documented firewall rule sets can reduce site connection times from months to weeks. Without a target design, every project becomes a bespoke undertaking: address conflicts during acquisitions, manually maintained special rules, and dependency on individual knowledge holders. This technical debt appears in no balance sheet, yet it slows down every strategic initiative, from cloud migration to new data-driven service offerings.

Security and liability

With the NIS2 Implementation Act, which came into force on 6 December 2025 without a transition period, cybersecurity has formally become a matter for top management in Germany. Around 30,000 companies fall within its scope – significantly more than the previous CRITIS operators – including many mid-sized businesses in manufacturing, mechanical engineering, chemicals and logistics with 50 or more employees or €10 million or more in revenue. The registration deadline with the BSI already expired in March 2026; violations can incur fines of up to €10 million or 2 percent of global turnover. Above all, the law personally obliges executive management to approve risk management measures and to oversee their implementation. This responsibility cannot be delegated.

From an architectural perspective, the point is simple: almost all required measures – risk control, attack surface reduction, detection, and containment of incidents – presuppose a structured network. Zones and transitions in line with IEC 62443, controlled IT/OT handover points, traceable communication relationships and Zero Trust principles are the technical foundation on which risk management can become credible in the first place. Anyone running an ISMS on top of a flat, undocumented network is, in effect, documenting that their organisational measures lacked a technical foundation should the worst happen. This implies a weak position vis-à-vis regulators, cyber insurers and customer audits.

Why these decisions belong on the C-level agenda

Three characteristics distinguish architectural decisions from ordinary IT procurement. First, their reach: network architectures live for 7 to 10 years – in OT, with plant lifespans of 15 to 25 years, often considerably longer. Whoever defines a segmentation concept today, or indeed forgoes one, determines the risk and cost profile the company will operate with well into the next decade. A later correction during ongoing operations is possible, but many times more expensive than getting the fork in the road right at the outset.

Second, the trade-offs: availability, security, flexibility and cost cannot all be maximised at once. Whether a site receives redundant connectivity, whether a production cell may be automatically isolated in the event of an incident, whether remote maintenance access by machine manufacturers must run through a controlled zone – these are trade-offs between business risk and investment. IT can prepare and evaluate such trade-offs, but executive management must make the decision, because it bears responsibility for the risk.

Third, liability: at the latest since NIS2, the question of whether the network architecture reflects the state of the art is no longer an internal technical discussion, but a matter subject to evidentiary obligations. Executive management does not need to design the measures itself, but it must understand what it is approving. This requires an architecture that can be explained and substantiated.

Five questions executive management should ask

A robust picture of one's own situation does not emerge from technical reports, but from a few questions framed in business terms, put to those responsible for IT and OT:

• What does one hour of network downtime cost us, per site, per production line, per core process? If nobody can name this figure, there is no basis for any investment decision.
• How far does a single fault reach? Which areas grind to a halt if a central switch, a firewall, or a compromised client is affected? Was this scope of impact a deliberate decision?
• How long does it take to fully connect a new site or acquisition? What specifically does this timeframe depend on?
• By what criterion do we prioritise network investments? By the age of the hardware, or by the business risk a given component covers?
• Can we present our architecture to the BSI, cyber insurers and customer audits in a comprehensible way, with up-to-date documentation of zones, transitions and communication relationships? How will this be handled going forward?

The answers quickly reveal whether architecture is being treated in the company for what it actually is: an investment decision with long-term business impact.

Conclusion: Architecture is strategy, in both technical and organisational form

Network architecture determines delivery capability, customer experience, speed and liability risk – four factors that unquestionably belong on the executive management agenda. The consequence is not that board members need to read routing tables. The consequence is that architectural decisions must be treated like other strategic investments: with a business-justified target design, quantified risks, deliberate trade-offs and regular review. Companies that continue to treat the network as a mere operating expense are still making the business decision – just unconsciously, and usually on worse terms.