Technical Debt – the payment for success

[#1]

Naomi Bloom put out a post worth reading titled –   The Scourge of HRM Software -- Technical Debt. Technical debt is part of the long term cost of having successfully implemented projects and the reason why so much of most IT budgets is consumed by maintenance costs.

As Naomi points out: “But eventually, no matter how much good work is done to pay down that technical debt, the pace of technology and business change really does force us to stop, take out that “blank sheet of paper,” and make a leap.”

This is something to keep in mind as organizations plan their move to cloud techniques or any other large technology shift.

 That got me thinking about a webinar HP has featuring IDC, Jean Bozman, Research VP of IDC’s Enterprise Server Group, talking about the top evaluation considerations for enterprise computing—including the top characteristics for mission-critical computing platforms—all of which impact acquisition costs and operations costs. Additionally, Stuart Haden, Senior System Engineer of HP’s Business Critical Systems group, describes some of the HP server hardware to address these characteristics.

The Webinar on characteristics of mission-critical computing on December 6, 2011, at 11:00 Eastern (8:00 AM Pacific), including live Q&A sessions.

Read the IDC whitepaper: Evaluation of Mission Critical Computing Systems: Key Criteria for High-End Systems Customers

[#2]

My experience with Technical Debt has been mostly as a result of things done to “make it work” in the final stages of systems delivery.  Good teams will keep track of Technical Debt to chip away at it in subsequent releases.   The aggressive pace of change, especially for mission critical systems, contributes to Technical Debt.  Mission Critical systems are typically tested more thoroughly than systems that are not as critical.   Testing after all is a means to mitigate future risk.  More testing often finds even those one-in-a-million scenario bugs or requirement misses which when found in the later stages of delivery are patched rather than fundamentally  redesigned.

An often left out ability when describing mission critical systems is “Survivability”.  Availability is the ability for the system to continue to process pretty much the same when components fail.  Survivability is the ability to keep on working at some level even when components around it or within it have failed.   Truly mission critical systems need to continue to support their primary function in a diminished capacity when the seemingly unforeseen occurs.    The paper describing the “Evaluation of Mission-Critical Computing Systems” highlighted Modular Design which is a key enabler of Survivability.  The modular design of software systems can support survivability by providing different means of accomplishing the same tasks through different logic paths and/or components.   Thinking modular and understanding the dependencies within and between components supports Failure Mode and Effects Analysis (FMEA), and more formally planning for survivability at every level of a mission critical IT system.