Crossing the threshold from start-up to scale-up is cause for celebration. But it also marks a new era of challenges. Issues that were previously a low priority will begin to take on a whole new significance as your planning horizons change. It’s time to take a more responsible, long-term view on business growth and development. And one item that has to move up the agenda is technical debt.
Technical debts commonly impacting scale-ups
Let’s get one thing straight. Technical debt is an inevitable consequence of progress. You’ll continue to incur it as your business grows. However, as a scale-up you need to be proactive about managing it. A deliberate and prudent approach is fine. A reckless, oblivious approach is not.
Start-ups incur a lot of technical debt. If you follow anything like the ‘build-measure-learn’ approach described by Eric Ries in The Lean Startup, you are embracing the deliberate accrual of technical debt. So, as a newly scaling business, you should be carrying rather a lot of it. All those shortcuts and temporary fixes to build and iterate minimum viable products were exactly the right thing to do at the time. But they could put a stranglehold on future growth unless you take control.
In our work with scaling businesses we see a lot of technical debt at both the software layer and the infrastructure / platform layer. Most of the good thinking and research into technical debt is focussed on the application code, but as infrastructure looks increasingly like code, many of the principles also apply at this layer.
Here are some of the most prevalent forms of technical debt we see that can restrict growth if they’re not addressed:
Research shows this is the most prevalent form of technical debt in start-ups. Small teams with relatively straightforward software usually get by with manual testing. But it becomes increasingly problematic in a scale-up scenario as teams get bigger and software grows more complex.
While testing is the most common form of technical debt in scale-ups, code quality has the highest impact on productivity. With a growing software team, this can quickly escalate into a major headache, but there are open source tools out there that will detect code smells and help you identify when to refactor.
This form of technical debt emerges as a constraint in the time-to-effectiveness for new team members. Ongoing growth exacerbates the problem, leading to design debt when existing software is poorly understood.
As infrastructure starts to look more like software, uniquely configured components that aren’t written as code or managed through source control increasingly limit optimisation of the software development lifecycle.
What does best practice look like?
Chances are, your infrastructure holds technical debt in at least one of the above areas, and more besides. Clearly you can’t pay it all off at once. But you must start somewhere.
For infrastructure based in the cloud, there’s much opportunity to manage technical debt through continual improvement and modernisation. However, the rapid ongoing evolution of cloud platforms can make it difficult to figure out where to focus your efforts.
In recognition of this, some providers offer practical ways to benchmark individual systems against current, proven best practice. For instance, if you’re with AWS, a Well-Architected Review offers a straightforward way to identify and prioritise technical debt that needs to be addressed to avoid hindering growth.
Using AWS Well-Architected to master technical debt
The AWS Well-Architected Framework comprises five pillars of best practice: Operational Excellence, Security, Reliability, Performance Efficiency and Cost Optimisation. Reviewing your infrastructure in relation to these enables rapid identification and prioritisation of issues that need attention.
A Well-Architected Review isn’t like an audit where someone comes in to point out what you’ve ‘done wrong’. It’s a constructive, collaborative process that helps improve your architecture over time. Outputs include practical, pragmatic measures that can be implemented relatively quickly to improve AWS workloads.
Identifying your workloads
In the Well-Architected Framework, AWS defines a workload as:
…a set of components that deliver business value…Examples of workloads are marketing websites, ecommerce websites, the backend for a mobile app, analytic platforms, etc. Workloads vary in their level of architectural complexity. They can be simple, such as a static website, or complex, such as microservices architectures with multiple data stores and many components.
Our experience conducting Well-Architected Reviews for scale-ups shows that it’s common for multiple workloads to be laden with technical debt. Prioritising those closest to the core value stream, then improving their operability, stability and functionality, can have a noteworthy impact on business performance.
Once a target workload has been identified, it’s interrogated with up to 46 set questions spanning the five Well-Architected pillars. This ensures fundamental areas are considered directly and objectively, such as ‘How do you manage credentials and authentication?’ and ‘How do you monitor usage and cost?’.
You only need to focus on questions that are relevant to the workload in hand, or alternatively you can address one pillar at a time. It’s a methodical process that works effectively and efficiently to reveal the scope and scale of technical debt as well as other performance issues.
When a Well-Architected Review is conducted by an experienced cloud architect, it can underpin a targeted plan with a backlog of actions to improve the workload. Any instances of technical debt representing an immediate vulnerability or threatening future performance will be prioritised accordingly.
Improvement is a journey, not a destination
It’s important to understand that a Well-Architected Review isn’t a one-time job. Nor will technical debt ever be entirely eradicated. As new cloud services emerge, evolve and mature so does the current understanding of best practice. And as your business scales, new forms of technical debt will be incurred.
This has always been the way in IT. But today’s fast pace of change and innovation, both in business and the cloud environment, mean it’s vital to review workloads regularly.
A Well-Architected Review is more than a technical exercise. In the digital-first world, iterative improvement is essential. Technical debt needs to be managed intelligently. And a scaling business must deliver value quickly while remaining secure. When developers and operations staff have the freedom to work on new features and improvements instead of fighting fires, the sky’s the limit.