How Software Architects Can Manage Technical Debt in a Microservice Architecture

Most software architects wear two different hats – they act as software engineers and technical leaders. However, software architects often face an uphill battle when it comes to convincing product and project managers to agree to allow them to fix a project’s technical debt.

This article will focus on how software architects can utilize a well-planned and non-confrontational system to manage issues relating to prioritization. As part of this approach, we’ll look at how to build a technology capability plan and why software architects should be mindful of technical debt.

What is Technical Debt, and How Does it Impact Your Project and Team?

At the most basic level, technical debt is the set of decisions made during software development that minimize a team’s ability to build features that create value. When left unchecked, technical debt accumulates and can destroy a company’s ability to navigate its marketplace successfully.

Even worse, if technical debt is ignored, it can also result in an entire software system destabilizing and falling apart. For example, your company may rely on numerous microservices built on different code versions. If projects fail to be migrated to newer software, security holes may appear, or support may be dropped. By addressing technical debt, you can unify your corporate culture and empower engineers to assume responsibility.

Technical Debt Comes in Different Types

Often, engineers are faced with two choices when developing software. One, they can create an easy and fast solution to a problem. The result is that a feature or product can be shipped, but significant problems can occur later on. For example, a quick solution may not be portable or cause unforeseen complications. Recently, Tesla had to recall 27,000 cars over a problem linked to its software.

The alternative is to develop the best solution for a problem. However, this choice is often ignored because projects and teams are held to a tight schedule. Failing to address easy and fast software solutions results in an accumulation of technical debt.

Another type of technical debt occurs when your technical stack experiences obsolescence or inadequacy. Inevitably, despite choosing a strong application architecture, any software or code you implement will become obsolete at one point. When you fail to develop a plan for tackling this issue, your team will face greater hurdles down the line.

In either case, these types of technical debt pull resources away from value-adding activities like fixing bugs and developing new features.

How to Facilitate Technical Debt Management Using a Technology Capability Plan

The Technology Capability Plan (TCP) will allow you to manage your technical debt intelligently. It will also help educate stakeholders about what software issues must be fixed and when. Additionally, your TCP can help you identify privacy and security risks that emerge.

The TCP uses communities to build plans for eliminating technical debt. Different groups of contributors come together to build risk scores for each problem area. Priorities for tackling these areas are then set based on the risk score. Ultimately, these prioritized plans are used to negotiate with product managers to allocate engineering time to eliminate technical debt. The result is both positive and practical.

Build Engineering Communities

Engineering communities are built across teams and products and are typically made open-access. Engineers will then be drawn to these internal communities because of shared interests. For example, engineers working across different microservice development may both be using the same programming language to develop web-based apps. Engineers from both teams can collaborate to address questions and help grow the communities organically.

Internally, these communities utilize shared communication channels, like wikis, chats, and email lists to develop conversations and share resources. Then, these groups meet regularly and share their findings and summaries with all engineers. Once a quarter, these findings are assembled into the TCP and published internally.

How to Address Paying Down Technical Debt

One of the key steps in understanding your technological risk level is performing data analysis in your engineering communities. Each community plan should contain an explanatory narrative and a table that outlines the desired path for technological evolution.

How you build your narrative and table is up to you. Some experts have recommended using time periods, lifecycle status, and the technology’s version and capability. Different organizations will have different needs depending on their software and timeline. In any case, the explanatory narrative will create a context for how software is being utilized, and the table will illustrate a timeline for how technical debt is being accumulated.

Once these plans are established, they can be submitted for inclusion in the TCP.

Building Your Case for Engineering Investments

Once incorporated into the TCP, these portfolios can be ranked and scored. This system will create an intuitive way for project managers to understand your organization’s technological risk.

Some firms use a balanced scorecard. These scorecards, originally developed by the Harvard School of Business, demonstrate how each technology and product in your firm are creating technical debt.

One of the easiest ways to automate the risk score is by creating automated code that analyzes your software repositories to determine technology dependencies. This way, you can penalize products and technologies for using technology and software that have been marked as deprecated, migrated, or removed.

Ultimately, these aggregate risk scores for technologies can sum up to the aggregate risk score for the product itself.

Convincing Product Managers to Allocate Resources to TCP

TCP creates an organization-wide effort at identifying technology risks. Because the TCP is built using communities across the organization, it can demonstrate to product managers how technical debt increases risks in the company.

Executives who have embraced TCP can then be used as leverage against project managers that demand more features than are possible to implement. The TCP, thus, establishes a clear roadmap for the organization to allocate resources, both to new product features and to resolve technical debt backup. Software security and vulnerabilities such as phishing scams are among the highest priorities for organizations today.

Because the scorecard creates an aggregate risk score for all technologies and products, managers and executives can quickly identify how resources should be spent. Any product manager that ignores these risks will quickly be corrected by leadership should any troubles arise.

These reports and analyses represent a robust tool, not only for engineers and their organization’s communities but also for all levels of leadership. By developing and implementing a TCP, you’ll be able to stay competitive and focus on advancing towards cloud-native application development.

1. SaaS Security Guide: How to Protect Your SaaS Business
2. Understanding Software Supply Chain and How to Secure It
3. How software and cyber security can make a huge difference in business
4. Benefits of having ‘pandemic’ software in post-coronavirus pandemic business
5. Behavior-based vs IOC-based Threat Detection Approaches: How to Prioritize?