For the purpose of this discussion, let’s scope “technology debt” as the effort of the IT organization to maintain its computing infrastructure and keep it current. Microsoft recently stopped supporting Windows XP? Tough luck, you’ll just have to suck up the cost and effort to upgrade your systems — or, run with an unsupported infrastructure.
One of the least discussed benefits of SaaS is how they can help organizations avoid and overcome this technology debt.
This is the story of technology debt in the SaaS era.
What is technology debt?
Technology debt is about keeping your infrastructure on the latest and greatest version provided by your software vendors. When you apply Microsoft updates and patches on Tuesday night, you’re paying the debt. When you upgrade to the latest version of Oracle, you’re paying the debt. Importantly, while some of the debt paid may have a tangible benefit to your organization, a significant portion has no value whatsoever — you simply do it because your ISV has determined that it is time to upgrade. Some debt can be paid automatically and with little to no effort, but some debt will become expensive (I’m not getting into politics now…) and will consume a big chunk of your resources.
Similar to a financial debt, failing to pay your technology debt on time can land you in a difficult place. An unsupported infrastructure or technology products that can no longer properly integrate with other systems are potential penalties that you will incur. You have to pay the debt — and pay it on time.
Paying the technology debt in the old on-premise world
What some don’t realize is that ISVs also have to pay their technology debt. They may be using embedded software from a 3rd party that is no longer supported. Their code base may be running on an older version of the programming language. They may need to support newer versions of systems used by their customers. ISVs are certainly not free of the technology debt.
In the old on-premise world, when your ISV upgraded its product or released a new version and stopped supporting the older version, you had to pay the debt. It immediately becomes your debt and your responsibility to pay it, regardless of whether or not you budgeted or planned for it. Yes, the vendors you use can dictate your work plan and resource allocation in ways you may not imagine!
SaaS vendors pay the debt on your behalf
In the SaaS era, the vendor pays the debt too, but in most cases it will be transparent to the customer. It will not require any customer to allocate resources and spend any time on testing the latest release. Other than possibly a short downtime for maintenance (counted in minutes), there will be zero impact on any customer. When a SaaS vendor pays its debt (and they all do), the customer benefits substantially.
At Samanage we recently completed a major infrastructure upgrade. We moved our application from Rails 2 to Rails 3 (Rails is the framework we use at Samanage). The migration involved reviewing each and every line of code, making required changes and then testing, re-testing, and testing again to make sure everything works as designed. Our goal was to ensure that we did not impact our customers.
It was the biggest infrastructure project we have ever completed and we had to do it because the Rails 2 support model had changed. But more importantly, all the great stuff we will be building for our customers is based on Rails 3 architecture. We have spent the last 6 months working on the project and it will allow us to innovate much faster than we previously did. And the impact to our customers? None — that is, no negative impact. But, our customers will benefit greatly as we roll out new features. We paid the debt on behalf of our customers.
Next time you upgrade your on-premise infrastructure, consider the technology debt you’re forced to accrue, and whether there is a SaaS alternative that will free you from the grip of the technology debt.