I will take you through it in a pretty simple structure where I shortly introduce myself, dive a bit about the journey and then go into the challenges and especially the lessons that I've learned, hopefully that will help you also when you're engaged in your journey, or even if you're faced in your journey already, who am I? Schneider has spent my entire career in banking and especially bridging the gap between business and it over the past eight to 10 years, I specialized in security. And the last four years I was managing an IM team where we were engaged in the migration transition from the organization towards a cloud environment and the transformation towards a DevOps way of working. And during that those years, I experienced that going through the cloud, a journey, I should have talked to Martin because he already told it and he could have warn me before, but I had to experience it by myself.
And it's a journey also because it has an ambition. You want engage in a journey like you go backpacking in Australia. You want to go there for a purpose to learn something, to experience something. But it's also important to know where you're coming from. And how do you get from a to B looking at the ambition, your organization, isn't going to the clouds, just for the sake of the cloud. You aim for a specific goal, a specific purpose, and that could be to spike up your innovation. It could be to shorten your time to market, but it could also be because you expect a lower cost level or you are faced with an environment which is full of issues and challenges, which you hope to solve by moving away from that platform. Knowing your ambition from the organization will definitely help you and guide you on your way towards the cloud.
But don't forget to check with your sponsors. A transition to a cloud requires the involvement of the CTO, the CIO, and the C shop amongst many others. Are you aware of their ambitions and their expectations when going to the cloud, if you know what your ambition is, it's also important to know where you're coming from and transition to a cloud is a lot of technology. So how familiar are you with your technology? Are you coming from one platform or do you already have multiple platforms and your application landscape? Is it based on a handful of critical applications or is the widespread application landscape full of GOs applications, homegrown applications, even size applications, the better, you know, your structure and the better, you know, where you're coming from, the better your journey will be, but it's not only about technology. It's also about you people in your organization.
How is your organization set up? Are you heavily outsourced? How does your staff look like? Is it external, internal? Are you relying on a handful of experienced people and how mature is your development team or your development teams? Aren't they familiar with networking? Are they familiar with security? How mature are they in automation? Because that will definitely drive and have an impact on your migration. And that's, if you know where you're coming from, you know, where you want to head, you can think about how to get there. And there's a lot of things to do about training and whatsoever, but I especially focus a bit on the migration part on the technology perspective. Very interesting choices that you have when you start off, will you engage on the platform simply by starting with one or two applications and one or two teams building and setting up your, your cloud structure, or will you build the platform beforehand so that every application that you have can land on a already prepared environment, are you going for a learning experience, learning along the way where you want to go for first time?
Right? That's very important if you engage on that journey, because that gives structure the same applies for you migration strategy with your applications, will you simply lift and shift, which is almost considered the easy way. It could be very helpful if you have an platform which you want to get rid of. So the quicker you migrate, the better it is, or you want to fully redesign your applications, fully embracing the cloud functionality. That will take more time, but has it benefit or are you gonna choose a middle way and choose for, or let the teams choose the better you prepare them, what to go for? The better your migration journey will be.
But enough said about the journey. What about the challenges I've experienced a lot, but let's focus on a few interesting challenges. The first one is about perspective and the people that you work with, I encountered challenge you with respect to ownership and facing the changes along the way, looking at your partners, you've chosen the cloud, whether it's AWS, whether it's Azure, you are engaged in a partnership with Microsoft, Google, and that's great, your partners, and you wanna make the best out of it, but have you had a good look at what drives the partners at cloud partner is going for consumption because consumption drives their income and how did they expand and get the most consumption is by attracting all the development communities to use and consume that platform to the maximum. And they do that by building all kind of fancy tools, creating huge, useful functionality and making it as easy as possible to use.
Hey, and that's great because your team is always fun. If they really enjoy a new fancy platform, but they start off with one thing in mind, the platform, and that's basically, they expected all the developers are mature, are well trained and they know how to set it up properly to set up the right security. And I don't know about your, your organization, but if you have tens or even hundreds of development teams, you probably have are certain that the majority of those teams are mature well trained, but there are some teams where you might not be that certain or you even know that they're no mature enough. And one thing that you want to prevent is that you end up in the newspaper because there is a minor on your platform or even worse that there is a data exposed. So as an organization, you would like to prevent stupid mistakes.
And that is a bit of a challenge. If you work with a platform that engages in autonomy of teams, so you will have to find a balance between the autonomy of a team and preventing stupid mistakes. And what about your internal parties? Like already said, you have your CTO, your CSO, and, and your COO. They all have their own ambitions going for time to market going for reduction of cost, going for optimal social security. And unfortunately migration through a cloud is not a free lunch. You will not get everything for free. So sometimes you have to choose one over the other. So it's eminent that you have that you make sure that, you know, what's driving everybody, but also make sure that you align everybody because you don't want to end up fighting between all the parties, trying to get, make the best out of it.
Another interesting challenge, which I hadn't expected, at least not to that extent is the question who's accountable. I come from a large organization where there is a IM team where you have a platform team where you have a network team, everything is split. And then you end up with a platform which is built and set up so that a small enterprise can also en engage and work with it with a handful experts. And then you end up with a dilemma who will now be accountable and responsible for the maintenance of Azure active directory, Google identity. Will that be the IM team because it's identity or will it be the platform because it's the basis of the platform or will it be end user services because it's for office 365. So basically you end up with choices where you wanna align the responsibility, the same applies for your development teams, autonomy versus control.
The platform is so widely. So you have to choose for every aspect of, for every new feature, have to find that proper balance, including the choice you wanna make one structure for all the teams, or you wanna make a segmentation per team. That's also an interesting game. And how about your vendors, if you're outsourced, what will the outsource party do and working together with your partner, with your platform partner? I do expect, or I do experience that trying to build up a service level agreement with a Microsoft or Google is a very different ballgame than trying to set up service level agreement with a local it party responsible for your on-prem data center. There are slightly different things, but they will have a lot of impact. So having to balance accountability and rethink about your accountability is an important part of that journey.
And last but not least, it's one of the challenges that I faced was how to deal with a moving target and move target. The good thing about a cloud environment, one of the reasons to go for cloud environment is it's continuously evolving. It's improving, it's growing all kind of new features, weaknesses are being fixed, but how do you cope with that as an organization? Because there is a lot of new change. And what do you do if a new feature comes out, will you simply let it open for all teams to implement and start using? Or will you test it beforehand or even control it beforehand so that you configure it in such a way that it's being implemented, safe and sound. The choice that you can make as an organization is all dependent again on what is the goal that you wanna achieve? What is the issue that you tried to solve legislation first?
We could not go to the cloud, then it was okay. If you go to the cloud, then it was okay. And now with res it's about, Hey, think about your cloud again. The same goes for the organization. When we engaged in the cloud journey, it was one cloud. Now everybody agrees and accepts, Hey, it's a multi-cloud multi hybrid. How do we go with that? So how do you cope with those changes? And these are pretty generic challenges, but as a manager, I have to find a way to cope with that. And it's not only about technology. A lot of the talks that I heard over the past days are amount, which tools should I use and how do you implement that? But there are lot of interesting challenges which you have to solve together with your team. So it's about where do I focus as a team on, will I be the domain admin of Azure I 80?
Or will I take two sale point for rock and manage that application and manage the access on that level? And how much power do you give to the teams? That's all about, Hey, do I do that for Azure key vault or the secrets manager? What are the teams allowed to do? And what will we manage centrally? One of the very interesting challenges I think is about technology again, where you go cloud native, making sure that the teams use the seamless experience that platform provides, or you go cloud agnostic. And what if the direction of your organization changes? It's quite easy if you go only to a cloud or single cloud, but what if you go or change the direction to multiple cloud, then again, you have to rethink your strategy migration already said, if you have a lot of applications to migrate, how do you help the teams?
Of course, they can look for a YouTube movie or find a, a document how to set it up, but it's about helping them migrating in the right way. Do you engage actively or do you wait and see, and have you also thought about the dependency you have on the cloud? If you put all your identities in the cloud and that cloud service goes down and yes, it goes down. Are you able to cope with that? How do you cope with that? And have you been prepared or do you prepare yourself? If something goes corrupt, those kind of challenges you'll have to face in a cloud and sharing the cloud. Yeah. We can collaborate with all kind of organizations by connecting the, the, the active directories and join up. Yeah. But you also expose the landscape to a lot of new parties. When do you go for that?
And why not? Basically the way I try to solve these kind of dilemmas is making sure that I know what the focus and the ambition of the organization is, is the main driver cost reduction. It's a different ballgame than if you like to solve the issues on a legacy platform. And don't underestimate the risk appetite. Not every organization has its own risk appetite, or is enforced to have a specific risk appetite. So you have to make sure that you balance that one allow for learning along the way for everyone. It's a new experience, whether it's the auditors, whether it's the developers, whether it's your IM team, they all have to learn. But I have been accused of not understanding the cloud or not adopting the cloud. But one thing that I did know is that you, you definitely have to think also about the experiences that you learned in the old world, because a local SQL account will still be there on the cloud.
So you'll have to face those issues as well, and start measuring from the start. The cloud has a lot of data and you have to make sure that you start using it and start understanding it and start implementing it so that you can show that you're in control, but also you are able to learn wrapping up conclusion. What do you hope that you take along migration to the cloud is a journey and it requires persistence. Make sure you work as one team, the platform team, the IM team, the network team work together, join forces with the cloud provider. It will combine the strengths and it will be a lot of more fun instead of Hey, that team is not doing what I wanted to be. The cloud, bring new challenges, but also you'll have to face the traditional ones. So don't overlook them, start learning in mind and don't do it based on assumptions. Use the data that's there in the platform and use it from the start and last but not least don't ever expect to be ready ever, just like Inna. It's never done. The only thing, what you can do is making sure that you get better at it every day.
Thank you all for attending Anna. You're deserving.
