New CAST AIP Release: Part 2 – Appmarq

As you may have heard, we are launching a brand-new version of CAST Application Intelligence Platform this month, and we’re giving our readers a special preview of what’s in store for the release in a series of blog posts. In case you missed it, we previously shared details on the new Delivery Management Tool that eases the process of delivering enterprise source code.
For part two of our series, we will look at a new feature which has been integrated directly into the AIP dashboard.

Don’t Dawdle on Debt: Establishing a Technical Debt Action Plan

Recently, Gartner Analyst Andy Kyte made quite a stir when he published a report that brought to the forefront just how expensive the cost of software maintenance is becoming for the IT industry.  As reported by Patrick Thibodeau in Computerworld, Kyte cited what he called IT Debt as already standing at $500 billion and fast on its way to surpassing $1 Trillion globally.
More recently, the reason why these numbers are growing exponentially was pointed out in a TechRepublic blog by Chip Camden who said, “Some organizations treat Technical Debt similarly to how some governments and individuals treat fiscal debt: they ignore it and just keep borrowing and spending. In terms of Technical Debt, that means ignoring the mistakes of the past and continuing to patch new solutions over old problems.”
But why would anybody ignore something that puts their business at risk?
What is Technical Debt?
There are many ways to define and calculate Technical Debt.  When we conducted our APPMARQ study early last year, we defined it as the cost to fix the structural quality problems in an application that, if left unfixed, put the business at serious risk.  We stress serious because we didn’t include all problems in the calculation of Technical Debt, only those application structural quality problems that are highly likely to cause business disruption. We did find that the average application in a Global 200 company has more than $1 million in Technical Debt.  Even a small number of critical applications add up quickly to staggering hidden costs.
So to answer the question of why a company would ignore Technical Debt, the answer is “they shouldn’t!” What they should do is set a Technical Debt threshold to determine how much is too much, and then remediate the rest.
Setting a Technical Debt Threshold
When it comes to Technical Debt, a company needs to determine how much, if anything it should put into remediating it.
This is what Technical Debt does – it puts a monetary figure on application structural quality and enables comparisons that were not possible before between IT costs and potential losses due to failure.  The goal is to keep the number of structural quality violations – or more importantly, the cost to fix them – well below the cost the company would incur should they be deployed and a failure ensued.
A Technical Debt Action Plan
We recommend that CIOs and heads of applications use an automated system like CAST’s Application Intelligence Platform to evaluate the structural quality of their five most mission-critical applications. As each of these applications is being built, measure its structural quality at every major release. When the applications are in operation, measure their structural quality every quarter.
In particular, keep a watchful eye on the violation count; monitor the changes in the violation count and calculate the Technical Debt of the application after each quality assessment. Once you have a dollar figure on Technical Debt, compare it to the business value to determine how much Technical Debt is too much and how much is acceptable based on the marginal return on business value (see graphic depiction below). For a framework for calculating the loss of business value due to structural quality violations, we recommend, “The Business Value of Application Internal Quality” by Dr. Bill Curtis.
Determining your Technical Debt threshhold

The Current State of Application Quality

On Wednesday, October 20 at 8:30 AM, our SVP, Chief Scientist, and Head of CAST Research Labs, Dr. Bill Curtis keynoted the TesTrek conference in Toronto, Canada.

Appmarq Makes Software Quality Benchmarking a Reality
Bill’s talk, “The Current State of IT Application Quality” covered key results from our latest study on application software quality from around the world – 288 applications from 75 companies in all major industry sectors including the public sector.
For years we’ve had software timeline and budget benchmarks. Now we have what are arguably, the most important data – the quality of the product produced.

The results Bill presented are from our Appmarq database – the only repository of software product quality metrics in the world. Appmarq makes benchmarking software quality a reality.
You can check out the results in the executive summary of the CAST Worldwide Application Quality Study – 2010.
Appmarq enables us to calculate the Technical Debt of a typical application in your portfolio. Here’s where you can read more about how we calculate Technical Debt.

First Annual CAST Study Reveals Over $1 Million of Hidden Costs in An Average Business Application

Structural flaws of business applications, such as outages, performance degradation, security breaches, and data corruption, have long been a major driver of high IT cost. This week CAST released the results of the largest software quality study using 288 IT applications from 75 companies in various industries, to provide IT executives with valuable information they need to manage the cost and risk of their IT applications.
The study, which analyzed the problems of these applications and the cost to fix them, revealed that each average-sized application translated into a technical debt of over $1,055,000. It also found that applications in government agencies scored lowest in changeability, an attribute that makes an application easier to modify or to transfer to another team. Low changeability scores indicate an application is more difficult to maintain, a condition that magnifies its technical debt. Results also showed that software quality scores tended to be highest where there was a business mandate, such as higher security scores for the core business applications that run financial services.
These findings stress the importance of fixing structural quality problems in order to avoid risks of outages, breaches, and other costly problems in the near future. If these high technical debts are prevented early on, IT executives can make much better use of their resources to develop new competitive functionality for their businesses. Read the full study results here.