What is technical debt?
The father of the Wiki, Ward Cunningham, coined the term “technical debt”. He used the word to refer to the inherent inefficiencies of software, which could be caused by developers rushing software into production or it could be because they created software with vague requirements. Another common cause of technical debt is over-customization of standard software – forcing software to do what it was never designed to do.
With all due respect to Cunningham, I will expand on the idea of technical debt. What if that also included inefficiencies in the job itself, like time wasted on workarounds or money spent to compensate for bad data. Cunningham also uses the term “burden”. Just like in our personal life, whenever you have debt you have to pay interest. So rather than using the word burden, perhaps we are thinking of the residual effect of technical debt as technical interest. It is the price or the penalty for the wasted effort or inefficiency associated with technical debt. It’s not just about money either, it can be low customer satisfaction, low employee morale, or networks that aren’t resilient.
What does technical debt look like?
It’s a pretty abstract idea, so let me share an anecdotal story. For over 10 years, I have worked with telecommunications companies of all sizes. A fairly consistent scenario that I have observed in my work involves polls and field verification of designs. A network planner or designer will create a new network design that could include underground installations through rows of conduits and handholes.
Before moving forward with the design, the company would send an employee to the field to investigate every handhole or row of conduits to make sure there were, in fact, conduits and ports. voids available for use. Why would they do this? Because they didn’t trust their own records. They had CAD files, a procurement system, maybe even a GIS, but they weren’t integrated and the accuracy was questionable. It was less risky to go out into the field, open each cabinet or handhole, take a paper map of the design, and verify that the conduit and ports were available. Rather than change the process and fix the fundamental problem of inaccurate data, they continued with the trucks and the field work. They would not eliminate technical debt.
Another way to identify and quantify technical debt is through data latency. We are all familiar with the concept of network latency, but now think about it in terms of the activity of your carrier itself. How long does it take between releasing, expanding or upgrading a new network and when your GIS reflects this updated information? In other words, how long do new capital investments sit idle before sales know they can sell services? I have observed delays ranging from 48 hours to six months. If it takes weeks to incorporate network changes and additions into your corporate MIS, it’s like paying only the minimum payment on a credit card.
To eliminate technical debt, change the process
One of the most frequently asked questions from customers lately is about NextGen networking in ArcGIS: “What is the ROI of implementing the distribution network?” “Telecoms are also asking:
- Will the implementation have a positive impact on my key performance indicators?
- Will it reduce overtime, operations and capital spending?
- Will we see a reduction in network outages and downtime?
- Will employees get their jobs done faster?
- Will our business have fewer security incidents?
The answer is yes. How? ‘Or’ What? By reducing embedded inefficiencies, that is, by reducing your technical debt.
Does it take effort? Of course! Paying off debt is rarely a fun or glamorous event. But it’s a great feeling once the debt is gone. Telecoms will need to add missing data to their existing network records. They will have to redesign well-established workflows. This could mean completely rethinking the way telecoms think about GIS.
ArcGIS pays off technical debt
ArcGIS may not be able to pay off your mortgage or student loans. But it can definitely save you money and lower your interest payments on your technical debt. How? ‘Or’ What?
- Extensive attribute rules – ensures data is accurate and consistent as it is created
- Accurate device modeling – realistic 2D and 3D modeling, resulting in a digital twin
- Enhanced security – adheres to the highest standards
- Services Architecture – allows network functionality to exist on any device (yes, even mobile)
- Network technology agnostic – model fiber, coaxial, wireless and copper networks in one place
The digital twin can become a reality if we eliminate our preconceived notions and cognitive biases about the way things are done. NextGen Network Management in ArcGIS takes advantage of modern technology to completely reinvent the process of designing, building, modeling, analyzing, and sharing one of a telecom’s most valuable asset: its network infrastructure. ArcGIS offers the power to do the things your organization’s dreamers have been envisioning for years. It presents an opportunity to see workarounds and supposed constraints for what they really are – technical debt interest payments. ArcGIS drives innovation and transformation because it helps telecoms see the possibilities when bad habits are replaced with healthy ones.