Why this book?

Simon Oliver Sinek is a British-born American author and inspirational speaker. He is the author of five books, including Start With Why and The Infinite Game. Let’s follow Simon Sinek’s advice and Start with Why. Every organization’s “why to use the cloud” could be subtly different. However, there are common ones such as CapEx, OpEx, or risk reduction, as well as faster time to market. Getting the desired return on investment (ROI) out of moving to the public cloud is not as easy as it looked when the hyperscalers sales team did their presentations. We are not going to cite percentages here, such as “X% of all cloud migrations fail.” First, we don’t have a consistent and overarching definition of “failure,” nor a specific one for each case. Second, every “failing” initiative has brought learnings with it. And third, we need to appreciate these first movers because we benefit from their learnings. However, research suggests that a significant number of cloud migrations do not go as smoothly as initially anticipated.

The reasons for limited cloud success can vary from organization to organization. Here are some examples:

• Unclear direction-setting attempts like ‘cloud first’ left teams unsure of their future or what to do.
• Moving to the Cloud is mistaken for innovation.
• Goals to move large amounts of applications to the public cloud in an established enterprise without significant change management are not realistic.
• Companies experienced massive margin pressure because the cost of existing infrastructure didn’t disappear as quickly as anticipated.
• Operational expenditure (OpEx) and bill shock from the hyperscalers occurred due to the use of popular high double-digit gross-margin cloud services (compared to single-digit gross margins for owned hardware).
• Lift and shift shortcuts do not leverage Cloud on-demand scale-out/in features and, as a result, do not lead to the desired business demand-aligned pricing.
• Data mobility needs and associated egress costs were not taken into account.
• Marketing metrics driving wrong behaviors: “30 apps in 30 days” slogans sound good; however, the objectives were wrongly focused on the number of applications moved to the cloud instead of creating and deploying cloud-ready, cloud-optimized, and cloud-native applications that generate a return on investment (ROI).
• Seeing the public cloud as the ultimate target state: Shortcomings of architecting for an edge-inclusive distributed future led to low-ROI efforts of moving non-fit workloads to a public cloud environment.
• Unrealistic expectations leading to unrealistic timelines: For organizations with hundreds or thousands of applications, it is unrealistic to expect to move quickly, assuming application refactoring will happen simultaneously across hundreds of applications that can be worked on at the same time.
• Focus on technology instead of transitioning people, processes, and culture to enable cloud-ROI through microservices, containers, DevSecOps, GitOps, Agile delivery, and self-service.
• Data sovereignty, residency, and data concentration risk need mitigation through resilient architectures, which increase efforts and timelines.
• New cybersecurity threat vectors - the need for a consistent security posture across heterogeneous infrastructure footprints is more complex than traditional perimeter-based security.
• Multiple proprietary public cloud implementations required reinventing the wheel and offered little reuse.
• Even DIY private cloud builds, where the team had intrinsic business knowledge but followed a ‘build it and they will come’ approach, had limited success with adoption.

The main root cause of these challenges often lies within “organic – just do it” cloud journeys and the fact that these journeys didn’t start with an “operating model first” approach. Now, if we take all of these challenges and add edge computing to them, the chances of success become even less likely. The added number of edge locations, hardware, platforms, deployments, applications, data, and security requirements amplify the complexity. This shows what edge computing can potentially bring in terms of these challenges – it calls for a different, less fanboy (and girl!)-ish approach. And that’s why we recommend an operating model first approach.

The recommendation is to not start with logos that we want on our CVs, or our love for technology – not even a specific use case. We must start with the operating model. Even though operating models don’t last forever, they are usually longer lived than strategies and hence a good fit to use as an anchor. Operating models – if done well – are the glue between a company’s strategy and the people that make this strategy come alive during its execution.