Imagine trying to build a car from scratch without even knowing the major parts you need to make it run—an engine, steering, transmission, and wheels—let alone how to find or build those parts.
It would be incredibly hard. And frustrating! Yet that’s the perfect analogy for where network automation practitioners find themselves.
No one is selling a car you can drive off the lot today. If you want a vehicle, you have to build it yourself. And there’s no blueprint to guide you.
I believe this is one of the key reasons we haven't seen widespread automation adoption. Everyone is struggling, each in their own garage, to figure out the parts they need for network automation and how to assemble them.
We’ve been stuck at the mechanic level
As an industry we’ve been hampered by tool-first thinking. We swap stories and case studies about our implementations, outlining what we achieved using this or that tool.
Those learnings are helpful, don’t get me wrong, but they’re stuck at too low a level. That old saying about how everything looks like a nail if all you have is a hammer is relevant here. Start with the tool in hand and you miss, or misread, a lot of the context.
The context, in this case, are the functional requirements that the tools should serve. Instead of working at the mechanic's level, focused on specific implementations, we need to step back and think like architects and designers working on a blueprint.
What are the building blocks we need to create a performant network automation system, and what function does each block serve? This is the shared understanding that will help us move forward as an industry.
How the NAF framework came together
I’m definitely not alone in seeing the need for a shared blueprint or framework. At AutoCon 1 in Amsterdam, Dinesh Dutt opened the conference with a keynote about network automation adoption barriers and common misconceptions holding the industry back.
It struck a chord. People were buzzing about it in the NAF Slack community, and soon there was talk of forming a working group that would hammer out what a shared network automation framework might look like.
NAF co-founder Chris Grundemann helped us define the final group with a workable number of participants, and a good variety of perspectives from operators, vendors, automation consultants, and network managers. I was on the list.
Together, our working group dove into regular meetings and discussions. It was a messy but collaborative process with lots of debate and compromise.
But one thing we all agreed on from the start was that we needed to focus on building blocks for an automation system, not tools.
Simple, universal building blocks
What emerged from our discussions is a refreshingly straightforward model that we’re calling the NAF Framework, or the NAF Automation Framework.
As Dinesh Dutt put it when presenting the framework at AutoCon 4: "The building blocks are simple and universal. They work independently of whether you're running Amazon or whether you are running a small little data center in the corner.”
The six functional building blocks—intent, observability, orchestrator, collector, executor, and presentation—answer four fundamental questions that anyone, working at any level or scale, must answer when building an automation system:
- What do I want? Intent is where desired outcomes are designed and stored.
- What do I have? Observability is where network state from the Collector is stored, along with the logic to process it.
- How do I get what I want? The Collector gathers current state data from the infrastructure, and the Executor implements changes guided by intended state.
- How do I control all of this? The Orchestrator coordinates and executes automation tasks, while the Presentation layer provides interfaces for interacting with the system.
The key takeaway is to always think of the six components as functions. The functions are deliberately simple so the framework is easy to understand. And they’re deliberately composable, which means you can string a bunch of them together and get the result you want. They aren’t a monolithic entity. That flexibility means the framework is relevant to any automation project, at any scale and any level of maturity.
(For more detail on the framework and each component, see the NAF website.)
Gaining an architect's view
The NAF Framework forces you to think at a higher level. Instead of asking, "Which tool should I use?" you focus on the functional requirements. One tool might handle multiple functions. Or you might need multiple tools for one function. But now you can see clearly what you're building.
I think this higher-level perspective is super important for the industry. We need more people to become automation architects but we're missing a lot of architecture skills training. My hope is that this framework will help people learn some of those skills and get up to speed much faster.
I’ll admit, the framework looks obvious when you see it. But there are still a lot of people missing this information, still a lot of people reinventing cars in their garage and struggling through the same mistakes so many others have already made.
So the purpose of the working group was really about documenting a higher-level approach, and creating that shared blueprint that didn't exist before.
Why the NAF Automation Framework matters
Having this shared understanding of how to build an automation system changes things for everyone in the industry.
Beginners don't have to start from scratch figuring out what components they need or how they should interact. They can avoid months or years of trial and error.
Anyone evolving an automation system can see how what they have maps to the framework to more easily identify gaps or overlap.
Vendors can show exactly where they fit in the framework, giving users an immediate understanding of what function is being covered. (For example, Infrahub sits in the intent block.)
The industry now has a common language for discussing automation. We can focus on the building blocks and their interactions, not the brand names.
Join the effort
As Dinesh emphasized in his Autocon 4 talk, "The fundamental purpose of this is to serve the community. If this does not help advance us having a common lingua franca when we talk about network automation, then I think we have failed in our mission."
So what comes next?
For AutoCon 5 in Munich, we're working on explaining the why behind each component. Why do you need version control? Why does flexible schema matter? Watch for presentations and workshops as the AC5 schedule is announced.
We also need community input. Does the framework make sense? Is it helpful to you? What do you think is missing? We're not building a protocol, so we can be iterative and collaborative—as we should be.
Join the NAF Slack community to add your comments and feedback as we continue to build out the framework and the pieces that attach to it.
