Bridging the Gap at Philips: Technical and Governance Realities of SaaS IAM Migration

Well, first, before I start, thank you, everyone, for being here. So I know it's already late in the afternoon on a Thursday, so thanks a lot. I really appreciate it. So this is my second time presenting. I think it's the first time presenting by myself, so I'm looking forward to it. So let's get right into it. So today I'll be talking a little bit about how we approached our migration to SaaS from our IAM systems. So all right. So a little bit about Philips. So I presume most of you know Philips. Can I see some hands? Maybe you all know Philips. Good.

So we started making light bulbs about 130 years ago, and it was founded by these three lovely gentlemen here. And we've been doing a lot of innovation over that time.

We, of course, did TVs, all that type of jazz, many things that Philips did. I think there's not many things that you can't name that Philips didn't do. But recently we have transitioned into health care. But the innovation hasn't gone away, and we're still trying to innovate and improve people's lives because of that. And not even that, we're trying to improve about two and a half billion people's lives per year.

All right, let's get into the topic. IAM migration, I'm bridging that gap. I was looking through the agenda this week, and I saw how many presentations there are that had something called bridging the gap in there. I was surprised. It was more than I thought. So the creativity aside. So maybe who thinks or who's thinking about migrating your on-prem legacy IAM solution, whether that be IGA, PAM, or whatever, to a SaaS model? Are there many people? I see some hands. That's good. Are there people that are like, no way, never going to happen? I see no hands, so I guess that's a good thing.

I think we have been in this position also for quite a few years. So in history, like before, it was always very far for us. And we see the landscape evolve. And I think in recent years, we've seen that it was actually a lot closer than we thought. So that's what this presentation is about. So I'll take you a bit back to the beginning. So in our case, IAM exists already for quite some time. So the foundations were laid, I think, between 10, 15 years ago, not by me, but by my lovely colleagues.

Also, by the way, most of this is also founded and created by my colleagues. So kudos also to them. So we exist as IAM, as group security. So I work in group security. We determine the product roadmap vision strategy. And we ensure that it adheres to all the security controls that are defined within Philips. We have our colleagues in IT who run the operational show. And they work together with our MSP to really do that day-to-day support. So we really drive the new features, new functionalities.

And yeah, that's worked great so far. So this is a bit of a generic abstract layer of what our architecture looks like. So thank you, chat GPT. As you can see, we support basically our entire enterprise landscape. So we have systems that bring in our sources, so our HR system. We have some external systems. And actually, you see the partners there. But actually, it's currently still part of our IGA. But that's also being planned to move out. But it's all based on on-prem software.

Of course, we move it to our own cloud. But still, you get all the benefits and drawbacks that come with on-prem. So currently, around 300 applications and thousands of servers are connected to our IAM services. And our philosophy basically has been to use as much direct connectivity as possible. So even though we have on-prem software that's very customizable, we always opted for, let's not try to do that. Because in history, because the whole foundation for IAM was laid 15 years ago. But before that, there were, of course, other systems that had to support the IT lifecycle.

There has been some like-for-like replacing over the years. And that has led us to implement some customization. As I mentioned two years ago, I also presented. So then I talked about how we rolled out our access reviews. That's also something that we do as of now. But it's very static and very rigid, I would say. So then putting that a little bit into a timeline. So as you can see, 10 years ago, almost, we deployed our full, let's say, modern on-prem IGA tool. And we basically put it there as a replacement of a tool that just needs to do some provisioning.

So purely create an account, create your directory account, off-board it on time based on a source. And after that, we, of course, had to get some more coverage in. So we went into onboarding servers, onboarding applications. And after that, once we had a good scope of coverage and a bit of business knowledge that we actually exist as an IAM team, we rolled out additional capabilities.

So indeed, think about certifications. Think about KIEM requesting privileged access, what you may call it. So basically, extending our reach across the company. And Philips is very big, very scattered enterprise. So it's tricky. And I think at that point, we realized, OK, we're done. That's fine. What next? So we saw that we had a need to migrate to SaaS. And that's where we are right now. So where did it come from, that pressure to change? And heartbeat monitor, by the way. So you have your typical SaaS use cases or your typical on-prem drawbacks that you see, right?

So we, of course, have high operating costs. We're a big company. We have a large database. If you need to do maintenance to something, Philips is a regulated company. We're in health care. We need to prove that everything's OK. We need to do a lot of quality and a lot of testing. It's quite cumbersome to actually push even the simplest of changes through. We're working with multiple providers. You have your cloud teams. You have your infrastructure teams, your networking teams, your application team.

And yeah, you need to align a lot of things before you actually get something clarified and aware with everyone. What we also see generally, we come to EIC very often. We keep up with the market. We see vendors moving to a SaaS-first strategy, of course.

And that, I think, is a main driver for us to really start looking into, like, hey, is this something we can? Are we fit for that? We have customization, but maybe not as much. Is it suitable for us? So that's what we did.

And also, I think the most important thing is business demand. So as we said, our IGA tool was there. The basic principles are in place, but we see the market evolving. There's more and more being tied into your typical IGA, into your PAM. It's all converging into a single, let's say, monolith structure that contains all these different services. So that's also one of the reasons why we went for that. So then a decision, decision point. We went into it really pink cloud moment, right? So we said, OK, let's go for it.

SaaS IAM, perfect. Speed, innovation, scalability. We'll get it all. No worries. Don't look at the rest. We get a bunch of new features, and everything can be migrated as is.

Well, of course, that's a bit of a, well, let's say, generalization of the topic. But what we did expect is that we transform our traditional IAM into more of an identity security sphere. So we're really trying to extend the reach of what the traditional IAM can do. And we tried to do that with a greenfield setup, because we knew from history that if there is some kind of business change happening at the time of, for example, a migration, you'll have to always revert back to the as-is situation. Because that's just the business that says so.

You know, you can't really do much about that. Of course, there were a few underestimations. So of course, on-prem components and legacy IT, yeah, it's always there. So don't forget about it. But you need to be very flexible in that way. And I think one of the things that we actually, well, we came to realize very recently, because we're in the middle of this, there's quite a few unknown dependencies that pop up when you're doing this whole migration, right? So in our case, we already knew that within Philips, there are some RPAs being used to query some data or check if an account exists.

And you can imagine, this can only get bigger in the era of all agentic AI, automation, your MSPs or other application teams saying, hey, can we check in your IGA tool if an account exists? Or is that actually the way it should be? So that's been more of a recent discovery that we said, oh, we need to be very careful. And we need to at least try to understand what is all talking to our platform. So more into a more defined approach. So we started preparing. I think the first thing that we asked ourselves is what breaks when we decide to move?

So as mentioned, we have some customization built in. Applications have customizations. Connectors have customizations. We had to at least understand what's going on. So for the majority of the functionality that we implemented ourselves as customization, so not based on any business demand initially, for those, we went back to the stakeholders that we're using. And I asked them, should we actually do it this way? So there can be multiple examples. But I think one of the more prevalent ones is that data retention, account retention.

So we have customization built in to retain accounts for litigation purposes. Fair enough. We went to the team and said, hey, we thought of this 15 years ago. And it's been moved over ever since. Do we still want to continue this? We don't have the limitation anymore. We don't have the capability to replicate this. We don't actually want to keep this in. What can we do? So we did research. And especially, I think also the vendor helped us a lot here. So they basically took in, looked at the landscape and said, hey, this will work. This is not going to work. That's really important.

And that input should drive, basically, your design going forward. So that's what we did.

Of course, I mentioned here communication. Because at some point, you'll have to start talking to your stakeholders, right? So the communication is where we started. So we already spoke to those key stakeholders that we have. But there's more. There's key users. There is application owners. So we had to send out a sort of general communication. We told them, hey, we're going to migrate. We had walk-in sessions. We basically walked them through the entire plan that we had drawn up by that time. And we said, look, this is our high-level plan. This is our high-level design that we have.

And we'll get back to you to talk about specific design changes that need to happen. And as I mentioned, we have about 300 applications. So not all of them are directly connected. But those were a lot of interviews.

And yes, it takes time. But please do it. Because you need to involve them in the project. And I think during the whole high-level designing, we also realized that because we are in a certain time constraint, you try to move fast, right? But do your work. Do your research beforehand. So we took already, let's say, almost a year and a half at least to prepare ourselves. Do your research. Sit down with it. Just take some time to really look at it and understand it before you just dive in and say, yeah, the vendor tells me it's OK. So let's move ahead with it.

There's a lot of more internal stakeholders that you need to convey. And especially in an enterprise like Philips, I think we discussed it also and heard it more in other presentations today and yesterday. Enterprises take time to change. So try to plan ahead for it as much as you can. Then more into the execution. So that's where we really got into the nitty-gritty redesign. So of course, our vendor already told us, hey, look, you're connected to this ITSM tool or to any Salesforce tool or whatever. It has all kinds of customization in it. That might not work.

So we sat down and let especially the vendor drive this conversation and say, look, we think we need to solve it this way. So we gave our vendor and our implementation partner the use cases and the business cases that we expect of them. And we let them take the lead in translating these requirements. What you need to make sure, though, is that as part of your SaaS transition, you have a lot of little improvements that you need to make. Some things don't work as part of the migration. And some of them are low-hanging fruit that you can say, ah, we'll include it, you know, small thing.

What we, or at least what I realized, is that that's a snowball. So if you say, ah, we can take this one little thing and this little thing, it really, like, blurs your scope. So please try to stick to the original plan that you make. And I know it's very hard because you see all these little improvements. We can make the business happy, but really try to frame as in, this is what we want to cover now within this time frame. Whatever else, make a nice backlog, create your user stories.

We'll take it afterwards because in the end, what's important is that you complete your migration because that's going to cost you, right? So there's a few things that we would do differently. I think I already covered it mostly, so I'll keep it very brief here. So making designs can never start early enough. That's at least for us what we said.

Look, just start early. Try to understand why something was implemented. If you are in an enterprise or in a company that's going through many changes or even reworks, layoffs, whatever, there's a big chance that knowledge is lost, especially something that maybe it's not directly IAM related, but can be of impact as part of your program. So it's important to make sure that you document this or try to understand all the information beforehand.

Yeah, first-time write does not exist. So as I said, it needs to be a bit of an agile approach. So your plan needs to be clear.

However, there will be a lot of dependencies and things along the way. So what we did is try to really divide it into smaller priorities, batches of things that we want to move over and try talking to the application teams in that way. And also the responsibilities. So as I mentioned, we are working with many stakeholders. I think it's also very important that you need to make sure that you divide the responsibilities and really say, look, I need you to solve this. Work with us, please, because otherwise it's going to hamper everything. And if that's needed, escalate it to management.

Get the buy-in is what I would say. So really make sure that all that's documented. So I got a really nice quote, who writes stays. So I'll just take that one. I'm not taking that one for granted. So where are we now? So as I said, I never said we're done. We're actually right in the middle of this. So I'm enjoying the time at EAC, of course, but no, we're still right in the middle of it. And we're making some good progress. So as I said, we removed a lot of customization because we're trying to use the system as is.

And if you look at the whole scope, I think 25% roughly of our system was customized. That's gone. We're not taking it. And of course, this came together with a lot of other projects that we tried to start alongside of it because we didn't want those dependencies to happen. So we said, hey, look, we want to do this, but for that, we need more. So we defined our high-level approach, a roadmap, and that flowed into multiple projects and initiatives to really improve. So as mentioned, our IGA. So we're preparing our June go-live with the highest prio applications.

So think about your HR source, your directories, ITSM, and all other applications that are relevant for our quality system that need any additional testing because the lead time is long. And as part of our PAM migration, which we're also migrating to SAS, we're already targeting completion in the coming two months because the amount of scoping was, of course, a bit less than what's IGA. So just to summarize really short, what I would focus on is stakeholder engagement. So as I said, it's a given, but don't forget it's really important.

And you need to have everyone feel part of this project, feel part of this change, because otherwise they're just going to say, yeah, but it's not important for me. And that's what you can't have in a project like that. What we also said is use SAS as designed. So don't try to fit your custom requirements into something that doesn't accept it. And leverage the vendor expertise to help you translate your business requirements into technical implementation plans. Manage expectations.

So I think I kind of combine it with make sure that you define the scope, make your plan, and don't deviate off of it. And how you want to sell it to your business would be maybe like we did, is to sell it as a technical change, because in general an IGA system takes care of onboarding, offboarding, and of course some other things, but your business as usual shouldn't change. Of course there can be different procedures, there can be different flows, but the normal end user that's not every day going to your IGA tool to check their permissions and do access reviews, they shouldn't know this.

We really kept it simple and focused and make sure that these IAM systems only perform the IAM tasks. So of course it's nice to say, if a business team comes to say, yeah, can you provision this to us? Or can we additionally do something like that?

It's IAM, right? Can you manage our accounts? There's always some additional side requirements, some additional step that they want you to do. Can we build our RPA bot in your platform? Because we need to check if accounts exist or something.

Yeah, no, it happens. It's what we've noticed, but we need to be really clear and say, look, does it have anything to do with access decisions? No? Then we'll have to look into it further and find a different way because it's just not going to help us.

And yeah, with that, I'd like to end. Thank you all for coming and happy to take your questions. See we have some time. Thank you very much, Peter.

Anybody, one question we could probably still squeeze into the schedule. Oh, we have one.

Hi, this is Farah from Allianz Benelux. Looking at your roadmap, you mentioned that you're still underway on the progress and changes come with struggles. How do you manage the pushback comments from the business? Because they are the ones feeling the change. And I asked the question because we have exactly the same as you. So I want to a little bit hear about how you manage the expectations, the struggles, the comments, and the pushbacks. So what we did is mostly reach out to application team, right?

Because they're the direct people that work with your system and they're the ones that are most impacted initially. So we also gave them the responsibility to say, hey, please involve your stakeholders and bring in all of the concerns if needed.

We, of course, use our internal communication channels to keep people posted about any progress. And as I said, I think some of the feedback will still come to us. We don't know yet, but I think migration, it's changed. There's always resistance to change. I don't think you're going to stop it, but we made sure that everyone at least takes their responsibility in communicating to their area of influence because I don't know everyone in Philips. I wish I knew.

But no, I think that the application team should take their responsibility and that should help drive less resistance. Okay, awesome.

Peter, thank you very much again. Thank you. And bye.