If you’re a CIO or CTO in 2017 this is going to sound like an all too familiar scenario:
…Your department is doing pretty well, you haven’t had many production incidents and delivery is more or less on target
…Team mavericks say they can ‘roll their own’ private cloud yet have uncovered a low-level issue they can fix ‘soon’. You just want to know how long it will take and how many dollars it will burn
…A constant stream of vendors promise utopia, while incumbents say you are under-utilising them. You’re not sure they are worth what you pay them now, let alone getting further into bed with them
…Your CMO/CRO is predicting a big upturn in sales and the CEO is showing a growing interest in what technology can do for the business, which means more questions like ‘What’s your opinion on digital? What’s your cloud strategy? What’s your platform strategy? What could machine learning or AI do for us?’
…Meanwhile, the CFO is demanding answers on the public cloud Total Cost of Ownership (TCO) — ‘Weren’t we meant to be saving money?’
You’re stuck right in the middle of all this - trying to balance stakeholder expectations with reality, while keeping up with an industry landscape that is moving at a rapidly increasing pace.
Navigating all the options and understanding what’s best for your business is a full-time job in itself. Do you save on licence costs and go down the open source software (OSS) path? What happens when your guys can’t fix or enhance it? Will the OSS community really be able to help you in a reasonable timeframe for your business? What about commercial off the shelf (COTS) software options?
This is what happens when you have an incomplete, missing or just plain not fit-for-purpose platform strategy. Defining a good platform strategy can answer most of the questions above, and give you a head start on the rest.
Here’s what that looks like. A good Digital Platform Strategy (DPS) must support five key business outcomes: Deliver faster, experiment responsibly, build an ecosystem, gain insights and provide a consistent experience.
Deliver faster is at the top of the list for an important reason. Thanks to the State of DevOps Report we have independent proof that having a high performing software engineer capability means you are more likely to have a high performing business.
During my own experience running a platform team, our mantra was ‘slow is smooth, smooth is fast’, and that pretty much defined how we approached speed and predictability.
Predictability so I could communicate with, and deliver to, my customers — and predictability so my team understood the expectations and could measure, and be measured, against them. If you don’t know where to start, just look at the decisions you need to make to ensure a more predictable business outcome.
Let’s unpack the elements of predictability in a technology sense:
• How capable is your team?
— Have they built (with vendors/partner help) a private cloud?
— Do you have a DevOps culture?
— Do you use CD pipelines widely/partially/not at all?
• How quickly does your business want to move?
— What is your release cadence?
• How mature does the offering you choose need to be?
— How capable is your team? (if your team is less capable you’ll want to make a software choice that does more heavy lifting for you, but is typically more tightly coupled and expensive)
— What support model does your business need
— What is your aspirational Mean Time To Recovery in the event of a failure?
— Do you expect to get access to high quality development resources from a vendor to help you progress quickly?
From a software delivery point of view, if you are not employing Continuous Delivery then you don’t have real predictability, it’s as simple as that.
Every environment is unique, and while I can’t speak for them all, I can point to one of my own experiences.
We had hybrid cloud with older elements on-premise in one of our older costly and less efficient data centres, and newer micro-service based elements in Amazon Web Services (AWS).
Product stack one featured Over The Top (OTT) of IP and Subscription Video On Demand (SVOD) in AWS.
- Product stack two featured OTT Linear in a third-party data centre, which was rapidly running out of capacity. The decision was made to move it on- premise, to our latest data centre (Power Utilisation Effectiveness < 1.3).
- Product stack three was on-premise and running Docker in Production supporting about eight million searches each day.
- Product stack four was on-premise, in development as part of a ~$50 million program of work creating a digital channel for an underlying business platform
Product stacks one and two served SVOD and Linear, respectively, and video 24x7, so any degradation needed explaining to the product owner. Ensuring buffering was kept to an absolute minimum was critical. Both product stacks had a very aggressive product roadmap, and one had a very aggressive user growth plan >300%.
Each stack had a different platform but the same hardware (other than the elements in AWS). Above that, each looked quite different. There were a few different flavours of hypervisor, NoSQL, building and configuration tools etc. It was the classic ‘start quickly and use what you want’ environment, and it was very clear that having a platform strategy was key to establishing predictability, and therefore success.
Many would argue that a vertically integrated digital ‘ecosystem’ was the way to go – and a long list of vendors would agree. But, no vendor can ‘sell’ you your platform – in the same way you can’t ‘buy’ differentiation. If you truly want to differentiate yourself, you must build your own platform.
After establishing what our Retiring, Running and Emerging/New categories were, we set about confirming where we were and what we wanted for the future, which had to be as simple as possible, with as few choices as possible. We knew that ensuring commonality across our platform was key to our predictability, as it allowed us to ensure our ‘pool’ of people who knew the detail of our platform was quite large and allowed us to have a leveraged engineer to server ratio.
Developer ergonomics/experience was also something incredibly important to us so our platform had to integrate well internally to reduce friction as far as possible. Most critically, this platform for the future suited our unique circumstances and gave our business that all important predictability.
Andy McQuarrie is technical principal at ThoughtWorks.