Technical debt is the collection of expedient short-term solutions that don’t allow for smooth long-term operations. Too much technical debt can create fragile networks that make automation more difficult and subject to unexpected failure.
What is Technical Debt and Its Impact?
Technical debt in software systems is typically the result of not understanding application requirements. For example, selecting the wrong type of database that results in poor performance. Or putting related data in separate reports, requiring the report’s readers to manually perform correlation.
In networking, technical debt results when network building blocks are not followed. Small but critical configuration changes result when interface names are inconsistent. Different device models may use different default values or the command syntax may change. What seems like a small change can ripple throughout a configuration, impacting things like access control lists (security) and routing protocol configuration (network connectivity and stability). Andrew Lerner at Gartner wrote an excellent article about it: Technical Debt in Enterprise Networks.
How do these differences make their way into the network? An organization’s managers and executives may prioritize rapid and lowest cost implementation over smooth operation. When price and implementation speed are factors, operational stability often suffers.
Technical debt doesn’t have to be the result of bad decisions. It can just as easily result from technological changes or changes in scale. The transition from leased lines to MPLS and then to SD-WAN is a good example. Another example is the need to revise your IP addressing plan because the organization outgrew the old design.
At some point, the business managers need to allocate the resources that are required to remove the debt that is holding back the organization’s progress. The business can then proceed at a faster pace because parts of the system are now operating more smoothly.
The network becomes more complex and more fragile as technical dept increases. Minor differences make it easy to make mistakes. The technical team members have to remember that parts of the system with the same functionality may use different commands, making automation more difficult.
Let’s look at an example: an enterprise network with 50 branches. Each branch has two WAN links and a wired and wireless LAN supporting laptops, printers, voice, and video conferencing. Firewall, QoS, and routing are needed on the router and a stack of switches is used for physical connectivity. A consistent design across all 50 branches allows one primary configuration to be used, with variables for the things that change from branch to branch.
A simple change like using a different LAN interface on the router or between the router and the switch stack requires multiple configuration changes. The automation system could be designed to automatically determine the LAN interface in use, but a consistent deployment would be much simpler to design and easy to validate. Troubleshooting a single design is faster because everything is consistent. Only one network diagram is needed for 50 sites.
Note that technology changes will require that you have two branch designs: the old design (e.g., leased lines) and the new design (e.g., MPLS).
Addressing Technical Debt in Networks
Fortunately, your technical team can use network automation to identify and eliminate technical debt. Identify parts of the network that should use consistent designs and use the automation tools to highlight inconsistencies. Check for physical consistency first, then work on configuration consistency. Manual work will be needed to fix physical consistency. Automated remediation can then be applied to achieve configuration consistency.
The problem for managers is that addressing technical debt is typically not viewed as moving the organization forward. Instead, this work should be viewed as removing the impediments to forward progress. It does take time to execute, but it sets the foundation for the technical teams to focus on new initiatives. (Managers should think of it like this: In the software development world, bug-fix releases are used to address technical debt. Reductions in technical debt provide the foundation for releases of new features.)
In some cases, an emergency situation arises where your team must deviate from the desired design. In the real world, these things happen. Make a note about it and plan for the team to address the technical debt and bring it back into compliance.
Summary
Network automation is both benefactor and provider of network consistency:
- It is a provider to organizations that use it to achieve consistency.
- It is benefactor when the network design and implementation is consistent and automation can be simplified.
Network automation allows companies to remain competitive and avoid unnecessary downtime. It is a natural integration with the migration of IT systems to virtualization and cloud technologies. The adoption of network automation is a journey comprising multiple stages. Good luck and don’t hesitate to contact NetCraftsmen if you want a partner on the journey.