Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor with KuppingerCole Analysts. And so is Patrick. Patrick is my guest today and he is a lead advisor with KuppingerCole Analysts.
Hi, Patrick. Good to have you.
Hi, Matthias. Great to be back. Great to have you. And we had a very successful episode just a few weeks ago when we talked about not everything is IAM, which rang a bell for some of the IAM owners that we're talking to. And we want to continue that discussion in some shape or form because this actually leads to a topic that you have been covering at our Identity Fabric Impact Day in Munich just a few weeks ago, and which much more importantly is a topic which strikes us more and more when we talk to our customers, to our peers in the industry.
And this is the topic of a target operating model, which sounds very abstract and very business style, but it's really important. So first of all, a few sentences. What is a target operating model? I would say, yeah, or to keep it in a short summary what it is, it is actually a tool which helps you to distribute responsibilities in the organization, no matter if it's IAM. But IAM is very important to do that. It can be applied or is applied in various areas. But here it becomes crucial as we have so many people, so many organizational units involved when talking about IAM, when executing IAM.
And therefore, yeah, it's a necessary tool to actually distribute responsibilities. Yeah, fascinating. And I think that is something that many organizations actually are struggling with because IAM typically is a technical and IT discipline or traditionally at least. So sometimes it's just a kind of learning process to say, OK, I think I did that. And the question is, why do I need a proper target operating model, especially in IAM or to put it the other way around? Why does IAM often fail when you don't have a clear target operating model?
Yeah, from my perspective, it is sometimes like either people doing things redundantly, for example, designing the processes for or designing the same process, for example, to join a process because they are not aware someone else is doing it in the organization and they have their own implementation variation of it. Yeah, because maybe there's also no template existing because nobody took care about it, for example. Yeah. Or even worse, a process is completely neglected or forgotten because the organization unit thinks, oh, the other one does it, but actually no one does it.
So these are the two scenarios that can happen. And therefore, a target operating model helps you to actually shape the responsibility around the things you need to do or you want to do. Right. I fully agree. And from a notion perspective, it really shifts IAM a bit from technical to strategic. So you need to take a step back and talk to more people to distribute these responsibilities. So you talked about that at IFID. And the question is, how do you achieve this shift? How do you shift an IAM from just being merely a technology task to a strategic operational business enablement task?
Now, that's a very good question. The thing is, when we were developing the new or the next generation of the target operating model for IAM, we are just collecting the tasks in the beginning. And then we started with our experience and also with some analysis methodologies to cluster the tasks. And we saw it's not only technology when we are talking about IAM. No surprise, hopefully.
It's also like a business perspective coming more and more into the play as you want to achieve like business-driven processes, IAM business-driven processes and integration, for example, with IT security and so on. And we also saw, and that should be considered when we are talking about IAM, we also need a management perspective who is, for example, in an organization collecting the budget, who is drawing the architecture, is responsible for designing the architectures.
We really shifted away from the pure technical task of customizing, of developing something and had a look at it as a full-blown picture of IAM and therefore designed the tasks and clustered them across these three categories, management tasks, business tasks and technology tasks. And they can also be mapped more or less to the skill sets you usually have in your organization and can distribute it accordingly, knowing that, of course, technology, you have more specialization. So it's not limited to this, but it gives you a first impression of how you can actually slice your responsibilities.
Right. That sounds like you have a proper blueprint in mind already.
I know, but also that we are currently refining that way of designing a target operating model based on organizations of different industries. But is there a blueprint of how you can slice these ownerships, these responsibilities across IAM? Is there maybe, I don't know, a logical sequence imposed that can be followed by assigning ownerships? So the result of our target operating model, of the core concept, of the core model is a cube, I would say. So as I already said, we have the three different kinds of tasks, these three clusters.
And then we have different, I would say, perspectives on them. So for example, talking about processes, which could be one of the tasks, we have three different views on it. First view is the design perspective. So we are looking at who designs it, who's responsible, for example, designing the joiner process. Then we have the execution, we define, they are like the execution of the process, the actual doing of it. And then the last slice, the last perspective that we have is actually the content, who delivers, or the input, who delivers actually the data work.
For the joiner process, for example, HR could be one of the responsibles here. And by this, you are giving a bit more depth to the model, instead of just talking about a task, yeah, like design or process, joiner process, for example, you are also having like the different dimensions and the responsibilities that might change because of the different perspectives. And that cycles us back to the episode that we did earlier, not everything is IAM.
And when you say input, when it comes to data being delivered to an IAM as input, triggering everything that is downstream in IAM and in the downstream systems, that is something that if you don't have this target operating model, that then stays with IAM because they need to clean up data, they need to reformat data and design processes based on just what they get. So target operating model design also means communication, talking to the right people, making them responsible, saying, hey, HR, what you're doing has an impact on us.
Please make sure that we work together well so that it gets to a proper process. So is communication one of the key starting points in getting to a target operating model?
Yes, of course. So I think the core thing that this model helps you with to get the people at the all around one desk, yeah, around one round table and to discuss actually the responsibilities. And of course, this fosters communication. So I see the target operating model that we developed more as an aid to start the communication and to start discussing about responsibilities, actually.
Of course, it aligns with the IAM reference architecture we have here at Kuppinger Kohl. So it also continues the models that we have. So you can actually utilize the reference architecture to refine the target operating model and to add more specific tasks for your organization. So and by this, you start the communication and you make the split between responsibilities explicit.
Also, you were talking like about HR already, but it comes what can also come to play are like third parties, external parties like managed service providers, for example, that need to be considered here, for example, when utilizing identity as a service solution or similar sourcing models. Right. So IAM is getting more complex, which is a good thing and which is a complex thing. So it's really challenging for organizations to deal with this new picture of IAM.
So also the IAM teams are moving out of the machine rooms or no longer somewhere in the basements, but really aligning with corporate goals and maybe that as a final thought to think about. You've mentioned these reference architectures, these reference models that we talked about from the identity fabric to the reference architecture from a capability perspective. You've mentioned several dimensions or two types of dimensions when it comes to structuring the target operating model.
If we take that step back, how does the target operating model and in the end IAM service delivery fit into the bigger picture of business evolution of service delivery within an organization? Will this help there as well to get more clarity? Of course it will.
Yeah, because it makes things explicit and scalable. You are, for example, when talking about outsourcing, when you're talking about achieving your business goals, you actually have here a powerful tool which helps you to organize the organization along what you want to achieve.
So if you are, for example, designing your IAM architecture alongside the reference architecture, then you have now a tool which translates the strategic view also in a target organization, target operation model and I think therefore it is a powerful tool that can actually help to organize your daily operations and to ensure that nothing is forgotten and nothing made redundant or executed redundant. Absolutely, and so we are back to traditional tools like Rocky matrixes and KPIs, KPRs, SLAs. So the way to formulate that will end up in these more or less tools that we are used to.
Somehow you can take this or the input you have then generated from the target operating model also or from this picture that you then gain also to RASI matrices. You can also utilize it for defining your KPIs, your SLAs, your OLAs, whatever you want and make it contractual. So it is actually then the next step. It is the bridge, I would say, between the methodologies we have here and the well-known tools to bring the business perspective together with the IAM perspective.
I think, yeah, it is a bridge. Right, before we close down, typically when I moderate a panel at an event, I usually have one question that I give all the panelists to give. For example, what is your first recommendation for achieving something? You are my only panelist, so I give you three questions. What are the three things an IAM leader should do in moving towards a proper target operating model? This will not happen within a week, but what are good first steps to take? Three ones.
Yeah, first thing I would say is lead by capabilities, not tools. Ensure that you are, as we are doing with the reference architecture, we are starting with the capability, not the tool, and not build our organization around a tool rather than building it around the capabilities. Then fill the grid from your perspective.
Yeah, take the three dimensions that I have per task, design, execution, input, and start alongside the reference architecture to understand what is done, what needs to be done. Write down the task, take the reference architecture as input, and describe what you have already. And then you might realize already where's the gap, yeah, or where you have the redundancy.
So you can do it, do it on your own, and yeah, then you're actually also able to standardize and, yeah, kind of utilize the cross-application or cross-tooling capabilities, for example, in the management direction for designing integrated architectures. Yeah, so utilize the tool to actually start talking with also not your IGA or focus on IGA, focused on PAM, focused on access management, your IDP, start to like build a bridge also between these tools by the capabilities and to have a holistic view on your landscape and your tooling.
Right, and one thought that just came up in the back of my mind, you've mentioned that earlier, and it was someplace hidden also in what you just said, it's a contract, right? You're making people responsible. It's not only saying, hey, we have a nice structure and we will work with like this starting tomorrow, but there is reliability, there's liability, there's responsibility hidden in that. So it's a contract. So if you do this, then let's do that. Am I getting that right? Yes. So based on this, you can actually then formulate contracts if it is necessary.
External providers take the explicit split and then put it into a contract and take this as a foundation to negotiate also the terms of the corporation, for example, also with other organizational units, utilize it for defining their responsibilities and assigning them. Right. So I can only deliver IAM capabilities when I have proper HR lifecycle processes behind. So this is really a one-to-one connection. So that would be a starting point. If you do your job adequately, I will do my job adequately. So it's clearly a contract.
It's an agreement that you can just phrase and put down and say, okay, this is the basis of how we collaborate. That's an interesting thought. So it makes things much more reliable with an organization. So it's no longer just an IT capability that's just there, but it's something that serves a purpose and it does that based on proper rules, based on the contract. Final thoughts from your side before we close down, what will be the next step within Kupinger Coal? How will we evolve the target operating model? Yeah. So as I said, I have presented the first version on IFIT.
So now it gets out into the world. Yeah. And we are applying it in our organization, testing it actually.
And yeah, I'm also planning to put some or write actually articles about it. So yeah, be curious, be keen about what might be published in the near future on kupingercoal.com and have a look if you have thoughts about it, reach out to us. I'm happy to discuss this topic with you. And if you need assistance there, of course, I'm also lend a helping hand. That sounds great. So watch this space. If you have any questions regarding this podcast, regarding everything we do at Kupinger Coal, please leave a comment for this episode.
If you're watching this on YouTube, just in the comment section or send us a mail, send a mail to Patrick and or me. We are happy to reply and we will reply. We are keen on getting in touch with you. Let us know. And Patrick, you will provide more research, more input based on the advisory work that we're doing in the near future. So thank you very much, Patrick, for being my guest today. I think this will be a topic that we will follow up again until then, looking forward to having you soon as a guest in this podcast. Thank you. Thanks a lot.
