Why a keep, build, or buy analysis is crucial to every CTO’s future.
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?
Maybe it’s time for the Next Gen version.
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.
What really matters when determining if a Next Gen platform is for you: How much time are you spending on support and maintenance versus new features and enhancements?
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.
Where does the business want to go in the future, and can that be accomplished in the current application framework?
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.
But – I need a Next Gen Platform because my technology is so old!
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.
So how do you know it is really time? Perform a Keep, Build, or Buy Analysis.
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:
- Evaluate the current pain points of your existing system. What are those pain points costing in terms of additional development cost, lost revenue, lost opportunities, customer dissatisfaction, etc.? Try to put estimated dollar figures on everything to create a three- to five-year amount that can be compared with the build and buy options.
- Determine the real cost to build the Next Gen platform. Be realistic. Too often I see ground-up development initiatives that do not take into account the real effort required to build, test and migrate. Do not forget all the ancillary costs like training, customer communications, and the impact on the finance team’s reporting capabilities. Every cost factor should be included.
- Analyze the market to see if anyone has a similar application that you can buy. Maybe it will not be a perfect fit, but if someone already invented the wheel, why not build the car using their wheel? You can typically find packages that provide some of your functionality and all that is required is some work to configure or extend it. Make sure you factor in all the costs including long-term support. Also, assess the viability of the company you are buying from – will they still be there three years later to support you? Will they continue to release new features, fix bugs, and security patches?
Once you have all the details, making the right decision really comes down to two factors:
- Which of the three solutions—keep, build, or buy—provides the best financial outcome for the business? (Lowest cost for highest return.)
- Which will position the business for the best chance to continue to grow over the next three to five years?
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.