Having technology debt within the technology estate can create various problems.  What methodologies do you use to score, measure, track etc. technology debt?  We use a methodology that was developed in house and I am curious what others are doing and using in this area.

We use our EAM tool to track
- Applications;
- Components of each 
- Tech version per component 

We wanted to have the teams own their own Tech Debt with a measurable Tech Debt Score, so we developed a framework described here: 

https://www.linkedin.com/pulse/technical-debt-framework-practical-ten-step-approach-escaping-tamer-ojdge/?trackingId=3WZCEdGIpNMfVTpmAz2JNw%3D%3D
 

We use a mix of our CMDB platform and our Enterprise Architecture platform to track Technology platforms and technology obsolescence and also leverage some external software for patching details.

Together with some home grown and self defined procedures and obsolescence data sourced from these platforms we track the technology debt and define roadmaps for addressing them as part of our overall Enterprise Architecture Roadmaps.

We are using service full lifecycle management, using standard tagging in ServiceNow for Retire, Invest, and Maintain; we manage the deviation expense and technical debt through the lifecycle management, where we then systematically target those in retire (including tracking cost, complexity takeout) for maintain, we have architectural runways that provide and future state of where the technology is going/replaced and then subsequently marked as retire once the decisions are made. For Invest, we track only deviation expense, where a particular lifecycle element deviates from the ordinary standard. We are using AI to ask questions as an overlay to questions elements of the CMDB, such as the cost/dependency view of technology debt and their associated paths to retirement.

Hi,

We're using many different tools:
A) We have an inventory of each applications;
B) For each application, we have its list of components;
C) For each component, we have its list of technologies;
D) Then, we have a date of "deprecation".

For example, this is true for librairies, databases, OS, servers, software.

Then, a score from 0 (SaaS solution) to 4 is assigned to each technologies/components.  The closer we are to an end of support, the highest is the score.

An application general health score combined the "deprecation", the business fit (does the application still fulfill its mission) and other indicators (stability, security, etc.)

Finally, based on this, we use Gartner's TIME model (Tolerate, Invest, Modernize or Eliminate) to add a disposition to each application.

With all these data, we can create 3-4 years view, we can simulate obsolescence caused by "end of support", etc. 

Not sure if I'm quite clear, but do not hesitate to reach out!

Steve

We too use an inhouse developed tool. We have a dashboard of all applications that has a technology status. We have expired, Due in next 1-12 months, 12-24 months, and OK. Our CPO's (Portfolio Owners) have the responsibility to ensure their portfolio is kept current. We looked at other tools for this but decide inhouse developed gave us what we needed. 
Our challenge a bit is getting the >24 months heads up that a specific technology is going to be out of compliance. In some cases due to nested and integrated systems, i can take upwards of year to get all the needed upgrades done.