Cloud is not a technology, it is a new operating model
The greatest opportunity for the cloud is not the set of technologies that you no longer have to manage, but the fundamental change that you can apply to your operating model. Unfortunately, a lot of cloud adoption is applying a traditional centralized ICT model, where the greatest opportunity is to federate technology innovation to the business.
Traditionally delivering complex software product / projects in house has required a large number of teams. The number of teams involved requires an enormous number of meetings and dramatically increases the overall project risk, and can slow down delivery by an order of magnitude or more. Some real examples that should resonate with executives
- The hardware requirements for the project exceed the current capacity requiring a facilities upgrade, design and procurement.
With no company policy on how to amortise the step up in capacity the project is landed with the full cost of the facilities / hardware. Project delay 3-6 months, with enormous waste in meetings and lost productivity;
- The network is designed with security assuming high blast radius, as it is housing 100’s of applications.
The project is not isolated and the automated build tools and other required services need to undergo a network design and review, require firewall and proxy rule changes and are subject to slow change control. This is all required in my view as the blast radius is massive, it does however result in months of additional delays, reviews and meetings;
- The product is delivering APIs that will be exposed to external vendors
and this requires involving the Enterprise Application Integration team, the people that run the heavily controlled middleware. As this team is in the middle of everything, with best intentions, the project is held to their timeframes and they don’t have automated tools to deliver and end to end deployment. This results in a lot of time explaining the API’s and the design, with no tangible benefit, and a reduction in quality and speed a few months.
The list is truly endless, as soon as you have a centralised capability with separate teams, there is inherently going to be a non trivial increase in your software delivery costs.
DevOps and agile tries to solve the silo’d team problems in software, however the problem is in the operation model itself and the real way to solve it is to give the power back to the project / product team to deliver their solution with everything in their control.
Current Target Operation Model for delivering software
The above diagram shows a typical organisation that we see, even after adopting cloud (minus facilities and storage), where there are centralised teams that manage the various services and capabilities. Contention quickly escalates and the number of people involved in delivering the end to end solution increases, increasing the distance from the people you are building the software for in the first place, the business! This model was a requirement of old, where heavy investment in standing up the capability was required and due to the cost it made sense to only ever stand up a single instance.
Negligible Cost Of Provisioning
This has changed, with the introduction of PaaS and SaaS, the cost of provisioning additional instances is negligible. In a true usage cloud PaaS, having one or one hundred instances of a service will make no difference to your underlying cost.
To deliver your project fast, provision separate PaaS instances, for example a separate database, service bus, api gateway and cognitive services instance. If your organisation has standards, and even better automation templates, then use them to ensure consistency of design and configuration. If they don’t then pave the way forward for your organisation.
Cloud enabled Target Operation Model for delivering software
The Product Team Has Control
The key with the above is that everything is in control of the Product team, there are far fewer people to engage with and far less risk associated with intermediaries. The Cloud team must provide a service to the Product team and in fact learns from the Product teams, then feeds that into automation scrips, policy and standards to make the delivery of the next product faster and of a higher quality.
The operating model is radically changed from teams centred around capabilities, to an empowered and federated team that uses high levels of automation, with an expert cloud team that assists the product teams to deliver their products with respect to cost, consistency, security and tool-sets.
Importantly if the Cloud team does not have experience in a service or can’t keep up, they need to leverage the Product teams to help build out the best practice for the organsiation.
Having worked under both models, I have seen the enormous benefit of implementing the second operating model, and even though sometimes the first Product team will have to suffer some additional cost in understanding and designing a new solution, it is more than offset by having most of the delivery under your control.
Unfortunately not all cloud providers are created equal as some PaaS instances have a tiered approach rather than a purely usage based, this is especially the case for higher security models when you need isolation of the PaaS service. This requires careful consideration, often requiring a hub and spoke model or clever automation pipelines, that will centralise some services and federate as many as possible.
The Cloud can facilitate a transformative change to your Operating Model to deliver software and services and while it is easier to replicate your current Operating Model, that will not deliver realisation the benefits you have been promised.