Gartner recently set off a new industry debate when it released its piece Measure and Manage Your IT Debt.Vinnie Mirchandani (@dealarchitect) has a typically pointed, incisive, insightful response, called Gartner's "IT Debt" Scare (I guess you can tell from the title where this piece is going ;-) ).
Both Gartner and Vinnie make excellent points, but I have a somewhat different point of view.
First, Gartner was very creative to once again bring a new perspective to an emerging problem. However, there can be more than one perspective on this issue, as Vinnie's piece points out.
What is Technical Debt?
Technical debt is a term apparently coined by Ward Cunningham in 1992 to describe the shortcuts, compromises, and mistakes made in developing software. For example, many times a software project is on a deadline, and a "good" approach would take too much time or cost too much in resources, so project members take note of the problem and use a quick hack to just get by for now. The quick hack introduces costs later in the project that build up over time if the "technical debt" is not paid off. For some great overviews of technical debt, see here and here, plus the infographic here.
Technical debt is commonly used to describe architectural shortcuts made in software product development in start-ups, but can be applied as a concept (as Gartner has done) to many other related areas - for example, IT lapsed maintenance, deferred maintenance on a home or public utilities, or failure to invest in areas that give a long-term payoff.
Technical debt - TO or BY the software vendors?
Some technical debt has little or nothing to do with enterprise software vendors; it's the same kind of technical debt accrued by large and small software vendors where shortcuts are taken during IT projects.
However, as Gartner positioned this problem (according to other reporters such as Vinnie and Larry Dignan, as I have not read Gartner's article on this topic), at least part of this debt is a debt to enterprise software vendors - forgone upgrades, or even going off maintenance. The theory is that firms will skip an upgrade from time to time (or, worse, a patch), or go off maintenance on enterprise software, creating some amount of technical debt; after all, upgrades get progressively harder to apply as more upgrades are skipped over, and going off maintenance can lead to missed security patches as well as costly "relicensing" fees in the future. One way to look at this technical debt is that it is a technical debt owed to enterprise software vendors.
However, another way to look at this is as technical debt owed BY enterprise software vendors to their customers. After all, if these updates, upgrades, and patches had enough value in them, and cost little enough to apply, then the ROI (benefit/cost ratio) would be sufficient to justify keeping up with the vendor's software releases. The gap between the ROI needed and the actual ROI for each release is a form of technical debt - but its a debt owed by software vendors to their customers.
There are two ways vendors can increase the ROI of these releases - by increasing the numerator (return or benefit) or decreasing the denominator (investment or cost). Simple, right? Increasing the benefit can be accomplished by planning periodic usability or functional updates that can go along with emergency fixes when needed, or by reducing the frequency of patch releases. The cost can be reduced by reducing the frequency of patch releases, creating tools that determine whether a particular release is needed by the customer, by handling the updates on the customer's behalf, by avoiding schema changes, and thoroughly testing every upgrade.
SaaS versus on-premise
Any enterprise software discussion these days has to include a discussion of SaaS (or cloud) versus on-premise deployments. What does the cloud have to with this topic? SaaS-delivered applications change the economics of software in many ways, and technology debt is yet another case of this. SaaS-based applications may not automatically result in greater benefits related to new releases, but they do offer the opportunity to reduce the costs of upgrades - because most of the infrastructure upgrade costs are borne by the vendor, so SaaS vendors have developed techniques and a body of knowledge that minimizes those costs.
Often, this is not the case with on-premise software. Customers have a very diverse landscape of systems, integration points, operating system versions, and set of applied patches; as a result, it just isn't possible for vendors to sufficiently test upgrades for all these permutations. Of course, customers are also responsible for the costs and efforts of each upgrade, not benefiting from the economies of scale when many customers are on identical environments simultaneously upgraded - as in a SaaS deployment.
On-premise software vendors generally do not optimize for low cost of upgrades, at least not to the same extent as SaaS vendors. By definition, on-premise software vendors cannot test every customer's upgrade with every release; in the SaaS world, such testing is standard operating procedure. These days, SaaS vendors even give customers some time to test upgrades before switching over to a new release, allowing customers time to test any custom extensions or integration points, as well as to test new features and develop new work processes to benefit from the new functionality of each release.
Many times, software upgrades go along with infrastructure upgrades - the new version may not be available for a particular brand of previously-supported hardware, a previously-supported operating system, or perhaps an outdated database. When this is the case with on-premise software, the customer has to bear the cost of upgrading to new infrastructure, testing other related systems on the new infrastructure, and training employees who manage the infrastructure and the new software. These costs are, again, not borne by the customer in a SaaS environment; the SaaS vendor takes on this burden. Incidentally, this burden is lower for the vendor in the SaaS world, since only one (or two, when multiple versions of applications are supported simultaneously for customers) configuration needs to be supported and tested, and because the SaaS vendor controls the upgrade cycle to minimize costs and disruption.
Do SaaS applications completely eliminate technical debt?
No. But SaaS applications significantly reduce technical debt, primarily by eliminating a backlog of unapplied patches and upgrades, eliminating costly infrastructure upgrades, and eliminating the "death matrix" of supported platforms and infrastructure.
(c) Oracle Corp.
Maybe I'll cover virtualization in a future blog, as virtualization holds some promise as a way for on-premise software vendors to come to grips with some of these problems and alter the economics of upgrades once again. Feel free to share your thoughts in the comments section below.
Links:
- Measure and Manage Your IT Debt - http://www.gartner.com/DisplayDocument?ref=clientFriendlyUrl&id=1419325
- Gartner's "IT Debt" Scare - http://dealarchitect.typepad.com/deal_architect/2010/09/gartners-it-debt-scare.html
- @dealarchitect - http://twitter.com/dealarchitect
- Ward Cunningham on the term "technical debt" - http://www.c2.com/cgi/wiki?ComplexityAsDebt
- Technical debt overview 1 - http://www.martinfowler.com/bliki/TechnicalDebt.html
- Technical debt overview 2 - http://forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
- Technical debt infographic - http://www.martinfowler.com/bliki/techDebtQuadrant.png
- Larry Dignan on technical debt - http://www.zdnet.com/blog/btl/is-there-really-a-global-it-debt-of-500-billion/39580
