When Complexity Becomes the Enemy: How Operational Workflow Sprawl Threatens Performance and Delivery

In the evolving world of application delivery, organizations are investing heavily in modern infrastructure, applications, and intelligent automation. Yet despite this investment, many still struggle with issues that should have been solved by now: systems that fail under pressure, deployment policies that don’t hold across environments, and workflows that grind to a halt when speed is most needed.

Two of the top ten delivery challenges organizations face today are particularly telling: lack of fault tolerance and resilience, and incompatible delivery policies. On the surface, these may sound like infrastructure or tooling problems but when you dig deeper, it becomes clear they are symptoms of a deeper structural flaw: operational workflow complexity.

This complexity isn’t just an annoyance. It actively degrades runtime performance, undermines policy consistency, and prevents organizations from realizing the full potential of their digital transformation investments.

In our latest research, 54.8% of respondents reported that their biggest challenge in designing operational workflows for application delivery and security was "too many tasks in the process." That’s more than half of IT decision-makers and implementers directly acknowledging that their systems are too complex to operate efficiently.

And that’s not the only signal. Nearly as many, 53.6%, said "too many different APIs" are involved in their workflows. Another 45.3% cited "too many different languages needed" as a top challenge. This is fragmentation at the operational layer: different tools, different syntaxes, different owners. All of it adds overhead, and all of it creates risk.

These numbers should concern anyone who cares about uptime, user experience, or operational velocity.

Let’s start with ADC02 Lack of Fault Tolerance and Resilience. In a typical modern application stack, you might have half a dozen different layers responsible for routing, load balancing, service discovery, authentication, telemetry, and policy enforcement. Each of these layers could be owned by a different team. Each might have its own API, its own change control process, and its own language.

What happens when something goes wrong?

A failover doesn’t trigger because the upstream dependency didn’t recognize the node failure. A new deployment misroutes traffic because the service mesh was out of sync with the load balancer. A latency spike takes minutes to isolate because the observability tools weren’t configured consistently across tiers.

These are not rare edge cases. They are day-to-day operational failures caused by workflow sprawl. And they directly tie back to the data in which we find 29% of respondents still rely on custom scripts to support automation. That’s a huge red flag. Scripting around complexity is not automation, it’s fragile glue. It breaks when the environment changes, and it delays recovery when performance degrades.

When operational workflows are bloated with handoffs, tribal knowledge, and manual remediation, there is no true fault tolerance. Just hope.

When most people hear “policy drift,” they think security. But drift in application delivery policies—things like traffic routing rules, load balancing behavior, or rate-limiting configurations—can be just as damaging. That’s one of the causes of ADC07 Incompatible Delivery Policies.

In a well-orchestrated pipeline, policies should follow the application from dev to staging to production. But in practice, the handoffs between environments are often manual, inconsistent, and tool dependent. A load balancing rule defined in staging may not match what’s configured in the public cloud. A routing policy tested in development might be omitted from production due to environment-specific constraints or oversight. Canary release thresholds, caching behaviors, failover logic—all of these are delivery-layer policies that frequently drift during deployment.

The root cause is the same one echoed in the F5 2025 State of Application Strategy Report: complexity. With 45.3% of respondents citing “too many different languages needed” and 53.6% citing “too many different APIs,” it’s clear that delivery workflows are fragmented across tooling ecosystems. Each environment might use different configuration models or infrastructure-as-code platforms, requiring translation every step of the way.

Translation introduces risk. It also introduces delay. When delivery policies must be manually rewritten or adapted between systems, rollout consistency suffers. And in distributed systems, inconsistency is often worse than failure—because it creates unpredictable behavior.

Imagine a multi-region deployment where a traffic-steering policy only applies in one zone. Or a global application with inconsistent cache rules across edge nodes. The result is a degraded user experience that’s hard to trace and harder to fix.

To move fast without breaking things, organizations need delivery policies that are declarative, portable, and enforced consistently across every tier of the stack. That’s impossible when workflows rely on a patchwork of manual processes and team-specific logic.

Until delivery policies are treated as first-class citizens—that means on equal footing with app code and infrastructure config—organizations will continue to struggle with drift, downtime, and delivery delays. Simplifying those workflows is the first and most necessary step.

Reducing workflow complexity isn’t about cleaning up the architecture diagram or making ops teams happier (though it would do both). It’s about delivering on the core promises of modern application infrastructure: speed, resilience, and consistency.

Organizations that want to improve runtime performance and enforce predictable delivery behavior must take a hard look at how many tools, teams, and handoffs are involved in their pipelines. And more importantly, they must ask: how many of these steps are adding value, and how many are just there to work around limitations in the system?

The answer isn’t always a new tool. Sometimes it’s fewer tools. Sometimes it’s a single, unified platform that enforces delivery logic with the same syntax and behavior across every environment. Sometimes it’s automating not just deployment, but governance, so delivery policies apply as code, not as a checklist.

The path to resilient and reliable delivery runs through simplification. Until we treat complexity as a critical risk, it will continue to erode everything we’ve built on top of it.