Enterprise networks are vast, intricate systems with multiple methods for storing configuration and state information. The configurations of those networks are also constantly changing as new applications, services or other updates are added. When you consider the complexity and dynamic nature of an enterprise network, it may be alarming to learn how much dataincluding most network configurationsis still updated manually, often in the middle of the night. To make that process even less efficient, the people doing the updating are required to manually log those updates on spreadsheets or into a custom-built database.

Relying on manual processes to maintain and manage the state of an enterprise network not only leaves the door open for errors but can also lead to the network spreadsheets or databases being out of sync with the actual current state of the network. Is the network correct? Or is the spreadsheet correct? Should we make the network look like the spreadsheet? Or should we update the spreadsheet to reflect the network? What is the actual source of truth?

The good news is that the reality of modern networking has changed the paradigm. As programmable networks are deployed more broadly, manual CLI interfaces are no longer necessary. Reading and writing network configuration and reading network state can be accomplished quickly and easily with machines and automation.

More enterprises are embracing network automation because they recognize the efficiencies it can deliver when managing complex networks and the benefits those efficiencies can add to the bottom line. But if youre going to automate your infrastructure, your automation solution will need to gather authoritative information about it from somewhere. This source of truth holds the knowledge needed to enable automation to make changes to the network.

Many enterprise networking teams feel they need to rely on a single source of truth to know the true state of the network. They believe that building a single system/server/database that can synchronize with the configuration and state information of all devices across the whole network is a viable solution. But such a solution doesnt currently exist. Given the multifarious nature of todays networks, relying on a single source is both impractical and potentially expensive.

Rather than asking What is the single source of truth? perhaps the better question is What will provide better data: Creating a single source of truth that tries to synchronize to the entire network? Or accessing distributed sources of truth needed to accomplish the automation in real-time?

Instead of relying on a single source of truth, enterprises should focus on accessing multiple sources of truth to conduct proper and meaningful automation.

If youre running a service provider network, for instance, your business is your network. If youve spent millions, or even a billion dollars on your network assets, its worth your time to have a system in place that accurately manages and maintains those assets. A single source of truth wont provide that.

Also, as the network scales in size and complexity, the time it takes to synchronize a source of truth to the network also grows, limiting how often you can synchronize and leading to a greater time delta between synchronization states.

Finally, the process of trying to create a single source also doesnt address the real issue, which is that enterprises are still relying on manual processes that will almost always result in the source of truth databases and the actual network status being out of sync at some point. And that can have serious negative effects on a business as well.

The case for accessing multiple sources of truth is a relatively simple one: it allows for greater flexibility and enables enterprises to more easily leverage data to benefit their business.

With the advent of programmable networksmachines talking to machinesthe most current automation solutions can access multiple distributed sources of truthdifferent APIs and databases that are responsible for being the source of truth for different parts of the network and federate and sync data from these systems in real-time, providing a truer window into the status of the network and more accurate, actionable data that delivers business value back to the enterprise.

So why are some enterprises still hesitant to commit to a full network automation project? There are various reasons for this, but clearly, theres concern that not having a single source of truth for network data or data that may not be 100% accurate will compromise the automation process. Its a classic fear, uncertainty and doubt thought process: What if the data is only 70% accurate? If we try to automate with bad data, were going to break the network 30% of the time.

Some network teams may believe they cant automate anything until they can combine their five or six sources of truth into one huge database. At the same time, leadership may be pushing those network teams to move forward with automation to get more value from the network. By choosing to wait until they finally have a pristine database, they could lose months or even years of time, to the benefit of no one.

The solution is to take an incremental approach. Look at all the various network assetsprogrammable, cloud, legacy, etc.and start the automation process in the areas where good data exists and where a source of truth doesnt need to be built. In parallel, you can be cleaning up the other data and add automation when that data is ready.

Being able to utilize multiple sources of truth is better than worrying about having a perfect source of truth and holding back on an automation initiative. In the long run, it will be beneficial to both the network team and the business.

Just as important as committing to an automation solution that can integrate with multiple sources of truth to make decisions, is deploying the right automation solution. The most effective automation solution will embrace:

API-firstThe only way to integrate multiple sources of truth into a unified one is through an API-first approach, allowing systems to talk to each other. Data federation and transformationHaving unified sources of truth is only impactful when teams can fully integrate the data together while ensuring it speaks the same language. Unified viewAn abstracted and federated view of the data, processes and logic from integrated systems enables a single pane of glass across an entire network, as well as management tools for simplifying automation across the organization.

With todays modern, programmable networksand the absolute necessity for enterprises to have access to accurate, real-time network datarelying on a single source of truth is based on a flawed assumption that we can always have a synchronized database, and therefore is not a viable strategy.

By adopting network automation, organizations can adopt a distributed source of truth solution by enabling the multiple systems of record, and their collective data, to act as the source of truth, mitigating data quality issues and manual errors.

As an enterprise implements its automation strategy, having multiple sources of truth within the network will result in more accurate, timely and actionable data for automation to succeed, which will increase efficiency and drive the business forward.

See the article here:

The Power of Automation and Distributed Sources of Truth - DevOps.com