Are you ready?
Change is hard. Changing an entire organization is even harder. It is made harder still when coupled with such a huge technological paradigm shift as cloud computing, which not only requires knowledge of software, networking, and cloud services but also the knowledge of high-level concepts that cloud computing brings to the forefront.
Let us share a hard truth with you: almost every organization in the world is now adopting the cloud or planning to adopt the cloud – and they are all trying to do it as a matter of course, as a thing you do and complete and get done, as a thing you do as you’ve done before. Doing that is not impossible, but the results from such a strategy are lackluster at best. Take heed and bear witness to the truths that lie herein (to quote the tales of the Horadrim from the computer game Diablo) – nothing short of revolutionary organizational change and acceptance that we are not in Kansas anymore (to quote from the Wizard of Oz) is going to suffice.
You can either accept the need for this or you can try and fight it, do what you’ve always done, and stick with your traditions of IT change management. Hopefully, it is slowly dawning on you how seriously you and your organization must take this process. For nothing is at stake here, other than the very future of your organization.
The cloud architect is the one person in an organization that needs to understand all of this. Must. Understand. All.
They must be able to convey the importance of each topic to others in the organization and will need to work with all levels in the organization to bring about the change.
In cloud computing, the top priority is to achieve the business goals of the organization. All other matters take a back seat. Focus on what really matters. And in this book, we assume that the business goals are broadly aligned to do the following:
- Deliver digital services to customers (internal and external).
- Be quick but diligent about it (agility and compliance).
- Pay for agility and acceleration but don’t break the bank (focus on agility first, but then circle back to cost optimization regularly).
- Enforce the brand and the reputation of the organization (security and sustainability).
- And lastly, have peace of mind and the time to learn new things (less firefighting, more innovation).
Your organization has decided to go all-in on the cloud. So, the buy-in, in principle at least, is there. Now, how does one transform the organization to be able to quickly and efficiently deliver on that promise in its day-to-day operation.
This book will address this challenge by showcasing the actual path to take from day zero (the decision) to strategy formation, planning, and execution, all the way down to day-to-day operation and long-term management. Anything short of total organization and technology transformation will miss all opportunities the cloud provides.
Agility: Business needs must be addressed yesterday, not in six months or two years. How does the adoption of the cloud help address this? What in the organization is preventing innovation, faster time-to-market, cost efficiency, and global scale? Not just one agile team, but repeated over and over again, at all levels and across all teams, in an orderly, organized, governed, and compliant way – without adding more bureaucracy, but rather by empowering all levels of the organization to be agile by default.
True agile adoption requires one to steer the organization not with slight and sporadic nudges but through focused radical course correction. Imagine a massive oil tanker attempting a 180-degree turn: the process is slow and appears to only make small incremental changes, but it is predictable and when it starts there is no stopping it.
This book will address this challenge by providing callouts, funny anecdotes, adoption stories from enterprise and start-up perspectives, information from running a SaaS platform in a regulated industry, ideal and cynical views, examples of what did work and what didn’t, patterns and anti-patterns, and so on.
Agility
I cannot stress this enough, and I’ve had this conversation with many CFOs, product and project managers, and even developers. To quote Donald Knuth, “premature optimization is the root of all evil.” This applies to culture as much as it does to code. Trying to optimize your practices while trying to achieve agility is lunacy – you don’t know yet what is important, or where the bottlenecks will occur.
Focusing on agility means focusing on the easiest path to production. If that means procuring more expensive services either on a higher tier or at a larger scale, do it. You do not want to waste time arguing about the sizes of VMs, App Service plans, or do we use Service Bus or Event Hub. Repeat after me: It doesn’t matter.
Remember that you are trying to develop, deploy, and deliver a digital service to customers. How do you know if it is a success or a failure? You get it out there, into the hands of your customers (again – external or internal), and you gather telemetry and feedback.
Is the service performing its business function and bringing value? Now push on and deliver more. Once you are getting diminished returns on the new features, go back and focus on optimizing the service. You may have paid for a few months of more expensive tiers and services and some of them may not have been optimal, but they were being used and the business is better for it.
The only exception to this is security: you do not compromise on security – ever.
And if the service wasn’t successful, evolve it from telemetry and feedback – or, kill it with fire. Be ruthless. You must. Or the market will be ruthless.
One practical example of this was the delivery of a COVID-19 vaccination registration and scheduling form. We did not compromise on security, but we picked the easiest (fastest, most agile) services to be able to get the form into the hands of the customers as soon as possible.
We ensured elasticity and when 5 million people accessed the form on day 1, it just worked. Then it took us two weeks to move that to more cost-efficient services and evolve the service further (for example, to be able to amend the scheduled slot). We paid for a few weeks more than was necessary, but the service was live and in the hands of those that needed it.
We could have waited a month and done the optimization upfront and then rolled it out, but you can get a lot of people vaccinated in a month.
Another example might be a service for the world’s largest sneakers manufacturer. The decision was between optimizing for agility and deploying a service that would be ready for Black Friday and the Christmas season or optimizing for cost and deploying the service in time for Valentine’s Day.
After stating it in those terms, which path do you think they chose? Which path would you choose?
Practicality: An architect needs to be in control of everything from innovation to workload deployment, scalability, agility, governance, and so on. It is literally impossible for one person to mind all these things, so to scale, an architect needs to influence the rest of the organization to get buy-in initially and continually, and to help create an organization that is then by default ready to address these challenges without the need to micromanage, argue, or struggle to deliver on all levels of the organization.
This book will address this challenge by providing the patterns and mechanisms (and sometimes just pure practical advice) on how to achieve this goal. This is a continuous process that is overwhelming initially and like any new process, it is initially painful as it involves all levels of the organization, but with the proper strategy and planning it can be done at scale.
Understand cloud adoption and digital transformation generally, and what it means in practicality in the day-to-day running of a cloud platform. Learn from actual examples – an enterprise company, a start-up/greenfield site, or a less than successful cloud adoption.
Be able to plan the cloud adoption journey and help all levels of the organization to do so as well. And then execute on that.
Innovate with the business goals in mind, then execute with cloud workloads that are automated and deployed in a predictable and safe manner, in a fast and agile way, without worrying every time someone interacts with the cloud that something will go wrong.
Have an overview of the entirety of your cloud workloads, what they do, why they are there, how they interact with each other, and how to deal with any issue relating to them being there – from communicating internally on required improvements to communicating internally to stakeholders and externally to customers when things inevitably go wrong.
Understand something about the concepts of governance, security, privacy, reliability, operational excellence, cost optimization, performance efficiency, and a whole bunch of Azure services and how/when to use them. Organize teams across the organization and join any of those teams to showcase your ideas or help them understand a difficult cloud concept.
Assumptions
Top of the list of assumptions is your organization has or is planning to have a cloud-first strategy and you have a significant role to play in it – hence we’ve written this book for you. So, we assume you have some understanding or maybe some experience of concepts such as these:
- Infrastructure as a Service
- The major cloud providers: Microsoft, Amazon, and Google
We will attempt to bring everyone to the same level of knowledge, but in general, we assume that architects have general knowledge of (but may lack extensive experience with some or all of) software architecture, cloud architecture, and organizational change management concepts.