To SaaS or Not to SaaS

Copy. So my name is Thomas Van vn. I'm part of the digital identity practice at PWC and we built basically digital identity capability for our clients from both a business and a technology perspective. I was supposed to be joined here on stage by our technical Eminence boss, but he couldn't join due to personal circumstances. So you have to do with me today. So I've been in identity for about 25 years and that makes me somewhat of a dinosaur maybe, and I know I'm already offending a lot of other people also in this room.

But you might have also thought that from the title of my presentation about you know, who was at, you know, it's 2024, who was maybe challenging if you sort of look at the title whether or not to go to SaaS. And I think what you will get at the end of this talk is that I'm not so much challenging. It I think makes complete sense. I just think there's some couple of things that you need to take into account and that might be also viable alternatives as well. So just to set the scene in terms of why I am posing the questions in the first place.

So of course we as identity professionals, we've I think always thought as identity being the most important thing there is of course, and fortunately a lot of our executives and IT leaders are also increasingly thinking the same. So as pwc we do this digital trust survey every year, roughly 4,000 correspondents. And what we see from last year's survey is that digital and technology risks as well as cyber risks are the two top priorities for them to to tackle.

And of course this is, we've always been trying to sort of enable the business in terms of collaborating an ecosystem with IM in terms of optimizing costs. But of course what you also see is a lot of clients are trying to address increasing regulatory pressure likeness two or cyber attacks. From that perspective, I think my colleague from ManCom talked about even cyber warfare in his keynote on Tuesday. So just a testament in terms of why identity is also becoming increasingly relevant.

And at the same time a lot of, you know what we said our clients, they are the are at the crossroads of course having built a IM capability over the past couple of years, a lot of that's still on premise. But now becoming either not meeting the demands or economically and technically becoming end of life or maybe simply the fact that a lot of the vendors and software that they work with are, you know, moving to different solutions set or moving their products end of life. So naturally the question is what's next for us?

And I think the adoption of SaaS, that of course makes sense, provides a lot of benefits in terms of cost savings. You have of course can reduce your dependency or value cares labor set by going to cloud and of course you can focus on business with the value more because the time to service is of course also a lot quicker with SaaS. But I think there's, as there are a lot of benefits, I think a lot of nuances also that we need to take into account.

And if you sort of look at, again, dumbing down the IM domain a little bit here, if you look at the three main solution spaces, access management, POM and IJ identity governance, I think there are at different sort of places maturity wise, I think access management typically with the work that has been done on standards has enabled this movement to the cloud already quite early on in terms of how that compares to your on-prem technology, if you still have that pretty much you can do everything or also with SaaS, I think for identity conferences and preface access, that's typically a different ball game.

Typically in breadth, if you sort of look at the main functionalities that you wanna cover, you can sort of tick the boxes, but if you look a little bit deeper, there are a lot of differences with what you might be used to be getting with your on-prem solution. So I think that's important to, to take onto account. But also there might be also some reluctance in terms of moving to the cloud.

So what we see a lot at clients that when it comes to PFL access predominantly is that there's some sensitivity in terms of storing your secrets, your privileged access in the cloud, but sometimes there's also regulatory requirements in terms of you know, where data needs to reside or originate for example with Chinese cyber law. So a lot of things to consider I think before you make the the step to to, to sas depending on where you're coming from and depending on the solution space that that you're looking at.

So just to give you a couple of examples of what we've seen from that in real life. So the first thing is that what we typically see is that when you move to sas, basically it means a change in the ways of working. So for example, we had a client that moved from an on-premise IJ solution to a cloud-based IJ solution. And of course all the typical functionalities were there, but if you looked a bit deeper, there were still some product gaps in terms of how data was being segmented within the IJA solution.

So how can you sort of shield data within different parts of the business from each other? How much can you sort of put the delegation of role management for example in a decentralized fashion still within your organization if you are IJ product doesn't segment the data in proper way. So that means in this particular case that client had to do a lot of centrally again rather than decently. That of course has impact on your IM team in terms of capacity but also in terms of the autonomy that your, you know, local teams had previously security operations teams, compliance team.

So this is again just an example of of how things can change when you move to SaaS if you're not sort of looking at it in a bit more detail already, you alluded a little bit to it. What we also quite often see when you move to SaaS that the role of the IM team changes. So of course there's less technical upkeep to do. Yes we have still have the integrations, but the main solution of course is pretty much taken care of by the SaaS vendor.

However, that does mean that if you have a team of technical engineers, technical operators, they might also see that there's a threat. So a, you also need to take that into account when you go for SaaS and when you execute, how do you bring them on board, but also what does that mean for their job going forward? I think there's also business opportunity with that, right? Because we can maybe focus more on, let's say the business operator Im, we can be partner better to the business in terms of, I dunno, role management design for example.

But it does mean that it's a different skill set and you need to make sure that your team sort of grows together with that change. And again, sometimes it's also a matter of temporarily scaling up the team if in my example you move from the decentralized to a centralized model for some of the admin things that you also need to capacity to be able to serve that business going forward. Otherwise the transition will not be perceived as a success because it will be long lead times and be less, basically less, less efficient.

The third thing I sort of wanted to point out is there's also different technical challenges. So one of the examples is that if you have for example, product gaps because of the feature parity example I talked about, you might need to have complementing solutions. So for example, one of our clients didn't have a firefighter or had firefighter access within their existing solution and they had Azure D management capability. They needed to look for alternative solutions components in their architecture to make the cap capability whole.

But it does also mean that you're looking at a couple of integrations between these different components that you need to make sure that it can be doable at the at the right level. And other thing on integration, I think what we've seen also a lot is that even though it's sars, there's still in some cases dependency on the SaaS vendor to actually do your transition to that SARS solution for QA of the deployment that that you have done for development that you have done sometimes even promoting it to production that you need the SARS vendor to basically push a button.

So I think when you go on that journey of a migration from on prem to cloud these, some of the key things that I think you need to take into account because it will affect of course things like lead times and your the the, the efficiency you have within your transition program. And that's nice, but so what can you do about it? And one of my colleagues said, you know, this is a no shit Sherlock slide, which some to some extent I agree with has a lot of common sense I think here.

But based on what I've experienced working with clients where we came in midway to sort of fix quote unquote their migration, I think there's still a a couple of good pointers. So think through before you start. So what we've seen a lot that a lot of clients are sort of underestimating how their existing solutions are used.

So how, how security teams are using certain reporting capability or how certain Im local IM teams are using it to, I dunno, onboard contractors. There's a lot of ingenuity within within your organization and are really maximizing the best of the solution, which might not, not always be aware of that and how reliant on it they are for the for yeah their processes.

So truly making an inventory, trying to understand before you go through that journey, before you go through that migration, how it is used will also help you to assess the impact of where some of these, for example, feature parity differences are between your on-prem and the cloud solution that, that you are are about to choose.

And of course then you can based on that impact, decide not to do it or go for a different vendor, but if you choose to do it, at least you understand the impact and that you, you can act on that while you execute on it in terms of making sure you have the buy-in and that you take them along on, on on the change. I think that's also a segue into the second thing, right, in terms of enriching your plan. I think in the 10 plus years that we've been coming to ESE, we've heard a lot about identity projects or programs not being a technology project, but I also a business change. So that's not new.

But what we do see is that the efforts that needs to go into the change management part, so stakeholder management, your communication and training when you move to sas, I think it's exponentially more than an with a typical implementation with on-prem, just for the sake of that in the history we tailored our solutions to the requirements and now we have to tailor the expectations to what the tooling is giving us. So that means that a lot of effort needs to go into that as well.

And I think the title led to SaaS or not to SaaS kind of alludes to the third point in terms of okay, you can also choose a different path, right? Whether, whether you cannot go to SaaS because of regulatory requirements or, or because you think the impact of the delta between what you're coming from and what you're moving to in terms of the SaaS solution is too big. There's also, let's say a cloudified on on-prem versions available that also can give you similar benefits to size. I just wanna talk about that a little bit.

So just sort of to summarize in terms of what we and our clients are looking for when they adopt size in terms of the value. So of course we're looking for the scalability and the performance and solutions. Something we don't need to worry about anymore. We can focus on time to service because the feature development is done for us. We're also not stuck in like four or five, six month upgrade cycles because hey, we're always on the latest version.

And inherently, even though eh security is not something you can outsource, I think by sharing a platform with other organizations, being multi-tenant, at least some of the security hygiene is of course taken care for. You all makes sense. But you can also, well maybe not a bit, but an end, you can also do that in a cloudified on-prem version because the way SaaS vendors are able to deliver us those values is because they're using principles, tools, and methodologies. We can also embrace in an on-prem world.

So of course, and I'm cheating a little bit here with cloud computing, if we talk about utilization of of pass, whether that is GCP or AWS or Azure, but we get some of the infrastructure of course right out of the gate and there's things like containerization we can leverage on top of that in terms of getting the auto scaling if and if we follow software development employment best practices.

But with infrastructure as code and configuration as code through A-C-S-E-D pipeline, we can actually ensure quality and consistency throughout the staging environment and also get the, through the automation, the time to service and the speed that looking for also in sars. So I think we, you can replicate the same benefits using the technologies and tools that also those SaaS vendors are using. We're just not seeing it. I think many of you by the way know this picture from all the presentations I've tried to give credit to where it originates from.

But if somebody knows I have been able to find it just a small disclaimer that I didn't put, didn't put it together. So how do we apply this as pwc? So of course we work with a lot of technology vendors and I should have replaced the force, Oak Loco Painful as that sometimes is also new opportunity with them becoming part of the ping family.

There's more technology vendors that we work with, but basically we take their technology as pwc, we containerize that technology and of course for the clients for which we deliver this technology, we apply security hardening, hardening and the best practices for the for for configuration. And that basically gives us a PWC image or PWC container version of that product. And then we push that basically through a CI ICD pipeline to the infrastructure of our clients.

And of course there's a lot of like possibilities for approvals and for principles before you actually automate all the way through production. But just for the sake of it, theoretically we could push it entirely, automatically into the infrastructure of our clients. But of course as client specific implementation. So when we work with a client also, whether it's specific workflow configuration or development of a plugin on top of the platform is also applying the same principles.

We combine that together in the image that is provided by pwc, then it becomes a customer image and then again, following the same principles, you can sort of automatically deploy that, deploy that, sorry, through IC, throughout CICD into the client's environment. And this is dramatically shortening the time to service also for those those clients with on-prem software. And it allows our customers also to focus on not the technical development and maintenance of let's say the core stuff, but on the specific use cases or requirements that your end users have or that your business users have.

So a lot of time, as you would with sar, you can actually spend on things that add value rather than a lot of the hygiene let's say.

So just to give you a, a little flavor of that, just maybe then to wrap up, I think of course, like I said at the beginning, my mission was not so much to challenge going to SaaS, but to be mindful of, you know, what are you stepping into looking at also where you're coming from, really understanding that, that if you decide based on the impact that that might, that might have or the regulatory requirements, there's an alternative path with on-prem deployment using the latest techniques. But more than anything, first thing then plan and then do, this is my talk. Thank you for your time.

Thank you Thomas. I think we have a few minutes maybe for two or three questions. Anyone in the room has a question?

If not, I think there's a question online. Yeah, So people seem to be having trouble hearing, so I'll show it to you as well. For a while it seemed like large enterprises were flirting with cloud repatriation going back OnPrem. And I'm wondering if you know, since you brought up to SaaS or not to SaaS, what are you seeing? Well it is, it would be a bit much to say it's a trend, but we do say clients considering it and sometimes also doing it again to some of the things that also even of medical said on this keynote on Tuesday.

In terms of your operational resilience, sometimes you don't want to be dependent on sars and I think a lot of clients coming to that realization that sometimes it's important to do things on-prem and also it might not always be the best cost option to go to SaaS. So I think a lot of clients are reconsidering, yes. So maybe it's fair to say there's a little bit more acceptance of going high, maybe back hybrid or multi-cloud or for resilience purposes it'll Be hybrid for sure.

But yeah, it's more, it's more less difficult to explain to your peers that you're considering because it is become more acceptable. Yes, Thank you. Alright.

Alright, Last chance for a question from the audience. Yes. Typical IGA gets high privileged access to all of your applications, which is can be a security issue. How do companies look at that when they put all of that in SaaS?

So, sorry, can you repeat that? You Have the pro, you have provisioning, giving high privileged access to all of your applications and putting that in the clouds. How do they look at that In terms of transcending the on-prem world to the SaaS world or Yes.

Yeah, so, so I mean one of the reasons why sometimes clients are reluctant to go SaaS is for this very reason, but of course if you look at what software vendors have done to make that secure, I don't think that's truly legitimate concern. It's more about what is the concern around the data that is addressed in cloud. That is more something we look at. For example, if you are looking at a customer identity solution, it's customer data, then there's different considerations then let's say the address book of your employees, right?

So then think we're more looking at that than at the integration part, if that makes sense. Thank you Thomas. Alright.