When I first began this post, my thinking revolved around the translation problems of a declarative approach to network operation, but having only procedural interfaces to work with. Further thought dismissed that assumption and led to thinking about how declarative models evolve to meet organizational needs.
I Declare!
Many articles have been written about how declarative models define what we want, while procedural models focus on how we want to accomplish this. Overall network policy should be declarative, while low-level device management should be procedural, especially when dealing with older platforms, right? Well, it's almost right.
Network device configuration and management have, for the most part, been declarative for some time. We don't tell switches how spanning tree works, nor how to put VLAN tags on Ethernet frames. We plug in the necessary parameters to tune these functions to our specific needs, but the switch already knows how to do these things. Even old-fashioned device-level configurations are declarative operations. Admittedly, they're not high-level functions and need some tweaking and babysitting, but they're still declarative.
Let's explore the timeline of where we've been, where we are, and where we're potentially going.
Procedural Development
Back in the primordial days of computing (okay, perhaps not that far back), when I was first learning to code, everything was procedural. We joked about the level of detail required to accomplish the simplest of things. What we really needed was the DWIT (Do What I'm Thinking) instruction. Alas, this particular directive still hasn't made it into any current coding environments. Developers have accepted this for the most part, and the people who are making the decisions are usually happy to let them handle it rather than trying to figure out how it all works at a low level. The development team became the buffer between the desired state and the means by which it is achieved.
Device-Level Configuration
Network device management is a step up in the abstraction ladder from procedural coding, but is still seen as a detailed and arcane process to those who aren't experienced with it. Like the developers, the networking team became the buffer, but this time it was between a high-level desired state and the detailed configuration of same. The details became a little less daunting to look at and more input came from the people making the business decisions.
More and more, the networking team had to be aware of the greater business cases for what we were doing so that we could better align with the overall goals of the business. We implemented business policy in the language of the network, even if we weren't fully aware of it at the time.
Large-Scale Models
Now, we're slowly beginning to move to full-scale network automation and orchestration. We can potentially address the network as a single process, allowing our organization's policies to map directly to the ongoing operation of the network itself. It's still pretty messy underneath the abstraction layers, but there's a lot of potential for the various automation/orchestration tools that are being developed to clean that up.
The Whisper in the Wires
Our network architecture should line up with our business processes. We've always been aware of this, but delivering on it has been difficult, mostly because we had the right idea but on too small a scale. New tools and models are being developed and refined, making it possible to this point, but it's up to us to embrace these and push them to their limits. The value of the network to our organizations depends on it. By extension, our value to our organizations depends on it.
I don't think we're ever going to reach a point where that old DWIT instruction is a reality, but is it too much to hope that we're getting closer?
Looking for a network monitoring solution? Download a free trial of SolarWinds® Network Performance Monitor. 
