Replacing IT technical debt with cloud functionality debt

Profile picture for user brianssommer By Brian Sommer November 18, 2015
Exchanging technical debt for functional debt in cloud scenarios is not a good idea. Here;s what you should consider.

Cloud functional debt 3
At two different vendor events this week, I heard a cloud implementer and a cloud applications vendor both discuss how too many cloud application software customers fail to activate new functionality found in the frequent, often quarterly, new releases of multi-tenant cloud application solutions. This new functionality could improve process efficiency, remove bottlenecks, enable new technology, or bring net-new applications to bear.

In the older, on-premises application world, customers often deferred upgrades as long as possible. They did so because the expense and time requirements of both IT and functional personnel were often huge while the incremental benefits of moving to the new release were often scant. Some upgrades may have required IT to acquire or update key systems software products, rewrite interfaces/integrations, re-code/re-develop custom applications, acquire additional hardware, etc. These upgrades, no matter how minor the vendor’s perceived impact to customers, were often scary nightmares to avoid until a major regulatory or other mandate forced the customer’s hand.

As more and more of these upgrades were deferred, the customer accumulated a lot of ITTD or IT Technical Debt. ITTD represents the economic and time costs associated with bringing an application to a current state. For some firms, this number is often in the millions or tens of millions of dollars. ITTD has been a major problem for users of on-premises solutions that was only made worse when the functional upgrade was preceded by a required technical upgrade.

One of the appeals of multi-tenant application software is that any lower technology stack upgrades, like to the database or security software, are the responsibility of the vendor and not the customer. Application upgrades are also handled, for the most part, by the vendor. In theory, multi-tenant applications should eliminate the ITTD problem. But, maybe this isn’t really working so well after all.

It seems that most multi-tenant, cloud application vendors, correctly, deliver newly upgraded software to their customers with new functionality turned-off. To enable the new functionality, users need to consciously activate that new functionality. But it seems a number of users aren’t doing that.

This is creating a perversion of ITTD. It’s creating Cloud Functionality Debt or CFD. This is a situation where a customer is running a new version of the cloud solution but is only using the functionality they enabled when they first implemented the software or implemented long ago.

CFD is occurring as customers:

  • Don’t have time to assess how the new functionality will change business processes, approvals, reporting, etc.
  • Don’t adequately understand the new functionality and, hence, continue to fall back on business-as-usual practices
  • Find the upgrade occurring at an inconvenient time, for example at fiscal year-end or when key staff are out on vacation
  • Are too busy tackling higher priority projects/initiatives
  • Want to be one-and-done with messing with any application software
  • Hate change
  • Have succumbed to the effects of inertia
  • Aren’t intellectually curious, imaginative or focused on continuous improvement
  • Like to immortalize older business processes instead of trying to change/improve them

Whatever the rationale, CFD is a problem for customers and vendors of multi-tenant application software.

Vendor/Implementer Perspectives

Let’s get these perspectives out now. Implementers would love to come back, again and again, to your company and 'help' you:

  • Understand the potential new functionality and capabilities ($)
  • Develop an implementation plan for same ($)
  • Devise the Process Design, New Metrics, etc. ($$)
  • Convert the data needed for the new functionality ($$)
  • Develop the change management and training required to get everyone on-board with the new capabilities ($$)
  • Configure, test, sandbox, etc. the new solutions ($$$$)
  • Anything else they can think of that will keep their people off the bench($-$$$$)

Software vendors have other expectations. They’re hopeful that you’ll love some of these new capabilities so much that you’ll add new users/subscribers to the system. They’re also hoping that when you enable some enhancements that you’ll want, or be forced, to activate some additional module(s) that expand their economic outtake from your firm.

Let’s not forget that several ecosystem partners of the vendor, like ancillary bolt-on app providers, might be needed for the full effect of new capabilities to kick-in. That could cost more money, too.

All of this creates a scenario where customers must develop a thoughtful economic assessment behind each new piece of new functionality they wish to turn on or they stand a chance of the contents of their bank account being turned over to vendors and implementers.

Customer Guidance

While the preceding section seems dismal, it often isn’t and there is good reason to hope for the future.

Some vendors understand the dilemma and are creating capabilities to help customers enable more for less. Intacct dedicated a lot of keynote discussion to this at their annual user conference. They’re beefing up their customer experience teams to help with these matters with clients.

Cloud functional debt 1

OneSource Virtual, a Dallas-based mega-implementer of Workday applications, also sees this as a major need within its customers. Not only are they prepared to help customers enable new Workday functionality, but they also bring an array of new process concepts and a portfolio of internally developed add-on apps and other technologies to improve the efficiency and effectiveness of business processes. The better vendors stress the extent to which new functionality is driven by customer feedback because while it is in their economic interests to get you adding users and functionality, that cannot be at the expense of sacrificing the trust they need to earn on a day to day basis.

Cloud functional debt 2

Software users should devise their own process for assessing the desirability, impact and cost of new capabilities in each new release of multi-tenant cloud apps. Doing so helps a firm decide, correctly, when they need to turn on or ignore new functionality. If your firm will never really need a new piece of functionality, then no CFD is being created. But, if you do need that functionality, then some assessment of the consequences of deferring its enablement must be examined. That deferral does create CFD. Great businesses monitor their CFD and act, smartly, to minimize it.

Building up a large CFD simply isn’t smart. A growing CFD is indicative of a firm whose mindset is tied to the past and is not looking towards the future. In a rapidly changing world full of fast-changing technology and fast changing business model, denial or ignorance are bad habits. As I’ve often said, “Nostalgia is Not a Strategy.”

Images via the author