Technical Debt Evaluation in The Context of Architecture Assessment

This note is to outline problematics of technical debt in the context of field consulting, namely, assessments of the larger commercial enterprise systems.

One of our company (SoftServe Inc.) primary consulting specialties is Architectural Assessments of the software built by our clients. The typical assessment goals might include identification and analysis of maintainability, performance, security and other issues and risks related to the quality of the software design and implementation. These issues can cause or influence money losses in product operation and sales as well as other adverse impacts on the business goals.

A typical assessment flow is presented on the diagram:

Screenshot 2016-02-17 12.07.58

Combination of qualitative and quantitative analysis lies at the heart of our assessment approach. Qualitative analysis is based on the Architectural Tradeoff Analysis Methodology (ATAM). Quantitative Analysis might combine code quality metrics computation, performance profiling, cost-benefit analysis (CBAM) and other techniques.

An architectural assessment is always time-boxed to a few weeks while the product size and complexity might vary up to millions of LOC and at tens or hundreds of subsystems or coarse components. In many cases its critical part is location of the TD items and analysis of their impact on the product development, maintenance, and operation, and as a result associated costs, business goals, and other indicators important for the product business stakeholders.

Hence, the major practical need of an assessor is in:

  • Well defined time-boxed process of TD items identification
  • Toolset to support this process
  • Meaningful approach to semi-automatically evaluate the TD associated costs
  • TD item prioritization technique based on the above

Given these four items the other assessment activities can be easily accomplished by a professional assessing architect.

Additionally, it should be noted that Technical Debt often affects the business not in its part caused by the code smells, design anti-patterns, or broken code conventions. Its worst consequences arise from such issues as:

  • Improper decomposition of the code into interdependent and integrated modules
  • Overengineering or redundant complexity of application structure, components, and communication patterns
  • Inadequate selection of the architectural patterns
  • Bad 3rd party technology choices (hosting platform, data storage, programming language, etc.)
  • Inefficient integration contracts
  • Security issues (DDOS protection, auth, encryption, etc.)
  • DevOps anti-patterns related to deployment, continuos delivery, and other types of operations
  • Suboptimal data structures
  • Other violations of quality attribute requirements for the system

A comprehensive approach to identify TD across those areas and to analyze it uniformly for impact with the goal to determine an optimal vector of application of limited resources (people, budget, time) in order to maximize ROI from TD liquidation is likely a most useful research subject from the business perspective.