Yeah, a heartwarming welcome to one of the last sessions and I'm glad you're all still here to listen to this topic. So we, throughout this EIC, we heard a lot about agents and so on and how everything is already done by agents or could be done. But from our experience and practice, a lot still depends on the humans. And I would like to start with, yeah, some kind of reality check. So everything that I see in my environment somehow reminds me of IAM.
So I recently moved and here you see a tangled router hanging around the wall, which I ended up after calling my IT service provider about an issue. So it started, yeah. Everyone was starting to do somehow their part of the work, yeah. The service provider said, yeah, it's somehow has to do with a wiring. Then the electrician was called and so on.
They said, yeah, maybe somewhere else and so on. So I ended up in this situation. Everyone somehow did his or her job, but at the end I paid for with the result, yeah. It was still not working and no one took care about the whole. And unfortunately, this reminded me a lot about how IAM is working in organizations. Yeah. You have the user calling and you have everything built, your strategy and so on. The tool is deployed, but at the end in reality, it's not planned how it should run. Yeah. So everything falls apart when it's live.
And then this results in challenges and very practical challenges that we have in organizations that we see here. And if we have not planned it, then the strategy that we have is just a PowerPoint like you see it here. Yeah. So you have to really live it, live through it. So it's not just the tooling, although we just sometimes want to believe it. So what do we see if you have not planned throughout how we want to operate it? So first of all, ownership gaps.
When we deploy a tool, we have functionality, but it still lives unfortunately with the real humans in the organization, filling our tools with life, with the necessary information that needs to be done to understand, for example, the entitlements that we have, the identity information and so on. The next thing is, although we have a lot of tooling in our organization, not everything is tooling. You might still have disconnected applications. So you might have an IGA deployed, but still have not all applications connected, for example. So there you might have manual processes.
In your policies, you might state how they should be implemented. In your IGA, you might have it, but how is it about disconnected applications that you have in the central parts of your organization? And another thing that comes along the way, the tool is live. You might have a system integrator who is like doing the implementation, but afterwards, have you planned how you are handling things and operations with your services that might be outsourced and so on. So when we are nailing it down, it's not about, yeah, which tool can we now use?
Or I would love to tell you you have a tool which just simply solves all this for you. No, it's about the organization. You have to make your head around the organization, how you want to build it and how you integrate it to have it working, to make this explicit, what you are kind of expecting from the organization.
And yeah, to inform them about what they need to do. So we started at Coupier Call, grounded in the practice that we have, what we see, yeah, in the organizations in reality and try to bring it together and kind of, yeah, design a model out of it that, yeah, organizations can work to start this journey. So I have to inform you, I will not have the solution for everything, but I give you somehow a framework with what you can start, which you can tailor to your organization and start this journey and, yeah, inform the people about their duties.
So first view that we have is we tried, or when we are looking at the IAM departments or the people who are working with IAM, we try to separate the tasks they need to do usually. So when you look first, everything, everywhere, when we are doing IAM, talking about strategy and so on, we need to have someone who is setting the direction with the architecture, with the strategy. This requires particular skills. Then we have the functional perspective where we are talking about processes, requirements, really about what, how IAM should look like to fulfill his or its stakeholder requirements.
And then last but not least, technology. The engineers, the people who are developing, the solutions, implementing them. That helps already to kind of sort the field in the first view. Then when we are now talking about the tasks that your organization, your IAM organization has to fulfill, then there comes a next view. When we are talking about the functional aspects, the management, the technology, this has most of the time like two or no, three views we should have a look at, especially in IAM.
The first thing, someone really designs it, who designs the strategy, who designs the architecture, who designs the processes, for example. So you need a particular set of skills to really fulfill these tasks. The next thing, the daily doing, operations, execution of all of this. How are the processes running in the organization? Who's really clicking in the processes and so on? So who's doing the day-to-day work, the operations? And the last thing, what is very important when we talk about IAM as spider in the web, we need the organization to deliver us data. For example, HR events.
We have the join and move a lever design, for example. We have it implemented in the solution it runs, but it needs HR data, for example. And these are very important things we need to make explicit.
Yesterday, we had here a new format where we were talking with enterprise customers. We have already brought up this discussion. Is your HR team aware what their data decisions, for example, or what their changes in the system are causing in the organization? And if you have not made this explicit and in an agreed model, then things probably fall apart when it comes to operations.
So now, bringing everything together, you see this wonderful cube. As I'm a visual person, I love to have this in a visual way. So you see now all of this combined. And no matter about what aspect of IAM we are talking, is it more IGA or is it more ongoing? For example, the identity provider, I have more or less of these standard tasks somehow. I know for all the different technologies, one or the other might be more important or less important.
So this is not all equally important for all the systems technologies you have in place, but this is somehow the starting point for you to start the discussion. You have now in these three layers, the different subtasks like the strategy, communication, architecture, of course, you have to look at the definition that I have, and are a lot more things behind. And you can then start the discussion, who is doing what exactly. Now to distribute this in the organization, we have like three different dimensions we currently have a look at. The first thing is the accountability.
And this is like for the first sorting, how to say, not yet like having a role behind it. But when you start with the first sorting of it, who is accountable? Most commonly we distinguish between the IT and business.
Of course, there can be parts that are shared, everything that is on the bottom, hybrid shared and so on. You should have like a real closer look at who is doing it.
Yeah, because when shared accountability is usually a problematic thing. So have a closer look at this. Next thing, distribution. Is it something you do with a central unit, for example, or is it something that you're doing decentrally in the organization, the application owners, for example, or again, hybrid? And then is it internal people who are doing it or have you sourced it out, for example, to a managed service provider?
Again, also the situation of being hybrid. So now let's bring it to life. I have brought and no, it's one thing up front. So why you should do this. If you do not do this exercise, you have unclear responsibilities. Tools are there. No one knows what to do. So this operating model gives you the opportunity to name the owner, to split design from delivery to, yeah, have not like a unsolved tangle or entanglement of responsibilities. And you can speak one language across the various toolings. Now bringing it to life. I took the entitlement management.
Entitlement management has some goals we want to achieve with it. I took it from the reference architecture, which is like the baseline for this operating model. You have to refine it and gives you the input about what you need to talk in your organization where you have to actually distribute responsibilities. I have put here like the four targets, what we want to achieve. It might be different for you, what you also foresee. It can be extended of course, but we want to achieve these privilege of course, and prevent access creep.
We want to have clean data in, so we need somehow providing data again, but also build then trustworthy reviews on this data and bring it together. We want to know who owns what in this particular capability and redistribute it to have accountability behind it. And this should result in meaningful catalogs that our users in the organizations can use, can understand. And then when they, for example, need to recertify that they can do effective recertification.
Now looking at the functional layer and the process perspective, I took this sample-wise to give you somehow an idea how it could look like. In the design, we have designing the role life cycle for roles. Then the actual doing, execution, we have requests, approvals, revocations, so the day-to-day doing, what is happening and what do you need, the application information to make it actually work. Now let's distribute it. Who is designing the role life cycle? Let's start with it. Usually the IT, the IAM team in a central position and of course should be internalized.
Execution, who is doing the requests? Who is doing the approvals and so on? That usually happens then when we are talking about roles in the business. Decentrally distributed, still the internal does do it. And then finally, the input is also delivered by most probably somehow the application owners usually, then it's IT, decentrally and internal. As you have recognized, I have already brought up some people that we see here, some roles, some really organizational roles that we have here. How do I get now to these roles? And this might be now looking a bit confusing, but I already warn you.
So bringing all of this together, the tasks that we have, management, functional, technical, gives you already an idea of what skills are required to actually understand who is needed. The views bring another layer of capabilities, skills, the particular person or the role that needs to fulfill it has in addition. And now bringing this together with the dimensions that we have, responsibility, distributing, distribution and sourcing, combining this with the capability, you get an idea which role is needed.
And then when we are combining this now for entitlement management, I get somehow these three roles that you see here and that I can use afterwards then to combine this all together and really map it to the corresponding responsibilities in my organization. So what do we take from here? What can you take with you tomorrow and how you can start really the journey in your organization? Five steps I would give you here. Lead by capabilities. Take the capabilities from your organization. Take one and try this exercise. Start with it. Start small. Understand the implications for your organization.
Then really start to differentiate design, execution, input. What is needed from the different perspectives, from the delivery views? And really understand also in the comparison today, where are the gaps? Standardize subtasks. Utilize across the different platforms that you have. For example, the governance, the policies that you might have across various tools that need to work together. Utilize it together. Bring it together and really combine IAM to be not working as the silos that might be in various organizations, but start to understand everything really end to end.
As I said, very important. The view that really drives us in IAM, we need the organization around us that delivers the input and gives us the necessary information to make our processes work.
And yeah, really think through each and every capability throughout to understand what is really needed. And then you can use always the reference architecture that we have at Küpinger Call to refine your target operating model. Also to assess the status quo, of course, and then to define where you want to go so that you have really a target operating model. Thanks a lot.
Thank you, Patrick. Thank you. Any questions from the audience for Patrick?
OK, not really, but I have a question. Yes, please. The topic of people and organization. Why do you think it is overlooked so much? Because I think if we are or as IT people, we tend to look first for the tool. So as I look at my previous times, I look into organizations. It's very charming that you look at some vendor and he's promising to solve everything for you. And you want to believe it.
Yeah, you want to believe it because the organizational change that we have in IAM, which is required to make it work, it costs a lot. It needs the communication, convincing people. And also this one is like making HR explicitly responsible for what they deliver and what they cause. This is organizational change that is not easy. And of course, there is pray and hope easier than doing the change. That's so true. Thank you so much again. Thanks.
