From CLI to NetOps: How Nokia IT Modernized Its Data Centers
Ahmed Abutaleb, Nokia IT’s lead data center architect, describes a multi-year transformation of Nokia’s on-prem data centers to a modern, NetOps-driven model using Nokia SR Linux and Nokia Event-Driven Automation (EDA). The change was motivated by real-world pain points: heavy, manual operations; poor traceability between design intent and what was actually deployed; siloed tools with little correlation; and configuration drift from CLI-driven changes.
To fix this, the team re-architected end-to-end—design, implementation, and operations—adopting “network as code,” templating, automation, and digital twin validation so engineers work at a higher level of abstraction while tooling enforces consistency. This approach improved confidence in changes, enabled quick rollback, and standardized configurations across devices. Beyond technology, Ahmed frames it as a people journey too—giving engineers practical exposure to automation and AI where it truly adds value. Reported outcomes include far fewer tickets (around an 80% reduction), faster and safer deployments, and higher team satisfaction.
This video is number 2 in a series of 6. To see the other posts, visit: https://techstrong.tv/videos/modernizing-the-data-center-nokia-its-netops-playbook
Transcript
Hello, I'm Scott Roam with Al, and I'm here today with Ahmed Abbu, lab of Nokia Enterprise IT to talk about some of the very interesting network migration issues that they've been through over the last, uh, year or so. I'm not gonna steal any of Ahmed's Thunder, and we'll let him speak to at all. Ahmed, please introduce yourself to the audience.
Hi. Um, my name is Ahmed Abbu. I'm the lead architect for the on-prem, uh, data centers inside Nokia it.
And, um, I had the privilege of course, of, uh, doing this exciting transformation where we moved a lot of data centers from legacy to modern, modern techniques, modern data centers, migrating from different types of vendors to, to Nokia equipment migrating from Nokia to Nokia. So, um, those two or two and a half years have been very exciting for me. I've been working in data centers for a long time, but this is like something I've never seen before.
Awesome. I'm excited to share this with you. Yeah, no, happy to dive into this.
And let's just set the context for, for people who aren't aware, you know, Nokia is just this tiny little company with just a few hundred users on the network, right? Yeah, sure, sure. We've got like 88,000 people.
Yes. Yeah. And a wide diversity of different departments and functions.
Do you support, you have manufacturing operations that you have to support, of course. Finance, accounting, yes. Hr, all sorts of, you know, software developers, people in sales, people in marketing.
Probably one of the most complex enterprise network environments that I've run into in my time in networking. How about you? I, I think it's, it's different types.
There is a variety of applications, applications that are very sensitive to disruptions. Sure. Applications that are, you know, factories, uh, you know, that that could, you know, disruption could, could throw off, uh, the software of the factory.
It has to be restarted, things like that. So it's very critical. Very interesting.
And the different variety. Different variety. Some are very sensitive to, to delays.
Some are very sensitive to outages. It's very interesting. So you've given a little hint at kind of the first, um, category of things that we want to talk about.
You know, some of the pain points and the issues that you, you had to think about and had to say, what does my next gen network architecture need to fix? So what were some of those original pain points? If you think back, you know, two, two and a half years now, um, to when you actually started down this path, what were some of the motivators that, um, got you thinking about we need to go to new network infrastructure and new tooling?
Well, when I started really with Nokia, it, I, I saw it, it d all sorts of problems. You know, I wasn't, I wasn't in the, in the IT world, I was in the product world, right? And everything, there was like more rosy, you know, you're dealing with labs, concepts, architectures, blue playbooks, sure blueprints.
But when you move to it, it really hits, you know, the real world part. And there I was exposed to all sorts of problems. You know, we have our operational model, you know, where we have to do a lot of intensive work, uh, very resource intensive.
We really don't know what is deployed, uh, if it's, if what we intended to deploy is actually on the network or not. We don't have a feedback loop from the actual, from the actual deployment to the intent. Um, we had operational problems where, where the operations team were dealing with different types of toolings that don't cooperate with each other, that don't tell you really what, what, you know, what is wrong with your network at any time.
You have to do a lot of brain power and co you know, manual correlation. Hmm. Um, also our designs, our designs, it was a lot, oh, well, let's go to the lab.
Let's try and simulate as much as possible production. Let's bring in, you know, expensive equipment, expensive, uh, uh, low balances files, other into the lab just to, to test something small because we are worried that when if we go in production, it'll have a, a very negative effect. So lots of variety like that.
And also, and also human aspect, uh, of the thing. It's like, like I, I think of it as a journey. This is not only a technical part, you know, sure.
People are, you know, see excited about automation, AI and stuff like that. And they, they wanna be part of it. They, they wanna get exposed to it, but not, not, not just for the sake of AI and automation, but where it makes sense for us.
So all that made made us think of completely rearchitecting the way we do everything. Sure. From design to, to implementation to operations, everything was completely different.
Did you see any, like, not to be overly reductionistic, but any like, specific pain points, was there overload due to alarms or tickets generated? Um, were there communication issues on some of these complex troubleshooting issues? Does anything specific come to mind there?
Of course. Uh, I'm, I'm not an operations team. I'm a, I'm a design team, so Sure.
Uh, I wanna comment on the design part Okay. Because, uh, that affected me the most. Sure.
Is, is when, when, for example, when I got exposed and we had a network audit and we found all sorts of problems. You know, the thing is we really don't know if, if what we're dealing with is, is a design intent or it is intended to be like this or, or a drifted through time to be like this. Sure.
So, uh, the common thing, the common thing is I always was told, go back, let's see the designer that did it two years ago, let's talk to him. Let's talk to him. Is it really this or not?
So it wasn't like very consistent and, and, and drifting. And we don't know if, if reality is good or bad. So, uh, all sorts of problems there in the design and also in the implementation.
Lots of people doing CLI, where, where one node has a completely different configuration than another. Not completely, but drifted away from another and they should be identical. And we never understood why.
So I, I, I really need, uh, I really thought, thought about this when, when starting the architecture that we consistency has to be there. Yeah. Automate, you know, something at a higher level should be, the engineer shouldn't be going to that low of a level to deal with things.
See, they should, they should be dealing with a high level and let some tooling, some automation, some templating, do the, the real hard work. You know, the con you know, consistency check work. Sure, sure.


