Sharif Nijim from Notre Dame is leading a discussion on driving out technical debt.
Technical debt is a concept that when you make technical compromises you build up technical debt that you then have to pay off later. At Stanford it’s being used to talk about not keeping bench-depth of staff in various areas, or deploying systems without the companion expertise in the tool. Allows you trade off quick delivery for long-term payoff.
Kitty notes that there is technical debt in all of the legacy services we keep hanging on to as we get thinner and thinner on the ground. Michael notes that it’s not just technology but also in skill sets, expertise and other areas. Laxmi brings up the concept of varying levels of risk in debt – not always the same.
Ilee – With ERP systems we create backlogs of requests from user community that we can’t get to. With old technologies the cost per unit change is higher – that’s why you want to retire technical debt by moving to new technologies. Want to incorporate new features that take care of some of that backlog. At USC they had systems that were 25 years old – was getting increasingly harder to find people who could maintain the software, and it took a long time to get things done. They decided to go to Kuali for finance and research administration, for HR they decided to go to Workday, still working with Kuali group on Student system. The timeline started in 2009, and will end in 2016/17. They think that the cost per unit change will go down as well as gaining improved business processes. They’re automating processes that used to be manual, allowing more debt to be retired. Created a data warehouse with Cognos that also allows the University to do analytics.
One way of looking at that is replacing older, riskier debt, with newer higher-quality debt. Will also allow of the retirement of debt in some distributed areas as shadow systems are eliminated.
I asked how one measures this technical debt – Teri-Lynn says that Garnet must have a method because they have done estimates of the size of technical debt overall, but she hadn’t been able to find any methodology documented.
Mark notes that there’s debt you take on intentionally or debt that you back into, and looking at it as balancing the risk in your portfolio is a way of understanding it. With financial debt we know what’s on our books, but we don’t know with technical debt.
Michael makes the point that not all debt is bad – Kitty likens this to “I’ll gladly pay you Tuesday for a hamburger today.” Tim says that as we try to get to yes in satisfying requests we are taking on more debt. Bruce says that as we make tactical decisions we have to be conscious of keeping things narrow enough to not let them creep into more debt. Kitty talks about the maturation of service management and service owners not always realizing the amount of technical debt that particular technologies are accumulating. Bruce notes that this is because people are attached to the technology, not the capability.
Steve notes that sometimes retiring technical debt can come at the cost of incurring political debt.
It would be good if we had periodic reviews of debt. We could categorize the debt the same way we do with risk management. Tim asks if we could catalog the debt perhaps as an addendum to our service catalog. Kitty replies that many of us do risk management, and incorporating this as a concept of risk management could help.
Tim talks about Harvard’s approach – they’ve identified a person to evangelize the concept of technical debt, provide that level of awareness to the business. He’ll follow the approach of building risk statements into the services. It’s in a formative state.
In the chat room the question is raised as to whether we’re building “cloud debt” as we move services to the cloud.
Oren Sreebny 