Technical debt is a concept that's becoming popular among technology buyers. The general theme: Legacy applications can derail innovation and suck up your technology budget. Taken to its extreme technical debt could sink companies.
Although the concept may be sound perhaps it's time to turn the mirror around and look into the technical debt owed by enterprise software vendors. This question was raised by Naomi Bloom, a human resource management software expert. She just completed a tour of HRM players including Workday, SuccessFactors, Taleo, Saba and SAP.
Technical debt, which comes in both a design and a code flavor, is the build-up of outdated designs, badly written code, object model short-comings (or never-comings for those vendors whose products were designed around either the data models of an earlier era or, heaven-forbid, without formal models at all), architectural flaws, lack of support for newer delivery devices and modes, and more. This is the build-up of flaws or simply outdated work that many to most software vendors accumulate as they progress from initial product concepts through product delivery and, hopefully, through ever more product releases if they are reasonably successful. It’s the sludge at the bottom of your vendor’s software “tank,” and it’s creates a considerable drag on vendor profitability, speed to market for new functionality, operational stability and error-free updates, etc. And buyers are paying for all of this with their licenses/subscriptions/maintenance, not to mention their manual work-arounds, customizations, add-ons, duplicate systems, disengaged workforces, impossible to change business rules, etc.
Bloom's post is worth a read since the punch line goes something like this:
- Great vendors pay off their technical debts and redesign existing software.
- These vendors are few and far between because it's easier to sell new features. These features pile up.
- The best case scenario for these technical debt happy vendors is that they sell legacy software. The base case is that these software vendors are acquired and milked along with their customers. The worst case is that all this old code blows up the vendor and its customers.
In the HR market, even young companies can have technical debt because they are modeled after PeopleSoft. "When I see key design principles from PeopleSoft, which should have long since been put out to pasture, perpetuated in shiny new 2011 software, I AM NOT IMPRESSED. So you can imagine my reaction when looking under the covers of various talent management applications this year only to discover that the everything but the kitchen sink job code structure has been reincarnated," said Bloom.
In the end, customers will have to look under the hood to access a vendor's technical debt, said Bloom. Bloom recommends that IT buyers start with design debt because that's easier to spot than code debt. She advocates that customers look at whether a vendor uses a contemporary object model, is the software dated and whether business rules can be sent as metadata. Bloom was specifically talking about HRM, but the message is clear: IT buyers need refrain from falling for snazzy demos and focus on the nuts and bolts of your software.