Build or Buy? This is the question every CTO has to face at some point. Do you opt to use IaaS or PaaS, do you opt to build your own pipeline or buy an off the shelf platform? Most CTOs will pick a lane and go all in, but I think that’s a mistake and a missed opportunity.
There are risks and tradeoffs involved when you choose a single lane and the smart CTOs know it. Think of it like this, you’re not a CTO but the head engineer of a race team. Do you choose to focus all of your attention on just the engine? Of course not, you tune the whole car, working on the engine, the steering and the suspension.
Now imagine you’re tuning your architecture, the smart CTOs are focusing on every layer available to them, not just going all in on IaaS.
As a CTO you have access to a lot of tools spread across the three different layers of architecture, SaaS, PaaS and IaaS. It’s important to remember, these layers aren’t competitors, they’re complementary, the goal isn’t to choose the right layer, it’s to know when to use the right one.
SaaS, this is the layer that provides you with commodity capabilities, the things that everyone does, HR, ERP, CRM, etc. There’s not much opportunity to differentiate in this layer, but it can deliver efficiencies that help become a cost leader. Don’t build what you can buy, save your budget for differentiation.
PaaS, these are the platforms that allow you to start to create the things that make your organisation unique and help you differentiate. These platforms do the heavy lifting for you by providing an opinionated, repeatable way of doing things. They let your developers focus on creating value without having to reinvent the wheel. PaaS is great for rapidly building prototypes, MVPs, or projects where you need to prove value fast.
IaaS, this is the layer you use when control matters most if you’re building something unique, have a complex problem, high volumes of data or need massive global scale. This is the layer that gives you maximum control but maximum responsibility. However, complexity and control have a cost overhead.
I have seen over many years CTOs who have chosen to go all-in on a hyperscaler. Organisations start off with a clean pipeline but over time it becomes a sprawling mess, with complex network configuration, virtual machines, build processes and YAML files that confuse developers.
At the start CTOs may look at PaaS pricing as a premium tax they’re not willing to pay. CTOs will choose the DIY path because it gives them more control over components, leading to a belief that decoupling makes cost control easier when compared to a PaaS.
However, those choosing to build their own pipelines over time, unknowingly accrue a DIY tax. The complexity eventually starts to creep and so does the cost, in money and headcount, with DevOps teams growing steadily. Organisations risk hitting a point where the benefits of building your own DevOps pipeline are outweighed by complexity and cost, that start to slow down the rate of delivery and stall innovation, and at the same time your competitors start to ship faster than you.
To overcome the risk of over engineering in a single layer you need to think more like an Enterprise Architect and assess each layer on its own merits, it’s all about using the right tool, for the right job, at the right time. Enterprise Architects don’t think like engineers, they think about what’s right for the organisation at that point in time, for them it’s not about choosing a layer, it’s about aligning technology with strategy, goals and value to ensure the organisation is more likely to get value from their IT investments.
A handy framework for deciding which layer to use involves thinking like an Enterprise Architect without the need to become one. When choosing a layer ask yourself:
- How well does this align with my organisation’s goals and objectives? Does this create value, an advantage or is it just infrastructure for the sake of it?
- Do we know the total cost of what we’re about to take on? Does the additional expense make this a sensible decision or does it erode value?
- Apply the 80/20 rule, can this get me 80% of the way there with 20% of the effort? Or, inversely, does 80% of the effort only solve 20% of the problem?
- Can I achieve something by spreading myself across multiple layers, can I get the best by combining no/low code SaaS, with speedy PaaS and dip into IaaS when I really need to?
The best CTOs choose not to invest in a single layer, they’re picking the right tool for the job and keep revisiting those decisions as the organisation changes and grows. That’s the key point to remember, going all-in on a single layer early on reduces agility in the long run, it’s better to spread your bets, use the best of what’s on offer and go deep when it makes sense. Don’t forget a well-tuned car performs better than one with a monster engine, the same applies to your architecture.
Top comments (0)