So as we were just starting talking about that, the need for a cloud strategy, et cetera, maybe I start with a little background. I mean, in the last one and half years, the advent of the COVID pandemic on one site cost major disruptions to many businesses. In fact, if I look into the travel or airline industry, which I come from, it completely grounded us. But on the other side, if you look at the revenues of some of the technology companies or cloud companies, they have ramped up significantly. Then the massive shift that we have from a work from home model almost overnight, further accelerated cloud consumption, remote working model requires access to high performing scalable infrastructure, which is one of the big benefits that cloud claims to provide. There was an interesting anecdote some days back when I was reading it that the currently the top 10 cloud tech companies valuation.
So the market capitalization of the top 10 cloud technology companies is currently higher than the combined market capitalization of the global top 10 banks. So some decades back who would've thought about it, that technology companies would evaluate at higher than the financial institutions. When you take management consultants, you listen to Analyst, you read any technology vaccines almost no one has any doubt that enterprises across the globe will continue to increase your investments. In cloud cloud and cloud enabled technologies like mobile mobility, IOT data, AIX collaboration tools will only grow. Having said that there are also multiple other statistics that you might treat many cloud programs struggle. If you look around, there are very few large enterprises that can confidently claim that they have a significant proportion of the workloads on cloud. Either they struggle in the cloud journey or they claim it becomes more expensive, or they somehow relies to the benefits that were initially promised. They're not able to leverage it. So somehow these two sites are contradicting. So what we are doing here, or what we are trying to achieve is some sort of a balance and some sort of a clarity on this entire exercise. So as I said, my name is, and I had the cloud transformation journey at Lyft. And in the next 15 minutes, I will try to touch upon the aspects as to why building a cloud strategy and optimizing a cloud strategy is quite needed to ensure that your cloud transformation program is successful.
I come from a travel industry. We try to take the same examples when you're trying to plan a travel journey. You'd start with a basic question. Why are you traveling? Or you could break it down into some other aspects, for instance, what is the motivation for your travel? When is the right time to travel, depending upon the time, where do you want to travel? What kind of experience are you looking for in your target destination? How do you really navigate this journey? Do you use a travel advisor? Do you use some sort of a all inclusive package or something that, so in the end, you're trying to build an overall experience, which is further subdividing into these inherent questions that are just listed out. And if you have good answers to all these questions, you're assured that your travel journey and the overall experience will be memorable.
And it's quite similar when we try to map it from a cloud perspective. Also, let's start this journey by answering some of these questions and see whether they can lead to building up a good strategy from our side. As I said earlier, most organizations around the globe are already in some stages traveling towards cloud. The question is not if the question is how and when can I truly adopt cloud, but for that, there are certain factors that we need to discuss as to what is really happening in the it landscape today. It's not necessarily from a cloud perspective, but from an overall it trends and it industry perspective. I think the very first aspect is the aspect of digital transformation. There is hardly a management meeting. There is hardly a board meeting. There is hardly any agenda of a conference that goes by where you don't have this perfect digital attached to that.
It might be a big jargon. It might be a big buzz for today, but when you try to split this word, digital and digital transformation, in my perspective, it boils down to two major aspects. First is merger of it and business. And the second aspect is heavy emphasis on agility and flexibility. And we will see as to these are exactly the kind of benefits that cloud promises to bring as to disrupting your traditional business models, redefining the customer experiences. And that is how cloud claims is leading into some sort of disruption. The second one I already started with the disruptions caused by COVID. I mean, the demand for cloud grew enormously in the wake of the pandemic. It was driven mostly by the organization's Hasling or grappling to power their workforce remotely and becoming more agile, having the right infrastructure, having the right ID model was essential to support and empower this disruption that happened.
As I said, almost overnight, combined with digitalizations combined by remote working there have also been a heavy emphasis to relook as to how we secure our infrastructure, how we build our infrastructure more resilient, reliable, and what are our philosophy behind the disaster recovery and a business continu management? I think this is also something that over the last two to three years, the emphasis or the discussion has significantly increased. There are also a couple of other areas which are usually not talked about, but in my experience, there are also certain trends that we see here. For instance, the application specific life cycle requirements are getting more and more dynamic. I mean, the days when we built an application 20 years back and hardly any changes happen, except for maybe upgrading your operating system for databases, those days are getting over. There is also a need to balance your traditional environments.
And what we call is innovation driven environments. Some consultants call it two speed. It, I don't like to use that word, but yes, in your organization, you would have certain traditional processes, traditional applications, traditional environments, and some fast moving agile environments last but not the least and something which has barely been noticed today is a couple of decades back. The outsourcing models were completely different. You used to hear about entire it infrastructures, the entire it getting outsourced over large durations, like seven years, 10 years, you don't hear about such kind of changes anymore. You don't hear about such contracts anymore. And those outsourcing models are getting more piecemeal, more specific and very, very structured. So the on premise contract discussions or the outsourcing model discussions are changing. And the reason I highlight all of these aspect is because these inherently are feeding as to why cloud is required in the organization or how you should look into cloud.
So, first of all, when you start building a cloud strategy, the very first point that I would like to highlight is cloud is not an it infrastructure strategy. It is not an answer to your data center. It's not an answer to your data center, transformation exercise. And it's definitely not an answer for replacing your data center. It is indeed one of the triggers, but if you start approaching cloud from a traditional infrastructure perspective or from a traditional data center lifecycle perspective, chances are you're missing the lot of benefits that cloud claims to provide. I started with digital transformation and indeed cloud is a foundation for digital transformation. There are applications and business models that can be completely built from scratch using cloud as a platform. That's why I don't use cloud as infrastructure. I don't use cloud as a technology. I like to call cloud as a platform.
When we start building a cloud strategy, it needs to be firmly embedded as one of the grounding principles of one of the core pillars, not just behind your it strategy, but also behind the digital strategy. Because as I said, cloud forms, business models, it disrupts the way the transformation exercise is conducted in organization. There's also some sort of a myth that I have an application in a traditional data center. If I migrate to cloud, I'm done with it, or the journey to cloud more or less comes to end. I think that's another way or myth or another wrong way of looking at cloud. Just like digital transformation has no end goal. According to me, the cloud migration or migration of an application to cloud is usually the start of a journey because the real agility or the real benefit of an application comes when you start innovating in cloud or start using cloud native services last but not the least cloud strategy is not a one time exercise.
So it's not that you create a paper, couple of slides put it in some sort of a knowledge management database. And you're done with it. Cloud as a platform is constantly evolving. In fact, evolving faster than what we can manage, enhance the strategy work, or what you want to really leverage with cloud is also an ongoing process and has to constantly evolve as well. So let's come come to some of the points from a strategy perspective and how we at are approaching cloud and cloud strategy. So just like many other organizations, we also started with the strategies by simply saying cloud first, meaning that we also thought a couple of years back, we would like to have every application into cloud, but we very soon realized that's again, a wrong way of looking at it. Cloud provides a lot of benefits, but it's not an answer to every problem or every bucket of applications that you have in your portfolio.
So while in our strategy philosophy, we adapted it. And a couple of years back, we said cloud first but not cloud only what does it really mean? It simply means that cloud is always the first platform to be considered. Whether I'm purchasing an application or building an application, we will not build or buy applications for native data centers. It'll always be for cloud, but we also realize that there is a reasoning, or there might be reasons why alternatives might be relevant. Hence we will buy, build cloud enabled it systems only. We will try to migrate our entire landscape, which is hosted on legacy infrastructures to the cloud, but there has to be a business benefit for it. We will not wait for the sake of it again, to be sure that business benefit is not confused by a one to one cost comparison, meaning that I'm not trying to compare cost per server in a traditional data center versus cost per server in cloud, I would like to see cloud business creates created more holistically, meaning some of the benefits that cloud provides like eligibility flexibility, performance, security that we talked about in one of the previous slides, they have to be factored in, in creating an overall total cost of ownership non-functional requirements, which is one of the big benefits that cloud comes up with, especially when it comes to quality resilience, the security performance, those have to be calculated in our area.
We have given certain kind of priorities. As you know, cloud comes with various kinds of deployment models. Software as a service platform is service container services, etcetera. And hence we set certain priorities by saying that our first priority software is a service followed by platforms. And third is infrastructure service. So we would try to use cloud as native as possible. And we would like to avoid migrating applications purely on a rehost basis using only the infrastructure technique at the same time, just to avoid that south model or software as a service model is confused, but the general contractor model, meaning I should not ask my application developer to host it somewhere and run it back to me as a black box, we have created certain guidelines that more or less fulfills the same cloud principles, meaning if an application is hosted in south, it follows the same cloud principles like elasticity, scalability, meter usage, or paper use, et cetera.
And that is what sauce is. We also realize that there are a lot of legacy applications, which have to be modernized, but they should not be forced fit into cloud. Meaning if an application is not cloud ready or does not cannot avail the benefits of cloud, then we might as well leave it on-prim and not try to force it into cloud and then worry about why it's more expensive or why it doesn't work in cloud or why it's slower in cloud. So these are some of the basic guidelines that we have put in, which are then explained through certain examples, certain scenarios into the cloud strategy document. We also decided that we will not put all our X in one basket. So we decided to go with a multi landing zone approach, meaning that we work with multiple clouds. And hence we have enabled certain processes that allows this deployment of applications into multiple clouds or selection of clouds for different clusters or different scenarios or different verticals is a group meaning that we have many companies from airlines, from logistics, from catering, from MRO, et cetera.
We also realized that there is a need for setting up a central cloud team that can steer the cloud projects across the organization, meaning that while every individual organization might have their own applications, there is certain amount of synergy and benefits that comes when you follow a similar kind of cloud techniques, cloud services, cloud governance, and creates similar structure foundation layers. It definitely provides a lot of reusability benefits last but not the least cloud, being a new concept. It's quite important to build a certain momentum foster communication builds skills, cetera, hence promotion, or a setup of a cloud community extremely helped us in this entire journey.
As I talked about a central cloud team, I just tried to bring a slide, trying to UN explain what the central cloud team tries to orchestrate. So when you're trying to set up a cloud journey or set up a cloud transformation program, you realize that this requires interfacing with various stakeholders. For instance, you have application owners that might come with different functionalities or different functional domains or different legal entities. There is an architecture team, usually an enterprise architecture that, that you might have in your organization that takes decisions on certain technologies, certain roadmaps, et cetera. You have an infrastructure team that sets up data centers that sets up networks, firewalls, et cetera. You have a security team that sets up your overall it security policy, cybersecurity policy, cyber defense, et cetera. Obviously you have a procurement or purchasing organizations that is setting up agreements, work orders with your cloud providers, your cloud operations providers, your cloud migration providers.
One of the most important aspects that sometimes people ignore is the licenses. The license management and cloud is quite different for license management on an on data center, especially when it comes to certain technologies like Oracle databases or Citrix, et cetera. And last but not the least, again, the operations part of it, it's generally as zoomed that the operations on an on-prem data center is quite similar to an operations and cloud. It is actually not the case. Operations and cloud puts in more responsibility directly into the hands of application developer or application owners. So the earlier world where you can have an application world and an infrastructure world, and the two worlds are more split across those boundaries are blurring. Now the responsibility of an infrastructure team or an application team is not so clear when you're trying to set up things in cloud, because an application team itself can deploy applications, can manage the infrastructure down all the way up to virtual machines, operating systems, patching, et cetera, onto the cloud. So the operations team itself changes their responsibilities increase, especially when it comes from an application side and orchestrating Dr. Pieces to ensure that applications get migrated smoothly and are able to leverage the benefits properly central cloud team was created, which obviously included a lot of packages, like for instance, cloud strategy, cloud governance, automation as to how to use different automated techniques C and such things in terms of disaster recovery, backups, SLAs cetera was then handled by the central cloud team.
There's one more slide that I would like to talk about when you're trying to migrate to cloud. There would be lot of times when you can make multiple decisions, meaning that an application can get migrated by different migration approaches or different solution designs and enhance certain guiding principle is needed to give you an example. If you're trying to migrate an application on a lift and shift basis, it's faster, but chances are, you're not able to leverage the right benefits. On the other hand, you might need to modernize your application, which provides a lot of benefits. Maybe you also saves cost, but it takes a huge amount of time. So there are certain balancing factors. So we already talked about cost. Then there is a time factor cause every application has a life cycle, has a contract expire associated that the design factor is your applications.
Modular. Is your application able to use APIs? What kind of architecture and policies are built into your application reusability? When you're trying to set up applications in cloud, you can get a lot of cloud optimization benefits if you have shared resources. So for instance, applications use containers, and there's no point in creating containers for individual applications, you can create shared container environments. You can create shared databases. You can create shared images, repeatability. As I said, cloud allows infrastructure automation. That means you create an environment once and then you can keep replicating it and destroying it. Hence it's quite important that you automate the infrastructure set up completely through scripts using technologies like terraforms for instance, and nativity like using platform services, cloud service is quite essential when it comes to right decision making.
So coming to an end, I mean, we talked about that. There is a need for a strategy. There is a need for a structure, and there is a need for setting up some sort of governance principles, but to ensure that your strategy is successful or to ensure that your cloud transformation is successful. One aspect that is usually ignored or is underestimated is change management. As I said, when it comes to cloud, it's quite different from a traditional infrastructure environment. The general mistake that people do is they will try to replicate their data center processes onto cloud. So for instance, the provisioning processes or the release and deployment processes or the operations processes or financial controlling processes, as an example, and then they complain that the cloud is not able to provide the right agility or the right performance benefits or the right cost benefits, enhanced heavy emphasis on changing sometimes even disrupting these processes is essential to make cloud work. That more or less leads me to the end. I hope I was able to cover in the short 15 minutes, some aspects behind setting up this cloud transformation journey and why strategy is not just creating a cloud landing zone approach, but an overall whole holistic approach, including strategy, structure governance. And as I said in the last management of change.
