Automation as architecture: How Nokia rebuilt confidence in its data center network
For many organizations, automation is still something you apply to infrastructure—an add-on, a set of scripts, a layer above. But what Nokia’s global data center network transformation shows is this: when automation becomes architecture, everything changes. In Nokia’s case, treating automation as architecture fundamentally changed how risk was managed, how changes were validated and how confidence was rebuilt across the network team.
In part one of this series, I looked at how Nokia’s IT team recognized the limits of its legacy network environment—systems that had grown complex over time, constrained operational agility and introduced risk into even the most routine changes. In this post, we go deeper into how Nokia addressed that challenge by building automation into the core of its infrastructure, not just as a tool, but as a foundational principle.
Defining the right foundation
At the outset of the project, Nokia didn’t just want new hardware or faster speeds. They wanted to reframe how the network was run. That meant building a fabric architecture around operational priorities, not just technical ones:
- Simplicity in design
- Consistency across global data centers
- Predictability and confidence during change
This wasn’t a theoretical design exercise. Nokia’s IT team needed to solve for real operational pressure—supporting 24x7 manufacturing, minimizing downtime and restoring trust in the ability to make changes safely. As one team member put it, the question wasn’t just about performance: “How easily can I operate, how easily can I make changes and deploy?”
Their answer was to build a globally consistent, modular network fabric using Nokia data center switches running Nokia SR Linux—and to manage it using the Nokia Event-Driven Automation (EDA) platform.
EDA SaaS: Operational simplicity at scale
One of the most important decisions Nokia made was to consume the automation platform using a Software-as-a-Service (SaaS) model. Rather than host and manage the automation tooling themselves, they opted for EDA SaaS, a cloud-based model that offloaded complexity and ensured always-up-to-date capabilities.
This choice was strategic. The IT team made a clear decision to avoid creating a new operational burden by running the automation platform themselves. That’s a key distinction. By going SaaS, Nokia’s engineers could focus on using EDA to enforce consistency, validate changes and streamline operations without managing the controller infrastructure itself.
And it paid off. EDA became the system of record and execution for the entire network fabric. Every device was provisioned through it. Every change went through it. Every rollback, every validation, every update—EDA became the interface, the guardrail and the enabler for safe operations.
From change anxiety to confident execution
Here’s where things get tangible. In the legacy environment, teams were understandably cautious about changes. Even small ones—adding a VLAN, adjusting a route—could cause unintended ripple effects. Without a reliable way to validate impact, change windows were slow, reactive and stressful.
Nokia IT ultimately moved network changes into a CI/CD pipeline. Configuration updates were version-controlled, reviewed, validated in a digital twin and deployed through automation. With EDA and its integrated digital twin functionality, Nokia flipped the equation. Now, any proposed change could be simulated before deployment. Teams could see what the network would look like after the change—routing tables, link state, service availability—and compare it against the current state. That validation loop became the safety net that unlocked faster execution.
In fact, the IT team began deploying changes through a CI/CD pipeline. No more manual SSH sessions. No more Notepad++ configs. Just version-controlled, reviewed, automated updates—pushed with the click of a button.
One engineer described it like this: “Now we run the pipeline, push the button, done. No outage.” That’s not just a process change. It’s a cultural one.
Automation as confidence builder
Let’s be clear: automation is often sold as a time-saver, and it is. But in this case, it was also a trust restorer. Nokia’s IT team wasn’t trying to move faster just for speed’s sake. They were trying to create an environment where operators felt confident—where they didn’t have to second-guess every adjustment, or involve six engineers to approve a change, or spend a weekend babysitting a config deployment.
EDA made that possible—not because it replaced engineers, but because it gave them clarity, validation and consistency.
And because the fabric architecture was designed around automation from the start, the tools and the topology worked together. That’s the difference between applying automation after the fact and building it into the network’s DNA.
Lessons in operational design
What other IT leaders can learn from Nokia’s approach is that architecture and operations are not separate concerns. Designing a scalable, resilient network isn’t just about routing protocols and bandwidth. It’s about how people will maintain it, grow it and live with it over time.
When automation is an afterthought, it becomes brittle. When it’s baked into the system—through intent-based workflows, digital twins, CI/CD pipelines and SaaS-managed platforms—it becomes the engine of confidence.
That’s what Nokia achieved. Not because they chased the latest tech buzzword, but because they aligned tools, process and people under a unified strategy.
And it’s working.
This post is the second in a series of three, and you can read the whole series here. In my next post, I’ll walk through how Nokia operationalized this transformation—site by site, service by service—without disruption. Until then, read the full report to explore Nokia’s migration journey.
This is the second blog in a series of three. To see the other posts, visit: data center networks blogs.
