Talented IT teams regularly beat themselves up over technical debt and have built comprehensive plans to effectively manage and minimize its effects. Prodded by Larry Dignan in a recent post, just for today, take a break and instead look at the technical debt practices of enterprise software vendors.
You would think that with their huge teams, the large enterprise vendors would have wrestled technical debt to the ground a long time ago. You would be wrong.
There are several reasons why large software vendors often have technical debt issues as severe or worse than their small vendor/application counterparts. Among these:
Yet the technical debt buried within these applications can be a ticking time bomb. The more debt in place, the less likely you, as part of an IT team, will receive those amazing benefits the enterprise software vendor promised. Technical debt is one reason why being a late adopter isn’t always the best move: you get the downside of the accumulated technical debt, without the upside of the initial software innovation.
Another concern about technical debt inside enterprise software is the drag on the vendor’s future innovation. As technical debt increases, it reduces software quality and functionality, and forces the enterprise development team to focus resources on fixing the debt, which translates to higher prices.
Much enterprise software was designed in a different era, when it ran on mainframes, developers didn’t have to think about mobile apps, people working remotely and running it on today’s much smaller servers. Software viruses were few and far between. Competition came from a few, easily identifiable vendors. And, much of the software was built on traditional code, such as COBOL. The attitude of software designers was to build in every feature imaginable and let users decide what they want.
Today, much of the code developed in that early era is still recognizable. If you examine the guts of today’s enterprise software, you can often recognize that “kitchen sink” mentality. If you are considering the purchase or subscription of “new” enterprise software, it would pay to look under the hood of how that code was constructed.
To identify serious technical debt issues in the design of the software (finding technical coding debt is much more tricky), here are three questions to ask the vendor:
To be fair, any enterprise vendor who has been in business for more than a few years will have some technical debt. You should ask how quickly and effectively their team is working to manage and minimize technical debt.
While it’s somewhat comforting to know that even huge software vendors struggle with technical debt, it’s critical that you get a handle on their technical debt issues as part of your strategy to handle your own.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.