Rapid delivery of enhancements and fixes is even more critical in the cloud. We can't carry a significant backlog of technical debt. The cost of switching providers is smaller in the cloud than it is on-premises, and that means subscribers are quicker to switch. I want to be careful how that comes across. I'm not saying it's ok to carry a large backlog of technical debt for on-premises software. All I'm saying is that the consequences of doing so materialize more immediately in the cloud. It's important to drive down technical debt, both in terms of addressing warnings from automated tools doing code scans, in terms of unit test code coverage, defects, enhancement requests, complexity reduction, re-factoring, and all the many aspects of technical debt. For that reason, the IBM quality program has established a Technical Debt Governance model, which teams are now beginning to adopt in order to strengthen the focus on minimizing technical debt. Sonar is often the tool of choice to create a dashboard detailing technical debt, whether integrated with the IDE (Eclipse, or similar) or integrated with the build systems to produce post build analysis. Allowing developers to see the implications of their code, whether it raises or lowers the overall technical debt, before they even check it in to the source code management system is a powerful approach that motivates cleaner coding, more complete testing, and more complete responses to customer needs. In the cloud, it is also important to understand the range of usage models subscribers want, and to design the software to accommodate them all simultaneously, since it's a multi-tenancy system. Technical debt includes the continuous adjustments needed to better accommodate the preferred usage patterns as they evolve.