Status quo is not an option - overcome technical debt to spur innovation

Profile picture for user Sebastian Grady By Sebastian Grady March 10, 2020
Summary:
Technical debt often holds back innovation, and following the vendor's upgrade roadmap isn't always the best solution says Rimini Street's Sebastian Grady

Hands break chains of technical debt with bright clouds © Merydolla - shutterstock

In today’s increasingly digital economy, competition is intense. Sticking with current business models and technology will result in many enterprises getting run over by competitors. Status quo is not an option. Yet, the cost of technical debt, created by past technology decisions, creates a barrier to growth and innovation. How do CIOs and CFOs turn technical debt on its head and free up funds to drive innovation?

Technology change is increasing, but the cost is high

Enterprises are being challenged to change more quickly and more frequently. A recent Deloitte survey showed that customer expectations continue to increase. Enterprises feel they must adopt new technologies and new business models in order to meet these expectations and to grow and remain competitive. A new connected world of customer experience is causing companies to reinvent themselves.

Most innovation is not cheap. Making digital investments to support innovation can create significant budget challenges. CIOs often spend as much as 90% of their IT budget for ongoing operations and enhancements, leaving as little as 10% of the budget for investments in new technologies and innovations that support C-level goals of competitive advantage and growth. Such a budget model is no longer sustainable.

Technical debt complicates technology change and adds to the cost

Technical debt is a metaphor that equates software development to financial debt. It describes the short- and long-term cost of additional work required to make a solution fit for purpose. It is also used to describe the cost of “instant-relief” technology decisions that are more expensive in the long run when compared to solutions that may take longer to deploy and/or provide a better fit. Technical debt represents the costs in the existing application portfolio that may potentially be reduced in order to better balance ongoing operations and the price of new development.

Technical debt can occur with any deviation from an out-of-the-box solution, and it applies to software (code debt), hardware, and the supporting environment. Interfaces and customizations are obvious examples. Less obvious ones are forced upgrades and migrating to new product releases that may provide minimal improvements to business processes but don’t necessarily map to core strategic initiatives.

As technical debt accumulates over time, it increases a solution’s complexity, preventing enterprises from taking advantage of improved technology and adapting quickly to business changes. It can be a roadblock that causes significant and measurable negative impact on business performance. Most enterprises have at least some technical debt, but many enterprises maintain a significant amount.

How did so much technical debt accumulate with enterprise applications?

A major contributor to technical debt is software vendor policies and support models - which we refer to as “vendor-dictated roadmaps.” In our view, these are typically designed to benefit the software vendors, NOT licensees. They require customers to spend potentially millions of dollars in annual maintenance costs and updates for very little ROI.

The advice some enterprises accept from vendors is that to limit or eliminate technical debt, they need to ‘pay the vendor’s roadmap tax’ and implement all of the ‘latest and greatest’ releases. However, vendor updates are a very expensive way to attempt to pay off technical debt. Even worse, many vendor updates and upgrades actually INCREASE technical debt and don’t contribute to achieving core business initiatives. The vendors’ policies and support models can actually pose major roadblocks to innovation, growth, and competitive advantage by forcing enterprises to spend limited budget, resources, and time on projects that may not drive growth and competitive advantage.

At best, some customization might be eliminated with new functionality in an update or enhancement. At worst, it can cost big money and adds to existing technical debt. It’s like taking a loan to pay off a loan or shifting money from one credit card to another - this kind of technical debt is a potential savings area that can be cut drastically so funds can be repurposed for innovation.

Examples of roadblocks to innovation:

  • High cost for poor support – Despite paying expensive annual vendor support fees, often priced at 22% of license fees plus annual increases, customers can receive poorly rated service that is also missing critical support features, like supporting custom code.
  • End of support – Time-bound vendor software support windows can force customers to perform costly upgrades just to retain full support.
  • Little innovation – The costly annual maintenance fee paid to the vendor often doesn’t include meaningful innovation because most vendor R&D is focused on new platforms and releases.
  • Forced updates and migrations – Vendors are trying to force existing customers to migrate to their new platforms and releases, resulting in costly budget expenditures, overuse of resources and time, plus poor ROI for many customers.
  • Vendor cloud lock-in – Once significant amounts have been spent to migrate to the new platforms (often cloud-based), customers can be locked into that vendor’s existing cloud AND licensed products at costs that are multiples of current costs.
  • Vendor negotiation tactics – At times vendors attempt to convince customers into trading in vendor maintenance fees and underlying perpetual licenses for ‘cloud credits.’ This is a key reason why the use of ‘agnostic cloud providers’ (e.g. AWS, Azure, Google Cloud, etc.) can be a better option for perpetual software licenses being shifted into a cloud environment.

Collectively, none of these activities and costs are investments driven by the enterprise’s business priorities. Instead, they benefit the vendors without reducing technical debt.

The majority of technical debt often occurs below the water line

Using ERP as an example where annual maintenance is $2 million, the rule of thumb is a major upgrade will cost double your annual maintenance fees – or $4 million – and will be performed every five years. That is an annualized cost of $800,000 per year (These are the average costs compared to the maintenance payment from a survey of over 70 Rimini Street clients).

Add to this the cost of maintaining custom code. Unfortunately, if and when custom code breaks, it is not included in vendor maintenance programs. In this example, custom code costs another $600,000 per year to fix. Finally, every time there is a fix from the vendor, it is bundled in another software release, support pack or enhancement pack causing another $600,000 in unnecessary regression testing. So your real costs $2 million + $800,000 + 600,000 + $600,000 –  or $4 million per year. If all of these hidden costs were removed, it could free up many millions for innovation.

Application updates that contribute to business goals and objectives should be included in the enterprise applications roadmap. However, the cost, time and resources spent on a vendor-dictated upgrade, extension, reimplementation, or consolidation can actually increase technical debt via opportunity cost.

Existing technical debt can be overcome to ease technology change

A potentially high-impact method to reduce the impact of change and shift the operations-to-innovation investment imbalance is to reduce the amount of technical debt attached to current enterprise applications. Using the example above, a good chunk of technical debt could be eliminated by removing an application’s “below the water line” costs. Look to other application areas for additional savings. Using Gartner’s Taxonomy of Technical Debt as a primer, technical debt can occur in several application areas:

  • Reliability
  • Usability
  • Performance Efficiency
  • Maintainability
  • Portability
  • Security
  • Compatibility

Using Performance Efficiency as an example, technical debt would occur if the plan was to support 2,000 concurrent users on six servers, but when the project was completed it took twenty servers. An example in the area of Maintainability is a high number of customizations, each of which may need to be analyzed and retested every time a change is applied to the core system. Examining each of these application areas can determine how much technical debt exists, to what extent the debt hinders change or has high ongoing costs, and where it may be possible to reduce or eliminate the debt altogether.

Another route to overcoming technical debit and enabling an agile business is by adopting a unified support model. Such a model integrates ongoing operations and support to help optimize services for bundled and best-of-breed applications. An integrated service model also improves ERP application management outcomes. And, it supports modernization efforts that can extend the life and value of enterprise software through public cloud and via systems that engage with customers and users (an example of this is integrating ERP with best of breed cloud applications such as Salesforce and Workday).

In summary

The typical IT budget can be moved from 90% spent keeping the lights on and leaving 10% going to innovation to as much as 40% going to innovation. But this requires making a choice.

The old choice is to stay on a vendor-dictated roadmap, continuing to invest in undesired, forced updates, upgrades and migrations that are designed to meet the vendor’s needs, and which deliver limited ROI. Instead, CIOs should choose to:

  • Increase control over the IT strategy by choosing a business-driven roadmap designed around the objectives of the business, not the vendor’s. Leverage vendor software and solutions, but do it on your terms, on your timetable, and with the flexibility that eliminates technical debt and provides the funding and freedom to focus on initiatives that support growth and competitive advantage.

  • Focus on innovations that will help the business compete and grow. Invest where the outcome increases revenue, cuts costs, or garners market share from competitors. Massive upgrades or “rip and replace” implementations of ERP don’t generally achieve this. Most enterprises should keep their ERP system in place and innovate around the edges with new solutions coming from the new software leaders.

  • Modernize existing core enterprise applications (such as ERP) to increase their ability to adapt and to enable IT to change them more quickly. Eliminating upgrade and migration costs will allow for earmarking that part of the IT budget to innovation.

  • Minimize technical debt by deploying cloud-based applications and delivery models that innovate around the edges of core applications like ERP.

With a 2025 (or sooner) end of full support scheduled for many Oracle releases (or 2027 end of mainstream maintenance support in the case of SAP’s flagship product ECC6), plus a new IT mission for many CIOs – to drive growth and competitive advantage – now is the time to choose which path to pursue for the next five, ten, or more years, a path to eliminate as much technical debt as possible.