Network Architecture

Last updated: August 2026

Obstacles in 2026: Where Global Solution Architecture Projects Get Stuck

Anyone planning a solution architecture within an international group in 2026 no longer loses most of their time on technology selection. Delays now occur where IT meets OT, where regulation forces approvals (particularly in international operations), and where nobody quite knows what's actually connected to the network anymore. This article answers a question from the field: why do global architecture projects today take so much longer than planned, and what can concretely be done about it at network and OT level?

By Jens Thies · IT by PASSION

The bottleneck has shifted: from technology to approval

Ten years ago, architecture projects failed on technology: the wrong platform, underestimated load, incompatible interfaces. In 2026, the picture looks different. Platforms have matured, reference architectures for cloud, edge and Industry 4.0 exist, and OPC UA has established itself as a viable interoperability standard in manufacturing. Today, delays occur in the phases before and in between: during asset assessment, governance approvals, security and data protection reviews, and coordination between the IT organisation and production operations.

My projects reveal a recurring pattern: the actual solution design - target state, data flows, components - is completed within weeks. The months beforehand are spent on discovery, the months afterwards on approval cycles. Anyone wanting to set up realistic project plans needs to budget for these two blocks, not for the design.

Obstacle 1: IT/OT convergence starts with an inventory nobody wants to do

The single biggest delay factor in industrial environments is connecting production plant to cloud, AI and ERP platforms. The problem is rarely the target state, but rather the starting point. Typical findings from asset discovery:

  • Controllers and equipment with lifecycles of 15 to 30 years, whose network connectivity was never documented. Often with flat networks, where engineering stations, HMIs and PLCs sit in the same broadcast segment.
  • Proprietary protocols (Profinet, EtherNet/IP, Modbus TCP, S7 communication) that cannot easily be routed through firewalls or across routed segments, as they rely on Layer 2 adjacency or fixed latencies.
  • Unclear responsibilities: the plant network "belongs" to the machine supplier, the maintenance contractor, or nobody - certainly not IT.

For solution architecture, this means: before any data flow towards the cloud can be designed, a solid network and asset inventory is needed. Passive discovery via mirror ports or TAPs is the right approach here - active scans can crash older controllers. This phase realistically takes several weeks in a single plant, and months across a global network of plants. Projects that skip it end up doing it later under time pressure - but then with production risk attached.

Added to this is the downtime factor: integration testing on real plant requires maintenance windows, and many plants only have these once or twice a year. A missed window doesn't push the rollout back by days, but by months. Anyone not treating this as a hard milestone in architecture planning is planning against reality.

Obstacle 2: by 2026, regulation is no longer an announcement but binding law

The second major brake is regulatory requirements that now take immediate effect and reach directly into architecture decisions.

NIS2 applies - with no transition period

Germany's NIS2 Implementation Act (NIS2UmsuCG) has been in force since 6 December 2025, and the registration deadline with the BSI expired on 6 March 2026. Around 29,500 companies are affected - including many manufacturing operations, machine builders and suppliers who previously did not consider themselves critical infrastructure. For architecture projects, this means: risk management, reporting processes and technical measures such as segmentation, access control and backup concepts are no longer optional quality features but checkpoints on which approvals depend. Since 17 March 2026, the KRITIS Umbrella Act (KRITIS-Dachgesetz) has also added requirements for the physical resilience of critical infrastructure.

EU AI Act: partly postponed, but not off the table

For the EU AI Act, the "Digital Omnibus" (Regulation (EU) 2026/1744, in force since late July 2026) has pushed back the full high-risk obligations under Annex III to 2 December 2027, and for AI in regulated products to August 2028. Transparency obligations, on the other hand, have applied since 2 August 2026. In practice, this postponement changes little in terms of effort: anyone planning AI functions into an architecture still needs to build up system inventory, risk classification and data governance now - otherwise the postponement will turn into a backlog in 2027.

Data Act and data sovereignty

The EU Data Act has been applicable since 12 September 2025 and makes cloud switchability a contractual obligation, among other things; switching fees will be abolished entirely from January 2027. Together with regional data residency requirements (for example in China or the US context), this forces global groups to think regionally about data storage and AI workloads. Architecturally, this means: no more central "one cloud" landing zone, but regionalised deployments - with everything that implies for WAN design, breakout locations, latency and operating models.

Obstacle 3: Zero Trust meets a brownfield that was never built for it

By 2026, Zero Trust is a fixture in virtually every corporate security strategy. In OT, however, the concept collides with reality: equipment without user context, shared engineering accounts, systems incapable of MFA, patch levels that can only be changed during the annual maintenance window. Anyone trying to transfer IT Zero Trust patterns one-to-one into production creates delays - or downtime.

The viable answer lies at network level. Where identity-based controls are not possible at the endpoint, compensating controls in the network take over: zones and conduits per IEC 62443, micro-segmentation wherever the network structure allows it, controlled transitions between the layers of the Purdue model, hardened jump hosts for remote access instead of direct VPN tunnels into the plant layer. This is less elegant than an end-to-end identity model, but it is achievable, auditable, and compatible with both NIS2 and IEC 62443. Projects that build in this translation work early (Zero Trust principles into OT-suitable network controls) lose significantly less time later in security reviews.

Here too, in some cases, the step-by-step implementation of NetFoundry OpenZiti can be the gold standard - but this must equally be examined closely.

Obstacle 4: platform diversity and the underestimated network question

Large enterprises today run two to three hyperscalers, SaaS platforms, on-premises Kubernetes and edge clusters at their plants - all in parallel. Each of these platforms brings its own IAM, its own network model and its own observability. For the solution architect, this creates an integration problem that is frequently overlooked at the lowest level: the network.

AI and IoT applications rarely fail in implementation because of the model, but because of latency, bandwidth and segmentation. An inference workload processing camera data from the line belongs at the edge - not because it sounds modern, but because the round trip via the central data centre would blow the latency budget, and OT network segments must not "leak" unfiltered into the cloud. Such decisions (edge vs. cloud, local breakout vs. central WAN, a dedicated OT DMZ per plant) must be made during the architecture phase. If they are postponed, they resurface during implementation as change requests - each with its own approval cycle.

Obstacle 5: the current political and economic situation worldwide

Lead times for servers, graphics cards, RAM, ASICs and much more keep on lengthening. Prices are rising just as steadily. The cost of a server has risen four- to fivefold between September 2025 and June 2026, and prices continue to climb. The same applies to firewalls and other security appliances. In some cases, servers can only be bought without RAM. With every additional month of lead-time extension, project execution is delayed accordingly. Nobody can currently really estimate how far this will go.

Are you budgeting from the outset for several times the price of the hardware you need? Is that too much, or too little? And is the provider's Wi-Fi site survey - along with the specialists and equipment required for it - being delayed as a result too?

What actually helps against the delays in practice

A number of patterns emerge from recent years' projects that make the difference:

  1. Discovery before design. A structured architecture discovery phase (assets, networks, data flows, responsibilities) belongs at the start of the project - with its own budget and its own timeframe. It is not a delay; it prevents one.
  2. Joint IT/OT teams instead of handover points. As long as IT plans and OT "merely" implements, queries and escalations arise at every interface. Mixed architecture teams with plant representatives measurably shorten decision-making paths.
  3. Security and compliance from day one. NIS2 requirements, IEC 62443 zone concepts and data residency requirements belong in the first architecture sketch, not in the final review. Security bolted on afterwards is the most expensive route.
  4. Treat maintenance windows as hard milestones. Plant downtime windows belong in the project plan just like contractual deadlines. Anyone who knows them plans integration testing backwards from that point.
  5. Architecture as a living artefact. With business priorities shifting monthly, no big design up front can survive. A well-maintained architecture repository with versioned decisions (Architecture Decision Records) keeps reviews short, because committees can trace what changed and why.
  6. Order hardware immediately or promptly. As soon as it is genuinely clear which hardware is needed, it should be ordered. If delivery is delayed, it is worth negotiating with the supplier so that licences only start running down from deployment, not from purchase.

Conclusion

The challenges of global solution architecture projects in 2026 are, for the most part, organisational and regulatory in nature: unknown brownfield estates, gaps in IT/OT responsibilities, regulations that have become mandatory, and approval processes that are not prepared for this combination of factors. Technology is rarely the problem. Those who treat discovery, segmentation and compliance as architectural tasks from the outset, rather than as downstream obligations, recover precisely the months that these projects typically lose today. As for the current global political and economic situation: all stakeholders within a company should consult with one another and agree on a joint approach.

Note

This article reflects the author's personal professional assessment at the time of publication. It does not replace individual consultation. Details regarding standards, deadlines, versions and manufacturer functions should be verified before making any decisions. All content is provided without guarantee.