Thursday, January 19, 2023

Technical debt and Dynamics 365 solution architecture

Technical debt is an important concept to understand as a solution architect. As outlined in Thoughts about the Dynamics 365 solution architect role, a solution architect has to keep the long-term use of the solution in mind and implement scalability and adaptability into the solution for the future. This is where you will need to understand the concept of technical debt.  Software design and development is full of metaphors to help non-technical people understand specific concepts - technical debt is one of them. 



What is technical debt?

Technical debt is created by (un)conscious actions to take shortcuts in development or design of a software solution. These shortcuts are taken due to some short-term benefits such as faster delivery time, easier implement etc. ... but they have an impact on the longer term. 

Having technical debt is like having financial debt, where time spent on this "not-quite-right implementation" counts as interest on the debt and paying the interest on the loan (the debt) might slow down the project/program in the long term. 

You will see 3 types of technical debt in projects:
  • Strategic technical debt: technical debt caused by decisions made to shorten time to market, delay development or expenses, ...
  • Unavoidable technical debt: technical debt accumulated due to the fact that the platform/technology/product version might not be supported anymore, ...
  • Naïve technical debt: due to business immaturity (unclear or changing requirements, misalignment between product owner and business stakeholders) or technical immaturity (no coding standards, no peer reviews, no automated tests, no refactoring, no consideration for)

It is important to grasp that technical debt is not always an indicator of low quality (but it might be). Technical debt happens because even though we do the best we can - given what we know - we subsequently learn better ways to solve a problem or better ways appear due to technical improvements in the underlying platform or technology stack.  You probably heard the phrase "Ignorance is bliss" - well for technical debt this is not the case. The fact that nobody in a team has heard of technical debt should be treated as a red flag for software quality.

How to repay technical debt?

Regardless of the type of technical debt you accumulated, in the end you will always need to repay the technical debt to make sure that you don’t jeopardize your product evolution. If the cost to implement a certain change (be it a bug fix or adding an additional feature) keeps increasing over time, it might be an indicator that you have incurred technical debt on your project.

The first step is however making business aware of the existence of technical debt and the impact of it. I really like the ideas suggested in The Wall of Technical Debt on how to make technical debt visible. Building a regular habit of identifying technical debt and learning on how to negotiate with business on technical debt payoff is a good approach.

Keeping technical debt to a minimal is a team effort - make sure that delivering quality is engrained in the culture and way of working of the team.

How to identify technical debt in your Dynamics 365 solution architecture?

As mentioned previously technical debt is automatically accumulated as changes are happening on the technical platform underpinning your solution. So I highly recommend to follow up on the  important changes (deprecations) in Power Apps and Power Automate page and also on the Deprecation of Dynamics 365 apps page. 

By writing code, you are automatically accumulating some amount of technical debt but there is tooling available to help you identify technical debt in your code and solutions:

  • SonarQube - static code analysis tool which helps you identify bugs and code smells - works for multiple languages. Quite useful for .NET and Javascript development which are typically used in CRM development
  • Power Apps solution checker - specific Power Platform tooling to analyze Dataverse or Dynamics CRM solutions. Can be run from the maker portal,  Microsoft Power Platform Build tools for Azure DevOps or PowerShell
  • Checkmarx provides static application security testing (SAST and open source composition analysis (SCA). It helps you uncover security issues in your code base or in 3d party libraries/packages that you are using. If you are looking for alternatives, you might take a look at the vulnerability scanning tools listing from OWASP
Technical debt goes broader than purely code. Technical debt is a collection of issues which makes the overall solution hard to maintain, prevent easy implementation of updates, might impact performance and scalability. So lack of technical documentation, absence of a good application lifecycle management (ALM) process, lack of test automation/heavy reliance on manual testing, missing architectural design decision log, brittle integration, monitoring, etc ... are also things to take into account as part of a health assessment of a solution architecture.

References:

op

No comments:

Post a Comment