Technical Debt…A Fickle Mistress

It is not uncommon for IT leadership to loose awareness of the true cost of application ownership. Financial challenges and budget constraints make easy targets out of any effort that is not delivering immediate results. As teams look at ways to become more resilient, it is important to consider what factors may have resulted in any shortcomings in terms of resiliency to begin with.

When making investments in IT, leadership should be considering the lifecycle of the investment they are making. How long should it last? What needs to be done to maximize the viability of the investment? Just like a car needs regular oil changes and tune-ups, applications, hardware and other IT investments need care and feeding to assure they able to continue to deliver what they are intended. Similarly, if these items are not given due consideration during the planning of the investment, solutions for fixing resulting issues can be much more expensive.

Much like your credit card, if you neglect regular payments or only pay the minimum due, the interest on the remainder adds to your principle and the ultimate cost of what was originally purchased becomes larger… your debt increases. In IT this is referred to as “Technical Debt”.

At one point in my IT career, I had the opportunity to play a key role in the migration of a legacy financial system to a large-scale ERP solution. At the time the trade journals were full of stories about lawsuits concerning failed ERP implementations. I remember reading about a lot of finger pointing, most of which was only to cover poor estimation of effort on behalf of the contractors engaged to manage the transition.

Although our implementation was ultimately successful, the perspective my position as a technical lead allowed me to gain insight into some of the factors that both contributed to our success as well others that limited our momentum and slowed progress.

This project was to implement a number of functional modules, each related to a corresponding area in our legacy system. Time and again the software vendor would explain the benefits of remaining as close to a vanilla, out-of-the-box implementation as possible. Although customization was facilitated by their design, they indicated that we were better off avoiding it wherever possible. This was to be our project norm going forward.

As you might guess, during requirements gathering, many areas that were previously identified as applicable to a vanilla installation, would not meet the needs of our functional areas. The out-of-the-box software that was initially a good match for our functional processes, did not quite meet the more granular aspects of what our functional people expected. What was discovered was that over time, non-standard use of the legacy system was undocumented but became accepted process. As business processes shifted, use of the system had been modified and expanded from its original conception. This use became engrained in their common work processes and was now necessary to everyday functionality. Our problem now was that we had to first invest time and resources into catching up on all of the newly needed requirements. This was a challenge because none of it was documented; it was just understood by the functional teams who were using it every day.

We also learned of many shadow systems that were created to supplement the legacy system. Integration points, data feeds to and from different systems. Over time, supplemental functionality had been pieced together that had little and sometimes no resiliency or life-cycle management.

As an example…I recall discovering that in order to close our books each month, we needed to import data from an outdated system that one of our functional areas maintained. Although it was old, it worked and because it worked, several other functional areas began piggybacking off of this system as a means of getting their work done with minimal investment. Of course, this outdated system was absolutely not compatible with the new ERP. It was written using code libraries that were not considered secure by IT Risk and were not even supported by the operating systems on our new machines. Since it was working, nobody ever considered maintaining it with patches or upgrades. After all … the business unit owning it was only concerned with the viability that it provided for their small area. Even though its use had grown beyond their group, no investment was made to bring the system to a level of resilience or compliance suitable for its expanded role.

If due attention was given based on that system’s role in the enterprise, then the organization would have made sure due diligence was done to see that system was given appropriate care. Instead, the system went unattended until an event happened that required modernization. Although costly to play catch-up with patching and upgrades, this would even have been more expensive to the organization if the triggering event was the result of some failure that prevented the system from delivering its business value.

The hard fact is that this debt must eventually be paid for. If regular payments (resiliency maintenance) are not planned or considered as a standard part of doing the business of IT, then eventually, a larger expense results. Unfortunately, this debt is very easily overlooked or considered optional when budgeting efforts or challenges are made. Payment of technical debt is too easily “leaned-out”, but eventually snowballs into greater expense down the line.

This can be a difficult lesson for application owners. Even worse is that often the lesson is learned at the expense of an application owner that was not part of the application implementation when initial budgets or resiliency models were planned.

Some IT Management Gurus look at technical debt as the result of two things… choice and level of prudence. Choice can be intentional or inadvertent. Prudence can be reckless or discerning. Here are some examples of how these play together:

Technical Debt

  • When you look at your IT budget, do you consider the future effect of your decisions with regard to resilience?
  • Is application life-cycle longevity and financial risk avoidance “baked” into your budgetary planning?
  • Are short-term savings or personal recognition more important than the exponentially larger expenses that can occur later or the overall financial well-being of the organization?

Responsible application ownership involves examination and planning for all phases within the life-cycle of their systems. It is easy to put off application vitality and resilience and often tempting because of ever existing pressure to lower expenses. Just like in your personal finances, living off of credit will add exponential overhead to your bottom line.

Advertisements

About Bob Sacca

A member of the Senior IT Leadership team for General Electric Corporate with 20 years of experience in IT management and leading Both cloud and data related initiatives. Current responsibilities include organizational migration of applications to cloud based architectures. Strategic administration of public, hybrid and internal cloud offerings for business solutions.
This entry was posted in CIO, CTO, Information Technology, Tacit IT Leadership and tagged , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s