How to Clean Up Your Tech Debt
I love to work with fast-growing companies. There’s just one aspect that can pose a challenge: the massive tech debt created from mergers and acquisitions. It’s common for larger companies to purchase small companies; It happens every day and it’s one of the more pragmatic ways to keep relevant.
So what do you do when you roll into the CTO or CIO position to find that your predecessor over the last seven years never really had a technical strategy for the company’s M&A activity?
The two options commonly considered are:
Option #1: Do nothing. Just leave it all as it is and don’t touch a thing.
Option #2: Standardize and convert all systems to one common platform.
A couple of assumptions to start with.
We can all agree that supporting one OS, one DB, one programming language, one IDE is easier than supporting several. Some companies even create standardization as a strategy for competitive advantage. Just look at Southwest Airlines: The company standardized on a single plan model, which radically simplified its purchasing and maintenance approach and reduced costs significantly.
Customers don’t care what technology is under the hood as long as it serves them well.
Systems don’t last forever, especially if you are in a rapidly evolving industry. Shelf-life is typically measured in years, not decades.
Fully converting a complex tech stack (OS, DB, coding language, etc.) could easily take a year.
Although tech standardization is immensely desirable to a tech team, it doesn’t drive much business value. System conversions typically just try to achieve feature parity, which usually is never fully achieved.
You won’t have requirements to go off of for a system rebuild. Not in today’s climate. Even if you’re lucky enough to have something written down, it’s probably out of date.
Let’s say we go with Option #1: You’re in a new position after several mergers without a solid technical strategy, but you decide to sit on the existing stack. What will happen? Costs will get more expensive over time and making changes will become exceedingly risky as the technology ages.
If you choose Option #2 and take action, it may take over a year to convert each system. If you have several systems to convert, it would takes years--if not longer. You’ll get systems streamlined, but there won’t be any new business values delivered during conversion.
The good news? There’s an Option #3 which can be combined with Martin Fowler’s Strangler Method for Converting Systems. Fowler’s approach for a single system works, but you must think at a higher level when converting multiple systems.
Option #3: Start with the outside and work your way in.
Determine what central IT needs to understand in order to support all the existing systems. Start with a common logging, monitoring and reporting platform for all the systems. You can then work your way into each system based on predetermined rubrics. If a system runs efficiently and isn’t going to be modified, leave it alone. If a system is being heavily modified or is having constant issues, use Fowler’s approach to modify it over time.
There are numerous advantages to this method, including:
Your IT team will have a better view of all systems and can use data to determine what systems are candidates for rewrites.
Business value will be obtained almost immediately, instead of in months or years. I have witnessed this first hand--and it is a tech-miracle. I worked with a company that installed a common monitoring platform (Loggly, in this case) for the whole organization. It literally found and fixed a bug that was plaguing them for years within the first week.
It’s much less risky. Installing global monitoring and logging will take a fraction of the time, and if done correctly, will have little impact on the running system. You have to assume, however, that at least some of these tech stacks are going to be very fragile. This is one reason why I prefer to use offsite systems for logging and monitoring. With offsite systems you don’t have issues like log files filling up local disk packs.
It allows more people, including non-technical folks, to participate in understanding the data. There is a fundamental difference between a global system monitor in the lunchroom (which everyone can see at all times) and logging into dozen of computers across different systems to view disparate data.
The gathered data will help inform future decisions which will remove some of the emotion from a difficult situation.
If you’re in this scenario that many tech leaders are facing, consider starting on the outside and working your way in. It will provide immediate results, you’ll get the entire team involved and it’s a less risky way to revamp your technical strategy after M&A activity.