By Kevin Cox, AWS SAA, CCSK
Lead Consultant, Impact Makers

What is technical debt?

The term “technical debt” originated from Ward Cunningham, one of the authors of the Agile Manifesto. He once said that some problems with code are like financial debt. Technical debt is incurred by completing work in a swift way with some known and/or unknown gaps, which is like a financial debt. Like a financial debt, the technical debt results in interest payments, which come in the form of the extra effort that technology professionals must do in future work because of design choices or shortcuts. We can continue paying the interest, or we can pay down the principal by correcting or polishing the hasty work results into more refined results. Technical debt is usually unintentional, but similar to accrued interest, the impact often increases over time.

Where can technical debt be found?

Technical debt is also relevant to architecture, infrastructure, and operations. Technical debt can occur in IT operations during a rollout or implementation. Technical debt can also be introduced to an environment by not keeping up with advances in technology or processes. Technical debt is often introduced with a short-term thought process that can be summarized as: “We know this isn’t ideal, but we must deliver this now.” This has a large scope that crosses many areas in technology such as development, operations, CI/CD, DevOps, management, etc. Technical debt can extend over a wide area of environments and platforms such as Hybrid cloud, Cloud Native, and Multi-Cloud.

This example chart shows a typical cycle of technical debt over time. As the technical debt increases, the costs also increase, and efficiency goes down.

How is technical debt introduced in AWS?

Some specific areas where we can dive deeper and consider the real costs of technical debt are cloud governance and organization of resources. Often, we work with customers who have already started their cloud journey or have been using cloud platforms in a limited capacity. The AWS environment may have been created to solve a specific problem, overcome a budget challenge, or meet a new requirement. Usually, these environments were created quickly and met the stated business objectives in some way. In these examples, a Cloud Strategy is often established, and a Cloud Architecture is delivered, but a comprehensive framework has not been followed and gaps can be introduced that lead to technical debt. This AWS example is just one of the challenges we see from customers but can apply to many areas in IT.

What is technical debt in action?

In order to show how technical debt can occur in a real-world scenario, imagine we are examining the situation described in the paragraph above, some months or years later. In this example, there are hundreds of security groups, hundreds of name tags, inconsistent naming standards, and employees create new tags swiftly instead of using the existing tags due to the lack of an expressed tagging/metadata policy and sparse governance. This is technical debt in action. Consider the burden on this IT team to implement a new solution to solve a new business problem. They likely do not have a good inventory of what AWS resources map to cost centers, teams, applications, or how to integrate with new AWS resources.

How does technical debt spread?

Imagine you are now tasked to deploy a new EC2 instance into a public subnet of an existing VPC for this environment. When you get to the security groups to apply to the instance, you might have the following choices at the top of a list that includes hundreds of descriptions or name tags:

Johns-sg-internal
launch-wizard-1 created 2018-10-04
launch-wizard-6 created 2017-05-05
Donalds-sg
Ports-locked
Bob_dont_use_this_sg
Shelobslair
Load Balancer Security Group 4
RDS SG VPC

What ports do these security groups protect? Does the name help you pick one? Will you cause a data breach by picking one of these unknown elements? Maybe “Ports-locked” is a good choice, maybe “RDS SG VPC” is too, not sure. An employee will probably make a new security group and put in a name that makes sense to them. This incrementally adds to the technical debt.

How can I address and reduce technical debt?

Asset/Metadata management, governance, and compliance are often overlooked in cloud migrations, CloudOps, or eternally exiled to “the next iteration” of a cloud journey or migration. At Impact Makers, we bring this area in scope to ensure the success of your project. We help customers define standards, detect drift, automate the enforcement of standards, and work with the customer to arrive at the optimal solution. This could be a native AWS solution, a third-party tool such as Cloudcheckr, Fugue, Cloudvisory, or other options. In typical cloud migrations or projects, attention is usually devoted to the application and/or workload architecture with the details of EC2 compute sizing, Lambda serverless computing, VPC design, and areas like continuous deployment. These technical needs are critically important elements to a cloud journey—but it is imperative to remember there are also other areas that need to be in scope.

This example chart shows a typical cycle of addressing technical debt over time. As the technical debt is addressed and decreases, the costs also decrease, and efficiency goes up.

Learn more: The Impact Makers Solution

At Impact Makers, we leverage comprehensive and mature practice to enable customers to see all facets of their AWS ecosystem. Every project has unique elements that must be incorporated into a comprehensive strategy in addition to identification and execution of technical work. As Advanced AWS consultants, we recognize the impact of technical debt on the future of your cloud journey and we will help you optimize your present and future usage of cloud. Our comprehensive framework includes the AWS Well Architected Framework and industry best practices in addition to elements like technical debt, asset and metadata management, business strategy alignment, service portfolio management, support model definition, service design and deploy, CloudOps and much more. We work with our customers to deliver and enable strategic business advantage with cloud services.

To learn more, contact us.