The idea of scalability for software platforms is often misunderstood. Scalability means different things to the engineering team and to software developers who are responsible for building and maintaining the platform. However, software company CEOs should define scalability as:
The ability of a platform to maintain its stability and consistent level of performance as the load continues to increase.
As the demands on a platform increase – with the accumulation of data, more customers or users onboarded, or more features and integrations – there shouldn’t be a disruption of service. Stability must always be maintained. Through a business lens for a software company, scalability means your technology has the foundation to support your desired rate of growth. A platform that limits growth rate can kill a company.
Let’s look at a few key situations when designing a platform for scalability can drive make-or-break results for software companies.
1. Scalability and software modernization: Don’t throw out the baby with the bathwater
One of the biggest misunderstandings around scalability emerges when software companies embark on a software modernization project. It’s important to modernize your platform in a scalable way – but that rarely means “rewriting the whole thing.”
If your company is looking to modernize a software platform, that usually means you have an older legacy product or platform that has been successful. Customers are paying money for it.
There’s an adage: “Software is never done.” That can be interpreted in a few different ways. It’s important to make sure your product or platform is consistently maintained – it has to remain relevant in the market and deliver value to customers. But as you build a successful software business and start to expand it you need to get a good return on the investments you’ve already made in your product – while carefully managing the risks. That’s the business driver behind modernization.
Before you start a modernization project, ask yourself:
- What is the alternative?
- What if we don’t modernize?
- What if we don’t keep a legacy product relevant and current?
The customer demand for value will keep going up. If you can’t keep up with that demand, you could fall behind the competition. This means you start losing revenue and end up with attrition.
When starting a modernization project, make sure you understand why you’re doing it. You should focus on:
- Maintaining stability and scalability
- Delivering more and more value to your customer base
Have customers been asking for new capabilities and features, and you’re not able to deliver because your technology platform is holding you back? That’s a sign you need to modernize. But if this goes too far, software teams will end up saying, “The product is too old, and we just need to rewrite it.”
I was in a discussion with a software company that had a successful legacy product that had huge market share and was highly sticky; it made up 90% of their recurring revenue. But the product was getting old.
The company leaders raised the question, “Should we end-of-life this old thing, and put our eggs in a new, modern basket?” And my answer to them, respectfully, was, “HECK NO!”
Big software modernization projects can be expensive and risky. You can spend lots of money on software development and it still might not solve your challenge with scaling up for a new level of growth. Don’t bet on a full rewrite unless you’re facing an existential threat to your technology stack (Silverlight, Windows CE, and old versions of open-source technologies like Angular or PhP come to mind).
But for most software companies, modernization projects should take an incremental approach. Don’t throw out the baby with the bathwater. You’ve invested a lot of capital in building this legacy software product. And the product is successful; it’s still generating cash. So instead of taking on the risks and costs of a full rewrite, pivot to building new features and capabilities on a modern technology stack that integrates with your legacy product, while reducing the amount of new code you write in your existing legacy product.
Some amount of ongoing maintenance of this legacy product will always be required to maintain its stability and core functions, but this should be minimized. Don’t look at new features or customer requirements purely through a legacy lens. Focus instead on maximizing the value you can deliver to your customers overall. You most likely don’t need a Big Bang Next-Gen project to succeed.
2. Right-size your scalability for business growth (not infinity)
In software engineering, it’s easy for software teams to get tunnel-vision when looking at scalability and performance. Your engineering team might say, “we want infinite scalability!” But most software companies don’t need infinite scalability, or even elastic scalability (unless you’re in a seasonal, cyclic industry like agriculture or retail).
Why do so many software companies build levels of scalability that they likely will never need? It’s because sometimes engineering teams get too fixated on the idea of scalability as a theoretical level of perfection. They say, “We want the platform to handle any volume that we throw at it!”
But too often, they end up overengineering for levels of load that the platform will never see. And this excess scalability leads to unnecessary complexity and huge incremental operational costs. Instead of chasing after a level of perfection that you don’t need, software companies should fit the engineering to the needs of the business.
Scalability should support growth. How much more growth can you expect in the next 3 years? Is it 300%? 400%? Or maybe just 50%?
Use the business target to influence your choices for technology, architecture, cloud, infrastructure, and everything else so you can calibrate the result. Your system needs to be scalable enough for your business growth, not “infinity.”
Let’s say you’re at 1,000 users, and your target in 5 years is to be at 10,000 users. Can you design your system so that between now and 5 years, you can increase scalability by 10x? That doesn’t mean you have to re-engineer everything so you’re at 10x tomorrow.
Instead, take it incrementally. Scale it out, look at it multi-year, and find out what scale the business needs. Then calibrate the amount of engineering investment that you need to make to support that level and maybe a bit beyond it.
If you overdo the scalability – if in five years you need 10,000 users, and instead you try to engineer for 1 million users – that’s going to force you into unnecessary compromises on engineering and operational cost and complexity that will come back to haunt you. Instead, right-size the scale around the business and customer needs.
Too often, software companies don’t look at scalability through a business lens. Instead, they let engineers make all the decisions. The engineers almost always have good intentions, but they end up pursuing a level of scalability or performance that is too theoretical, and not practical. Don’t spend hundreds of hours of (expensive) engineering time trying to improve an operation’s performance by 25 milliseconds that your customers won’t even notice. There are better uses of that investment in engineering hours.
Right-sizing your scalability has to be emphasized as a priority from the top down. Software company CEOs need to keep communicating and aligning the engineering team around business targets, not just whatever problem the engineers are interested in solving right now.
3. Build reliable software platforms with physical-world engineering principles
Here’s how reliability can impact revenue: If your system is unstable or unreliable; your company is dead. Nothing is more important than stability or reliability. You lose reputation and you lose trust. That’s a major problem because trust is earned in drops and lost in buckets.
It leads to lost revenue, lost customers, and possibly the end of your business.
To maintain stability and reliability in your software platform, you need discipline throughout the engineering process. You need QA embedded in engineering for each new release. You need fundamental good practices not just with software engineering, but throughout the full life cycle of product design, construction, release and validation.
And it plugs into the infrastructure side too. The customer doesn’t care what went wrong – if it was infrastructure or security. “Our CPU load tripled!” They don’t care! It’s up to you to care about all those things. This takes fundamental discipline and experience beyond engineering or architecture.
Here’s why it’s so hard for software CEOs to get this right: most CEOs aren’t engineers (or have left the engineering decisions to the engineering team). CEOs often don’t want to know the complexities of all this stuff; they just start feeling the heat from customers, and asking people to “fix it!” But to fix it, the company needs a higher level of engineering discipline.
This isn’t the fault of the individual engineers or the leaders; they want to do a good job and they want to fix it. They often just don’t calibrate their focus on the tech, the process, or the people involved well enough to yield an overall result.
You have to be balanced about how you approach it. If someone’s just running around screaming “fix it,” you’ll have too many people trying to solve the problem from too many directions, but without a coherent, disciplined approach. The process people will say, “We’ll test quality into it!” (Note: this is not possible.) The infrastructure people will say, “I’ll throw more infrastructure at it!” But if you have a fundamentally unstable platform, none of this will be good enough.
Experience, discipline, and balance are needed at every step. And this is not a new thing. It’s operations and product engineering and product management. Think about the same disciplines you’d need in manufacturing if you were producing a new product. You’re doing a new product launch. How do you take the risk out of that? How do you make sure that your new car doesn’t have the wheels coming off? That there are no loose screws?
The same product management and product engineering approaches that are obviously needed on the hardware side are also needed when launching a software product. That will bring the right level of product management discipline that can provide balance and weigh all these issues to minimize risk and maximize ROI. Keep your software team aligned around business goals and accommodating growth, not just one well-intentioned but narrow view of theoretical perfection.
It’s easy to fall into this mindset of “software is different, software is so dynamic, we’ve gotta keep up with the hot new trends!”
Wrong! 90% of that mindset is noise and short-term fads. Instead, focus on the timeless first principles of software engineering:
- Product management
- Business-Technology alignment
- Platform Engineering
- Modular Architecture
- Quality baked into every phase of the product lifecycle
These fundamental truths will never change.