Skip to main content Skip to Footer

BLOG


May 02, 2019
Identify and remedy technical debt
By: Mahesh Venkataraman​

The increasing adoption of Agile and DevOps practices has improved the speed of application delivery, which in turn improves enterprises’ ability to rise to ever demanding business needs. However, this focus on the speed of delivery through Agile and DevOps practices often comes at a price—the systems architecture does not always evolve adequately to meet the quality attributes like reliability, scalability, stability, performance and resilience, and defeats the very purpose of rapid application delivery.

Architecture debt is incurred when design decisions are taken to address immediate priorities such as faster release to production, causing technical degradation of the architecture. Such architectural degradation most impacts non-functional requirements (or quality attributes) which may not be immediately evident in conventional testing. Currently, most of the techniques used for determining and characterizing architecture degradation use static analysis.

The Situation

Design and architecture choices are often made under uncertainty, and developers and architects are not technically equipped to predict the runtime consequences of their choices. Furthermore, as the functionality evolves, significant requirements that impact architecture often keep getting added to the system without corresponding architectural remediation, in turn causing “architectural erosion” or degradation.

Another issue is that production systems often fail in a manner that cannot be foreseen. Over 80 percent of critical production failures are not reproducible because of complex fault chains and hidden faults that surface only under certain conditions of usage. Oftentimes, users can activate execution pathways that trigger default chains that are not easily visualized during development and testing.

Overall, there is a domination of non-functional failures. In an internal study, it was observed that over 75 percent of critical production failures are due to non-functional root causes like scalability, reliability, stability, performance, fault recovery, and exception handling. These non-functional failures are often associated with architecture degradation.

Solution Imperatives

There may be many aspects of architectural degradation, but not all of them are necessarily significant in the context of system usage patterns. Your solution needs to be both minimal and optimal, avoiding false positives which are rampant while using static analysis tools.

The key imperatives are to:

  1. Derive production usage patterns: How is the system used in production—what are the main services and pathways exercised? How does the system respond to these usage patterns?
  2. Identify architecture failure patterns: What are the failures and the failure causal links? What are the anomalous responses which can potentially trigger failures under specific conditions? What are the potential failure modes and pathways?
  3. Analyze the architecture: What are the architectural parameters that contribute to anomalies and failures?

Curing technical debt

The Accenture Touchless Testing Platform can implement these imperatives. It ingests device, webserver, application server, and database logs and analyzes them, extracting the usage execution patterns pertaining to services, methods, package, API, web page and transaction type. It also provides execution flow graphs that help determine the top usage pathways. In addition, the tool spots predetermined architecture problem patterns that lead to non-functional defects. These patterns are provided in a visual graph enabling the developer, architect or tester to perform causal link analysis. It can also use production use patterns to set up test environments, simulating “real-life” conditions. Through observing architecture level behavior, problems can be identified and traced to architectural degradations, and we you quickly take action to remedy the issues.

In conclusion, organizations must be proactive in identifying any problem patterns. Once identified, organizations can limit technical debt and push toward the leading edge of innovation.

More blogs on this topic

    Popular Tags

      Archive