Yes, NLD can operate seamlessly in a SDN environment.
Here is the basic rundown on SDN (Software Defined Networking). First, here is a traditional switch:
Typical Switches (and Routers) contain configuration that instructs how packets arriving at the switch (Port 1 in the example above) should be forwarded. This configuration resides the Control Plane. In the example above, the configuration in the switch instructed that the packets should be forwarded out of Port 2. Possibly because the packets were destined for a host connected to that port, or because of some other forwarding instructions (VLAN, MPLS, etc.) -- either way, that forwarding decision was made because of configuration stored in the switch.
Moving over to SDN, SDN splits the traditional switch model. Looking first at OpenFlow. OpenFlow [almost] completely removes the Control Plane from the switch...
In OpenFlow, the Control Plane is moved externally to a server (called the Controller). When packets arrive at the switch, the switch consults the Controller for the forwarding decision, and then carries it out. Controllers can typically see all of the switches (and/or routers) in the local network and based on the configuration of the Controller direct packets around the network. This allows clever things like "flowing" packets around switches that are down, or taking into account switching bandwidth to direct traffic through less loaded switches.
A different visualization of conventional vs SDN is this...
However, OpenFlow-based SDN is losing favor for both market and technical reasons. On the technical side, switches in big data centers see millions of "flows" (traffic for individual connections) per-second; which means that the "dumb" switches, with no way to make forwarding decisions by themselves, must ask the Controller. This puts an incredible strain on the Message Bus between the switch and Controller, as well as the Controller's capacity to compute decisions. On the market side, vendors like Cisco don't like the commoditization of switches.
So, a third alternative has emerged...
This model is being embraced by Cisco, Juniper, etc. In Cisco's case, it goes by several names (of course), Application Centric Infrastructure (ACI), Intelligent WAN (IWAN) for SD-WAN, but all under the umbrella of Evolved Programmable Network (EPN).
This is similar to the OpenFlow model in that forwarding decisions are made by an external Controller. But the distinction is, the Controller doesn't need to be involved in packet-level forwarding decisions (as noted, it doesn't scale). It computes forwarding rules periodically and then, using APIs provided by the switch, programs (configures) the switch to carry them out.
Whew.
So, "everyone" tends to think, "Well, if the controller configures the switch, there's no need for an NCM solution to backup switch configurations." But that misses the fact that the Controller only configures the switch (or router) for the purposes of forwarding decisions. There is still a ton of static configuration in the switches: Authentication, NetFlow, SNMP, and Logging to name a few (of possibly hundreds).
In an SDN environment, NCM is equally critical compared to a conventional network. Without some of the static configuration, such as NetFlow, the Controller would be "flying blind" without any information by which to compute and program forwarding decisions.