Speaker 1: How to think about your cloud migration strategy. Let's say you've made a decision to move your IT infrastructure and applications to the cloud as part of your overall AI transformation. So what's your strategy? First, let's clarify what strategy is. I'll use a simple example. Every strategy has at least one goal. A young person's goal might be to be rich. There are many choices to achieve that goal. One may be to marry somebody with money. Another may be to get a good education and a job. Another to start a business. And yet another to rob a bank. And so on. Some may not align with the person's values. So he may choose to get rich through starting a business because he has a knack for it. The choices the person makes towards achieving the goal is strategy. That's it. If you're not making choices, there is no strategy. I've come across too many attractively formatted strategy documents that are not really strategy. Say you're a retailer. Your web traffic goes up during holiday seasons, and you want to be able to meet the demand. If you have your own IT, then you have to invest in enough IT to take you through these holiday seasons. But at the same time, IT will be much underused for 95% of the year. If you don't invest upfront, then you'll lose sales during these holiday season. So basically, you want to reduce your cost yet ensure scalability. How would you achieve these goals? You got two options. One is to outsource your IT to some other service company. And two is to move your technology to the cloud. If your software application were just some commodity, then you could go with option one because it's not a differentiator. In the early 2000s, Amex outsourced its IT to IBM at a deal worth about $4 billion at the time. On the other hand, if you have applications that differentiate you from others, and you want to maintain control over it, then you could choose option two, which is essentially you renting out computing resources rather than buying it outright on the cloud. Netflix uses Amazon's AWS cloud, so it can scale up and down easily. Say you've done some research and you decided to move to the cloud to reduce your cost and ensure scalability. Right there, you've made your first choice, migrate your IT to the cloud. That thoughtful choice becomes part of your strategy. The next goal is to actually move your information technology to the cloud. You have multiple options. One is called lift and shift. In this case, you're not making any changes to the software, but simply leaving the hardware behind and moving your software to the cloud that's maintained by the cloud providers. This option should directly reduce your cost and allow you to scale, so go for it. Aha. You're not happy with this choice. Why not? Oh, your software is built in such a way that it still requires a lot of maintenance for new business requirements, and you feel that your business is not agile enough. You're constrained. Okay, what you're really saying is that software has to be refactored so that it can deal elegantly with new business requirements and changes. So that option of lifting and shifting is not going to work. Rather, you have to refactor the code. How and when can you do that? One option is to simply move everything to the cloud as is, and then do a second phase where you refactor the code. The problem is you may never ever get to that second phase, and your code will still remain as bad. Another option is to refactor the code as you move to the cloud. This option has more risk associated with it. As a company, you decide that you could come together and reduce that risk. So you have made your next choice. Great. Software applications come in many sizes and forms. Let's just focus on a web-based shopping cart application that your customers use to buy your products. Here's the architecture of that application. On the back end, you have a database, specifically a relational database. The middle layer contains the business logic of reading, manipulating, and writing data back. Finally, the user interface layer is a front-end screen through which the customer interacts with the software application. This is called the three-tier application. Overall, this application drives many business steps or entire business processes. The customer shops on your website and drops a product in the shopping cart. Once the customer purchases the product through a checkout process, it triggers a business process that checks inventory, accepts payments, and sends a notification to the shipping department to ship the product to the customer's address. The shipping department might have its own three-tier application architecture to manage the product that has to be shipped. Their database may be completely separate because that application was developed for their need, perhaps at a different point in time with a different set of technologies. Other business areas might have the same problem, essentially holding duplicate information across their databases with different business logic for the same problem. Having understood this architecture, it looks like we'll have to make a few more choices. Let's focus just on the integration of systems. There are many options here to integrate such systems to make the end-to-end customer experience seamless. Specifically, we'll talk about integrating the shopping and the shipping systems. The simplest option is to use a human to read information from one system and manually retype it into the other. In the customer shopping example, when a notification arrives in the form of an email to an agent, she reads the content of the email and updates the shipping system. As you can tell, this way of doing things is error-prone and inefficient. A better option is to use RPA, or Robotic Process Automation, which I describe in more detail in another video link, which I share below in the description. Another is to wrap the functionality of applications in an API, or Application Programming Interface, where one application calls another to update it. However, this causes a many-to-many integration to happen, and it increases the complexity exponentially. Yet another option is to use an eventing architecture, where one system can drop events into a location, and other systems can pick up those events and use it as needed. For example, a checkout event may be dropped in, which could be picked up by the shipping system. So you have some architectural choices to make. Maybe you picked the eventing architecture to go with. All these choices that you've made so far, choosing the cloud, moving and refactoring in one shot, and using an eventing architecture, all these together make up your cloud migration strategy. I did not cover the exhaustive list of goals or choices that you have to make, but wanted to give you a way to think about it. If you are creating a cloud migration strategy, make sure that you understand the goals and the choices made to achieve each goal. If you haven't done that, you're just getting a fluffy document that goes on the shelf. It's not strategy. If you enjoyed watching this video, please consider subscribing. For a one-page visual summary of this video, sign up on my website. Thank you deeply for giving me the motivation to do what I do.