The concept of technical debt was put forth almost thirty years ago. It describes a phenomenon in software programming whereby decisions made early in programming to simplify something or do a “quick fix” end up compounding into a complication later in a project that impacts performance. Think of technical debt like interest compounding on a credit card you seldom use, to then one day find out you owe a huge amount of deferred interest. Just as in the financial case, the more technical debt you incur and the longer you take to repay it due to compounding interest, the cost to dig yourself out of this debt can become unbearable. Similarly, keep these concepts in mind by rationalizing your IT/OT ecosystem.
Originally technical debt was applied specifically to software development, but the concept has now been applied to other aspects of technology deployment. It is used to describe architectural problems, application portfolio issues, and a wide variety of other technology-related problems businesses face.
This article may be of interest: Why Now is the Time to Cut Technical Debt
Debt Isn’t Always a Bad Thing
Sometimes it makes sense to take on debt. Most people don’t wait to purchase a home until they can pay the full purchase price, so they take out a mortgage (debt). Likewise, in the technical sense, taking on debt can be a good decision as well.
In the software development field, it makes sense to make a few code hacks to test out a user interface (UI) and get immediate feedback from some potential customers. But if you let those code hacks remain so you can get the product to market faster, the debt will ultimately come due as you try to support, maintain, and evolve the UI, potentially becoming unaffordable.
It is like borrowing against your home for a grand “around the world” vacation and your debt exceeding the value of your home. Any change in circumstance and you might lose your home if you can’t pay back that debt.
How to Address IT/OT Architectural Technical Debt
Considering the broader view of technical debt, there are several ways an enterprise can’t rationalize the technical debt they incur. Since complex discrete manufacturing and asset-intensive organizations, such as those operating in the aerospace, defense, or other industrial sectors have a mixed information technology (IT) and operational technology (OT) architecture, they are often at risk from technical debt from an IT/OT architectural aspect.
It can be easy to justify adding to your technical debt by allowing for an ad-hoc implementation of these types of technology solutions on a point basis, given the complexity that can surround a better designed and more costly solution. Alternatively, it can be easy to accept point solutions when trying to best operate a collection of systems that you may have “inherited” from a previous management team, or through a recent merger or acquisition.
It is important to note that this is not a repudiation of a best-of-breed approach to systems and application selection. It is, though, a reminder that as with any choice, one should consider the technical debt that every decision carries. It is important to remember that a single-vendor approach carries technical debt as well since it ties you to the vendor’s pace of evolution and feature adoption.
A Well-Defined Ecosystem Reduces Debt
To minimize the technical debt associated with a multi-vendor environment that still retains your ability to migrate and evolve as technology and functional demands dictate, it is important to view your environment, not as a collection of independent solutions but rather as an ecosystem of interconnected parts that all work together.
Biologically speaking, you would not expect flora and fauna found in a tropical rain forest to survive in a desert environment. Of course, you could spend an exorbitant amount to create tropical conditions, but that is the equivalent of incurring debt.
In the creation of your IT/OT ecosystem, it is equally important to select solutions that work together in your defined environment. Some key environmental factors that you should consider when defining your ecosystem are:
- Supporting industry and corporate regulatory compliance
- Ensuring adherence to appropriate safety and security standards
- Utilizing common technology and communication standards
- Maintaining recognized user interface models and technologies
- Designing for platform interoperability, such as common APIs, Cloud platform infrastructure, or interface support
Each industry may have additional environmental factors as will companies that may have corporate technology standards. Pick a set of suppliers that can exist in a compatible ecosystem to capture the benefits that a best-of-breed approach can deliver while minimizing the technical debt associated with a multi-vendor IT/OT architecture.
