It’s 2 a.m. the night before you, the CTO (chief technology officer), promised to push a new release of your mission-critical application. Notices have already been distributed to all your employees and clients letting them know tomorrow will be the big day. That key piece of functionality all your big clients asked for will be live, and life as you know it will change for the better.
You sit in your office with that harsh glow of fluorescent light drying out your eyes and making you long for sleep. A team of five developers and QA resources are frantically working outside your office trying to tackle a last-minute bug – something you expected to be done three days ago. Why is everything going wrong? Why are you still here at 2 a.m.? Why has this application become so onerous to maintain?
As a technology architect working in the world of IT due diligence, I am often approached by a target company’s CTO with the idea that they are building the “Next Gen platform” for their company. Typically, I am presented with pretty charts and graphs about how they need the latest and greatest architectures, how the future of the planet depends on them ditching an older MVC stack for something awesome, like serverless tech running on AWS Lambda—or that their Cobol revenue management system is just so old only cavemen could work on it. Part of my job is to assess if their plans are legitimate and that building from ground up is the best solution—or is there another way to go? Before looking at their future plans, I need to assess where they are now and where they need to be.
The first real indicator that a Next Gen platform is on your horizon is your workload balance. In an ideal world, 100% of your time is devoted to new features and improvements. How many of us work in an ideal world with 100% new feature development … raise your hands! If you raised your hand then you either have the greatest application in the world or skyrocketing technical debt that will eventually crush all your hopes and dreams.
Most strong development shops dedicate between 10% and 20% of their time to support, maintenance, and technical debt remediation. This range, to me, is acceptable. More than 20% of time spent on defects raises questions on how resilient the application is and how much longer it will last. Charting the percent of support and maintenance needed over time will also show if there is an increasing trend of defect management. If that value is slowly climbing, you may eventually need to consider rebuilding from the ground up.
More than 20% time spent on defects starts to question how resilient the application is and how much longer it will last.
Businesses that never adapt to a changing world become irrelevant quickly. A great example of this is the railroad industry of the late 1800s. So complacent in their position as the transportation leader for both people and goods, little effort was spent modernizing. Track construction dwindled, and little was invested into faster, more efficient engines. With the invention of the automobile and the Eisenhower highway system, trains lost their place as the king of transportation when cars and trucks could reach almost every point in the country with speed and precision.
So, what does this mean for you? It means you cannot just sit there relying on an application built for one purpose while your business needs to meet other, more pressing purposes. We understand that your current application, built five or 10 years ago, was built for specific purposes. Over that decade, the business decided to change directions, launch new products, find new areas for revenue optimization, etc. You and your team reacted the best you could by adding new modules to the application.
You found ways to make the existing database schema fit this new business data into an already crowded object model. As the business grew and changed, that awesome 100% test coverage goal dwindled to 80%, 70%, 50%, or lower. As you add each new piece of functionality, you keep throwing bandages over the old issues. Trying to reuse previous pieces of code, occasionally you forget how it impacts the system and release a defect to a previously functional component. This is life! This is also the signs that it might be time for a Next Gen version.
After 10 years of running a platform on the same, older tech stack, isn’t it time to freshen up with something new? Your developers keep telling you how great these modern tools are, and how they can revolutionize the development world. Saying you are ultra-modern will just make your business worth more money. You can sell for an extra 10x because your platform is top-notch.
If we were playing Jeopardy, the answer might be, “What are things a bad CTO might Say?” Building from the ground up for the sake of using modern technology is never, in and of itself, the answer. If your current application does everything your business needs and can continue to be extended for new functionality as the business grows then it does not need to be replaced. Why would you want to throw $2 million, $10 million, or more into building a new platform when the existing one is not costing you more money than a new one would? I know I wouldn’t want to have to explain to the C-suite that I just spent a large sum of money for very little return.
It’s that simple. All you need to do is a basic analysis of whether it is better for the business to keep the existing system, build a Next Gen from the ground up, or buy an off-the-shelf solution. So how do you perform a good analysis? Follow these steps:
Once you have all the details, making the right decision really comes down to two factors:
From there, it’s just a matter of looking at the big picture. In the end, the choices will either be very obvious or so close that two of the solutions could be selected. Either way you go, you have the documents to back up your decision. You are now the well-informed CTO that made a strong business decision with fact-based analysis.
From there, it’s just a matter of looking at the big picture. Your choices will either be very obvious, or so close that two of the solutions could be selected. Either way you choose, you have the documented analysis to back up your decision. You are now the well-informed CTO that made a strong business decision with fact-based analysis.