I’ve been thinking a lot about how we connect disparate networking systems into one cohesive unit. Whether we’re building the panacea of an observability platform, or trying to stand up an automation capability with your company’s <buzz word> platform, the key takeaway is the same.

Abstraction matters. Abstract away from hardware right up to a clean GUI, or describe the network as code. The higher up the business stack we go, the more abstraction we need. This is not just about explaining complex problems to different stakeholders, it is about turning complex infrastructure into repeatable patterns.

A few recent clues

I was speaking with a firewall vendor who recently announced you can configure firewall policy without their management system. A few people asked, “Why?”

If your desired state or intent is controlled through something like Terraform, and firewall policy is fundamentally business logic, why route everything through a vendor UI at all? Build a provider or module that applies policy directly, and treat the vendor manager as optional.

Then Cisco come in with Network-as-Code. I’m a fan. Cisco take ownership of the data model and give you providers that translate YAML into configuration. At that point, you do not even need to learn HCL. More abstraction.

At Cisco Live 2024, they demo AI Canvas. It takes the individual “pane of glass” tools from each management domain and turns them into an interactive, dynamic pane, driven through a Cisco-trained LLM. The long-term intent is orchestration of fault-finding and recovery in one place, with suggested fixes. We still do not trust the robot overlords to auto-fix in production.

Then came the real lightbulb moment: IOS-XE direct-to-device Network-as-Code.

Let me repeat that. Direct-to-device Network-as-Code for IOS-XE Catalyst switching. No controller, no Catalyst Centre. Just an inventory file and some YAML.

Do you see where this is going?

A short history of abstraction

Hit play on AC/DC: Let There Be Rock.

Back in the day, back in 1985, nobody cared about a Terraform plan, and all that jive.

1. Box-by-box configuration
   Log into a box, configure it, keep the config in a notepad, cross your fingers.
2. Network management systems (NMS)
   Centralised inventory, basic templates, image management. Capabilities grow over time.
3. Software-defined networking (SDN)
   Decouple the control plane from the data plane. API-first. Open-ish standards. A programmable network.
4. Scripted automation
   APIs are good. Let’s use Python.
5. Infrastructure as Code (IaC)
   APIs are complex. Vendors package it up behind tools like Ansible and Terraform.
6. The future
   AI-assisted operations, control fabrics, digital twins, and assurance that actually proves outcomes.

So, what’s the point?

IOS-XE effectively skipped steps 2 to 4 for one part of the problem. You can do IaC without SDN, and without a vendor-specific management system. That covers one element of the management plane. What about the rest?

What we mean by control plane vs management plane

This matters, because “controller”, “control plane”, and “management plane” get conflated constantly.

• Control plane: decides how packets move, right now.
• Management plane: decides what the network should look like, pushes it there, and checks it stays that way.
• Controller: a vendor implementation that provides some management plane functions, and sometimes programs parts of the control plane.

Core functions of the control plane include

• Learning what exists, how it’s connected, and which paths are usable
• Routing protocols, control channels, overlay membership, endpoint discovery
• Convergence and resilience
• Policy-based forwarding and segmentation
• Overlay and identity mapping

Core functions of the management plane include

• Source of truth and modelling
• Intent, policy and service validation
• Configuration and lifecycle management
• Telemetry, monitoring and state collection
• Assurance, compliance, drift detection
• Closed-loop automation and remediation
• Identity, access and governance operations (RBAC and audit trails)
• Integration and exposure

If we could have one single management plane and one single control plane, we would be living the “single pane of glass” dream we’ve been sold for years.

Instead, we tend to have a pane per technology tower.

Why do we end up with so many controllers?

Here’s the uncomfortable bit.

We build teams around technology domains, and we buy systems that manage those domains.

• Campus teams have campus tooling and a campus controller.
• Data centre teams have DC tooling and a DC controller.
• Firewalls span both, but the firewall tooling is separate again.
• Wireless is its own world. Another controller, another portal, another inventory.

Part of that separation is genuinely technical. Feature depth, lifecycle workflows, domain-specific telemetry, safety rails, RF compute. Those are real reasons.

But a lot of the fragmentation maps suspiciously well to the org chart.

In plenty of environments, the structure of our “control and management planes” reflects organisational boundaries as much as it reflects technical necessity. Controllers can end up acting as guard rails for team ownership, not just for network outcomes.

So what’s the future of controllers?

If you were designing a unified, vendor-agnostic management and control approach, you cannot let organisational silos dictate the architecture. That is months of politics, but it is the only way to get a coherent outcome.

The question then becomes: can we build the control and management plane functions as platform capabilities, without relying on a domain controller as the centre of gravity?

I think broadly yes, using four building blocks.

A controller-less platform, in four blocks

1) Source of truth and intent

• Services, policies, tenants, zones, inventories, environments
• Expressed as repeatable code in Git, with strong schemas and validation
• Versioned change history for audit and institutional memory
• Open standards where possible (overlays do not have to be proprietary)

2) Execution engines

• Terraform, Ansible, and CI/CD tooling (Jenkins, Harness, etc.)
• Clear CI and CD stages, with policy and guard rails defined as code
• The ability to stand up virtualised lab environments on demand and test changes
• Direct-to-device via NETCONF, RESTCONF, vendor APIs, and community extensions
• Scale inventory and orchestration rather than scaling a controller

3) Digital twins and assurance

• Digital twins as a source of reference: discover and model the real network
• Assurance policies tested continuously
• Topology, effective forwarding, compliance and drift in one place
• Synthetic testing that actively proves paths, not just that devices are “up”

4) Audit, access and compliance

• Strong RBAC through Git workflows, branch controls, and identity integration
• ITIL integration through open event and telemetry protocols into general platforms
• Lifecycle management through automated runbooks
• Vulnerability management built into the pipeline
• Integration with organisation-wide SIEM tooling

Stretching a point to make a point, you can do all of the above without a controller.

I heard an industry peer recently describe high-speed, low-latency data centre networks for trading platforms. They run open standards like BGP and VXLAN. If they need to replace a Cisco leaf with a Juniper leaf, they can, and the fabric still functions. No controller is going to give you vendor neutrality like that. The constraint is scale and operational discipline, not the existence of a controller.

The remaining weak point

The strongest argument for domain controllers is still deep, domain-specific insight and workflows.

Controllers often provide:

• Semantically rich telemetry and correlation specific to that technology
• Safety rails and change orchestration tuned to the domain
• Lifecycle compatibility logic (images, feature support, hardware matrices)
• Specialised compute, especially in wireless (RF planning and optimisation)

But if the long-term direction is that telemetry, state, and topology are streamed into broader data platforms, and then surfaced through interactive experiences (AI Canvas being one example of that trend), what is the controller doing?

In many cases, it becomes an aggregation point and an API gateway with a UI bolted on.

Conclusion

Will controllers vanish?

In some cases, yes.

• Campus switching (IOS-XE direct-to-device):
  I would be questioning why you would not use Network-as-Code plus open standards like BGP EVPN VXLAN, where it fits. Some will argue the controller was never truly required here in the first place.
• Wireless:
  Controllers are not going away soon. You have specialised requirements and domain compute, and the controller adds real technical value. Whether it is an appliance, cloud, or hybrid is secondary.
• Data centres with firewalls, load balancers, compute, and network:
  This is where I hope we simplify. As security, application delivery, compute, and networking converge, abstraction becomes mandatory. You can achieve that abstraction without inserting a middle-man controller for every layer.

Will controllers change?

They have to.

Infrastructure as Code is not a fad, platform engineering is maturing and infrastructure teams now starting to understand CI/CD and want the same operational disciplines. Open source adoption is accelerating, partly through necessity and partly through what hyperscalers normalised; Vendors have recognised that mixed environments are the default and are opening APIs, documentation, and SDKs for interoperability.

At the same time, the AI wave is changing how people interact with operational data. Every data platform is pushing machine learning into analytics and experience.

My view is that a lot of the core functions of modern controllers are already being done elsewhere, but vendors still build to organisational and skills silos because that is how budgets, ownership, and renewal cycles work.

As we move towards delivering infrastructure services as products, and towards cross-platform patterns for internal customers, the cost and complexity of domain-specific tooling will come to a head. The controller will either thin out into a set of services, or it will be bypassed by platforms that do intent, execution, and assurance directly.