Fotolia
Can a loosely coupled architecture reduce technical debt?
While there are a lot of factors that impact technical debt, the level of coupling found in the underlying software architecture is often a primary culprit.
The term technical debt refers to the sum of the omissions, mistakes and poor software design decisions that fester within in a project and, eventually, create downstream difficulties in maintenance and update processes. As many organizations and development teams have discovered for themselves, the design of the underlying software architecture -- particularly the level of coupling between components -- has a huge impact on the amount of technical debt application development and management processes generate on a regular basis.
This article examines the association between component coupling and technical debt. Then, we'll review how the loose coupling associated with microservices-based architectures directly addresses the technical debt issues surrounding the monolith. Finally, we'll go over the rules to follow when refactoring for loose coupling that will help developers avoid reintroducing rigid dependencies.
Tight coupling vs. loose coupling
The tight component coupling associated with monolith-like architectures often fosters rigid component dependencies that make it impossible to create updates or version services in isolation. A tightly coupled architecture model will accrue more technical debt than properly distributed models, often for the following three specific reasons:
- a loss of component reusability and increase in duplicated development efforts;
- difficulty identifying dependencies and avoiding errors from poorly coordinated changes; and
- delays in software availability due to long, rigid development cycles.
There are all sorts of coding habits that foster overly rigid couplings, such as linking data between services through direct file transfers rather than passing parameters. But no matter the source, these dependencies will create compounding technical debt, due to the fact that an update to any one software component will likely require a change to most -- if not all -- of the components and services it's connected to. Every single change will trigger a rippling effect of necessary updates that swallow up time, cost money and increase the risk of breakages.
Alternatively, the loose coupling typically found in microservices-based design limits dependencies through a proper separation of software components and services. By restructuring the architecture model to encourage hygienic programming practices, such as facilitating data transfers via parameters instead of direct transfers, development teams can overwhelmingly reduce the long-term impact of frequent updates and technology upgrades on large software systems.
Refactoring for loose coupling
Organizations committed to rapid development cycles shouldn't question whether they can significantly reduce technical debt through loose coupling -- they should take it as a given. If someone on the IT team has microservices experience and some software is already implemented using loose coupling and microservices, the chance that refactoring for loose coupling will pay off increases.
Of course, it's much easier to introduce loose coupling in greenfield projects, as opposed to refactoring existing applications for increased separation. Given the difficulty of refactoring code, there are a few guidelines that can help you determine if a refactor is necessary.
- If rapid development practices are in play and updates are frequent, loose coupling will pay off -- even if refactoring is required.
- It may be possible to make the shift away from a tightly coupled architecture gradually by scheduling updates to components in response to changing requirements, rather than embarking on a large, singular refactor of the entire codebase.
- If the software is both fairly new and structured so that active components can be easily identified and isolated, refactoring is likely not necessary.
- If the company has problems retaining software personnel, effective refactoring will likely be difficult -- it's expensive (and risky) to outsource development, which will likely negate the financial benefits you hoped for in the first place.
Assuming it's justified, how should organizations proceed with refactoring? The risk here is that if attempting to reduce the effort and cost by cutting corners, coupling will remain too tight, nullifying the potential benefits that justified a refactoring project. To avoid this, go back to clean model application design principles. Identify the most critical functions of the existing application in that model, taking careful note of individual code contributions for each function and identifying who made them. As developers add code to implement new functions, teams should simultaneously salvage the blocks of existing code that can be incrementally modified to fit a microservices model.
The most common culprit in tightly coupled architecture problems is the use of persistent storage to pass data between components. When multiple application components need access to a single record location, the record should be passed as a parameter, not stored within the application code or database. Keep an eye out for scenarios where that type of data is embedded in code, and stamp it out during refactoring. This good code hygiene habit will go a long way in preventing accidental tight coupling situations and make it much easier to reduce technical debt.
