Yeah, I hope you can see the slides in screen mode for screen mode. So as, as introduction started and also the previous speaker has ING cloud is no longer a buzz word. Now it's very much a reality. It's most organizations in Germany and around the globe, they have been in the steps or in various phases of adopting cloud plus minus two or three years. Depends upon which organization you talk about.
The question that is not usually discussed is when that when people will adopt cloud, that's hardly a question these days, the questions that usually gets discussed in the it circles is how should I navigate the journey to cloud while many organizations at Arctic cloud. It's also a fact that very few organizations have their entire workload and cloud. So while many have started many experienced, some pilots, certain section of cluster of applications. There are very few organizations, especially the large ones that can claim that they have the entire workload and cloud.
So the question usually remains is why cloud is something that people would like to embark upon the challenges that comes with it. What should I do with it? How should I navigate it? And that's something that usually gets talked about. We talked about the COVID crisis also.
So again, in the COVID while it has impacted and passed it, spending across projects, not surprisingly, most of the studies indicate that cloud spending remains one of the top three priorities in current crisis and beyond. And hence the focus of my presentation would not be whether cloud is important or not, but I would like to cover three primary questions. So why are organizations traveling to cloud or why are, why Hans are traveling to cloud? Where are we traveling? So when we talk about cloud, what do we really mean by that?
Cause there are a lot of confusing definitions and conflicting definitions that people assume when they're refer to cloud.
And third and the most important question is this journey. How do we navigate it? So starting on the why side, and as I said already, that while many organizations have started or would like to adopt cloud, they really struggle. And one of the reasons that they struggle is that the question of why is not properly answered.
So I can't claim to have answers for all the organizations, but I would like to look back on the, and why did we decide to adopt into this cloud journey has rightly pointed out at the start itself, cloud adoption usually gets mixed or usually gets with digital transformation and digitalization, digital transformation. These are jargons buzzword, but if you try to demystify it or break it into two broad aspects, we refer to agility and flexibility.
And that's one of the top two objectives that I usually talk about when we refer to it and digital projects and anyone who has been remotely associated with it and cloud would vouch for the fact that when we talk about the benefits of cloud, the top two benefits that comes with cloud is agility and flexibility.
Whether the ability to scale up and down, whether the ability to replicate test and production environments, the ability to have resiliency of buildup, disaster, recovery, and business continuity, et cetera, that some of the primary benefits that cloud provides, obviously in the current landscape, there is also a greater demand to manage the application life cycles and to balance the traditional innovation driven environments. This is something that many consulting organizations usually refer to as two speed it.
And I don't like to differentiate between the organizational aspects of it, but definitely there are projects that would like to be faster, which requires agility as one of the primary concern. And then there are projects where stability is remains as one of the primary objectives for other than these triggers. Obviously one of the big trigger has always been the changes in the, on premise contracts.
So the era of large outsourcing where organizations entirely outsource your it, or at least the infrastructure landscape that is changing now, and lot of smaller scale contracts with more flexible SLAs metrics, driven APIs, those kind of contracts are coming into PR principle.
And that's another trigger that usually comes when we talk about why cloud is getting adopted. One of the things that usually gets confused is when people talk about cloud and cloud adoption, they mix it with an infrastructure strategy.
So for them, they use to have an unpromised data center and they would like to replace it with cloud. So it's just a change of an infrastructure landscape. And as I will see in the rest of my slides, cloud is not just an infrastructure topic. It heavily impacts the rest of the organization, whether it comes from application side, from processes side, the way you behave or the way you set up your organizational structure, it's quite different from a traditional on premise or legacy contracts. Obviously it's a foundation for a digital transformation.
So even with Han a journey started when a few years back Han declared that they would like to be the most digital aviation group in the world.
We even coin a hashtag digital aviation and from the digital strategy cloud became a kind of a supporting pillar to support all these digital projects that came along with it.
Now, when we are starting on this cloud strategy part, obviously many organizations, including the current even title, we talk about cloud first and it was more or less a same level of. So we also came with a blanket statement cloud first, we would like to have everything on cloud, but we very soon realized that that's not the answer. Not every application, not every project, not every objective can be fulfilled by cloud. So cloud is not an answer for everything. So within a few months we adapted our definition and said cloud first, but not cloud, only simple terms.
Every new application that we buy or build will be cloud native. And that's a kind of a set principle for our architectural department as well.
Having said that we also have more than 2000 applications on our legacy on-prem data center environments across regions. And we've like to migrate them to cloud and start reaping the benefits.
So yes, all of those applications have to be migrated to cloud unless a business case does not allow. And just to be sure that we do not confuse business case where they would like for like cost comparison. So I don't want to compare a data center per unit price of a virtual machine versus a data cloud per unit virtual machine price. We set very clearly business case is not just about cost.
The quantification of the benefits that comes with digitalization that comes with application life cycle requirements that comes with business continuity and resiliency, et cetera, have to be factored in because that's the real benefit that cloud provides. And we can't just see it from a pure cost perspective.
So cloud first but not cloud only, and this definition has been rolled out. It's kind of acts as an anchor point or a north star for us. Whenever we talk about any projects, any migration aspects and any kind of guidelines or concepts that we try to roll out.
Obviously it looks ly also decided to go with a multiple landing zone, which also seems to be a common pattern now. So we decided not to put our only one cloud, only one infrastructure provider, but to split it. And we have a two cloud strategy moving on. We just talked about why and the needs to set up some sort of a cloud strategy. Obviously the journey is incomplete unless we know how and where we would like to migrate to clouds obviously provides an opportunity to relook at an application portfolio.
As I said, cloud cannot be seen purely from an infrastructure side, an application recites on cloud and tries to reap the benefits that comes with cloud.
He, the utility of a cloud or the way the governance is set up, has to be seen from an application and even better from a portfolio perspective.
So again, looking at, from the perspective, we have data centers across different regions we have in Germany. Obviously we have it in us. We have it in UK, Singapore, London, and so on. And this entire portfolio we are trying to replace or have migration projects and have multiple landing zones as we call it. The first thing that comes up, which is clearly a surprise. When you start looking at your application portfolio is the amount of applications that you can really retire either.
They were created at the time when, and that functionality is no longer needed or applications can be merged together. And that clearly becomes one of the first priority. When you're looking at assessing your application portfolio or the entire landscape.
So many applications get obsolete. The second priority for us before we start approaching a public or a private cloud, is whether an application can be considered from a software as a SaaS perspective or a SaaS perspective.
Now, many people confuse SAS with some sort of a general contractor ship. So I don't find my application provided to host it in a hidden data center and come back to me and offer a black box pricing.
No, that that's what I call is application service provisioning or a general contractor ship. When I talk about SAS, I'm talking about real SAS in the sense that application can be measured on a transaction basis on a matrix basis. And I really don't have to care about security part of it, the hosting part of it, the maintenance part of it. And I'm getting evergreen approach similar to the one that cloud provides.
And that's why for us SAS takes a priority over an actual cloud hosting. When we move away from retire and replace.
The third priority that comes is, is actually looking at a pure migration approaches. And I don't need to give us to this five R or six RS or seven RS, whether you take a rehost approach or a refactored approach. The point is every application has its unique characteristics and no single migration approach fits in. Obviously every provider or every consulting organization would like you to believe that the best approach is to rearchitect or rebuild your entire application.
But the ground reality is you neither have the budget nor the time to redo each and every application, many applications have created 15, 20 years back. Hence it requires a huge amount of efforts to factor in having said that yes, rebuild and redesign is priority one.
And then you move on to refactor worst case we host or a lift and shift migration. When we look at the rare part in terms of cloud for us, public cloud is priority one, private cloud is priority two.
And we do know despite all best intentions, we would still have certain cluster of applications that might reside in on-prem till their life cycle gets complete. So the cluster will always have three buckets, public cloud, private cloud, and on-prem and yes, the trend would always be to keep shifting left towards the public cloud. But we would like to be conscious and careful that not to ignore that there are certain buckets of publication, which cannot be forced fit into cloud. And for them on-prem is, and will continue to be the right landing zone.
We talked about where, and I would also like to talk about the steps that we at least felt are the right steps for moving an organization or an application portfolio to cloud. And in a, and I know I'm trying to oversimplify it, but we obviously need to start with some sort of a planning phase, which is setting up the journey, setting up the journey simply means that you need to create an organization structure behind it, a roles and responsibilities, a stakeholder alignment, et cetera. Second is a discovery phase that you try to baseline the scope.
Baseline is scope simply means that if you have thousand applications, what kind of characteristics that those applications comes with, what is your life cycle part? What kind of databases do they run through? What kind of security requirements they have, what kind of compliance requirements, data, previous requirements they come with, and that's kind of creating a baseline.
What percentage of this cluster really makes sense to migrate? Once you are clear the portfolios or the clusters that can be migrated, you need to do some sort of a cloud assessment.
Now, every organization has a different name for it. Some call it cloud assessment, portfolio assessment, cloud affinity, mapping with cloud, et cetera, but it's still important to have a portfolio wise understanding what's the target landing zone. What kind of migration approach fits best? Some sort of a high level target deployment and a solution design. And most importantly, do you really have a business case for this cluster or not together with the assessment or as a separate phase, you need to have some sort of a pilot exercise.
This pilot exercise completely depends on your organization structure for us because we are a group. We decided to have two to four applications per subsidiary.
So we have the various service factories in it, various department, and each department should have at least two to three applications of small, to medium size, maybe a couple of interfaces, maybe few users up to hundred, but not causing any outage in case something goes wrong. And that's the kind of candidates that we selected for pilots. Once that's done, then you start with some sort of a wave planning, a wave execution.
Now I have used the word migration factory, although we have soon realized that migration factories a myth and while many providers who try to sell migration factories, a concept in reality, it really does not exist at the end. You're still trying to do kind of a cluster of waves that you're trying to migrate. Maybe in one go, whether you call it migration factory or not, but in assembly line production, obviously so far, we haven't experienced it when it comes to cloud migration.
Obviously there are many stakeholders and interfaces in the journey.
And as a started cloud cannot be viewed purely from an infrastructure site. Infrastructure is just one of the stakeholders. Infrastructure team might decide the firewalls part of it, the, the network management part of it, the basic cloud build, which is an infrastructure layer, et cetera. But obviously then you have a cloud security team, which is defining the policies and standards.
You have a procurement team that is taking care of the agreement for the cloud providers, the different service level agreements, the different work orders, cetera, you have different business units, which are usually the application owners. At least that's how it's in the group. You have an architecture team that is defining the enterprise architecture, the solution design, the reference blueprints, cetera. You have a license management team. And this is quite critical to understand that the license policies on an on-prem environment is quite different from licensed policies on cloud.
And the easiest example that people can talk about is an Oracle database, which has a completely different license policy. When you have an application within database, on on-prem environment and an application with a database on a cloud environment.
And last, but one of the most important one, obviously the operation site, because operating an application on cloud is very different from operating an application on an infrastructure side. And it's something that people don't realize it, but cloud, while it provides a lot of flexibility. And it also adds a lot of accountability on the application owner because he's responsible for his own deployments. He's responsible for his own monitoring. And hence partially he's responsible for the own operations of applications and cloud.
And to orchestrate this different work packages, this different stakeholders is central cloud team was established and that's the central cloud team that I'm kind currently running for it in the interest of time, I will skip the work package slide and move straight to the end, which is cloud provides many opportunities and there is no brainer for it.
I don't need to talk about the elastically provision services or the hardening that the cloud provides or the time to market services, cetera, et cetera.
But what people have to be prepared and has to set up their organizations is to manage what kind of risk and turbulences that comes on its way. Whether we like it or not, there is a short term increase in cost, but it also requires a rethink of a commercial and a controlling processes on an on-prem environment. You more or less have a stable infrastructure cost on a cloud. If you really want to reap the benefit, it goes up and down. And that is something that you can't predict in advance. And that requires some sort of change in the way you predict.
