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:
- Some of the companies are public and must continuously roll out new versions and features that goose revenues and profits to keep shareholders happy.
- Others have been or are about to be acquired, and programmers are laid off to make the numbers look better, which causes the company to lose legacy knowledge as well as the programming skills to address technical debt.
- Still others are in fierce competitive wars with other vendors and know that shiny new features sell, and assume they can get to addressing technical debt later.
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.
How Did We Get Here?
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.
Ways to Identify Technical Debt
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:
- Is the software built on a contemporary object model? Ask them for a review of their major object classes and how they are related. If you don’t have the knowledge, make sure you have someone with you who thoroughly understands object models. If all the vendor shows you is the physical design of relational database tables, you may be looking at very old thinking and programming.
- Is the software systematically effective-dated?
- Are all the business rules that drive the software abstracted to effective-dated metadata? Can their metadata be configured non-destructively? Are there any business rules expressed as application code?
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.
