Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor at KuppingerCole Analysts. And so is Patrick Teichmann. He is a lead advisor with KuppingerCole Analysts. He's been a guest already once, but here again we have a topic to discuss, which he, as a seasoned advisor, can present perfectly.
Hi, Patrick. Good to have you.
Thank you, Matthias. Great to be back. Great to have you. And you suggested a topic, and we're running up to Identity Fabric Impact Day. And this is so much not a technical topic, which I really love, so that we are really looking at a topic that you, as a practitioner, that many organizations and especially the IAM teams are facing. The main topic is not everything is IAM. First of all, what do you mean by that? First of all, before we go into deeper questions, why is not everything IAM? Yeah.
If you look at identity, sometimes you could be thinking that everything is somehow connected to identity. And this leads to a very practical problem in organizations that a lot of organizations tend to assign a lot of different responsibilities that might sound like IAM, but are not at the core, to IAM teams, to IAM organizations, and think it fits their best. Although there might be not the necessary skills or the necessary knowledge to really drive this topic. And therefore, this is something that I have experienced quite a few times at different organizations in different roles.
And therefore, it's a topic that, yeah, I'm always keen to discuss. I always said, once I retire, sometimes in the future, there should be one sentence by me that should be remembered by everybody. IAM should not solve HR problems. And I think that is part of the overall game. And this is something that I learned in the late nineties, and it has not changed up until now. But to start with the questions, why is that? Why do IAM teams so often become the fallback for unresolved ownership of problems, of tasks in other parts of the organizations? Why is that?
I think one of the core things is that a lot of IAM teams are equipped with a platform. So a lot of IGA tools, IAM tools in a broader perspective are very flexible and offer quite extensive solutions to solve workflow problems, for example. And therefore, a lot of organizations think, okay, that might be the right place to solve our very custom problem in terms of different areas of challenges that organizations face.
So, but that's also actually an organizational problem. So there is a lack of ownership for individual tasks. So they need to be put somewhere. And if I think back, the usual thing I can think of is the management of external users. There is no proper platform for that. So the question is, hey, you have this nice IAM workflow, self-service engine thing. Can't we use that for the creation of external users? And the usual answer you should give is no, because there should be a proper process upstream for that.
So that's, and then we can inherit this data. But can you share concrete examples from your experience?
Of course, not naming organizations, maybe a bit of pseudonymizing, but can you share some examples where that actually happened and where it absorbed manpower, women power in teams that would have been better spent for something else? Yes. And there comes a very well-recognized use case that, yeah, I can remember very good. And that is about, yeah, we need the manual process for onboarding internals. And I was asking, why is this the case? We have an HR feed, yeah, and the data comes from there.
And there's the thing, yeah, sometimes people show up without a signed contract and therefore we need, and HR only maintains the data once the contract is there. So if they show up on the first day with their contract in their hands and want to start work, we are not fast enough to onboard them. And therefore then was the requirement to, yeah, build a workaround inside IAM to, yeah, have a kind of quick onboarding and then later map the identity to the HR data.
And that of course increased, yeah, the complexity of the solution, but also then require that there's another input form for creating these identities as well as then doing the mapping and so on. So it created a lot of organizational overhead by having, yeah, not the up-to-date data to the right point in time. So that sounds like a recipe for chaos, actually, because you need to fix things afterwards. And I think that's one starting point. Any other examples that you want to share or that you might want to share or can share?
I think it is also, or what tends to happen is when you are touching with an IAM project, certain access management tools, yeah, that you have in your organization that grew organically and now no one really feels responsible anymore, but it's used quite frequently. And the thing is then sometimes, sometimes you inherit the responsibility by touching it by somehow the necessity to clean it up to some extent during your project. And then at the next day, you are now responsible, yeah, might see yourself responsible in the asset management tool by just having asked for some basic data. Yeah.
So this is also something I know very well where responsibility comes through the back door. Right. To put it positively, IAM teams are usually very much invisible because they are doing things and they are doing processes. They are implementing systems that are employee facing, that are external facing, or external users facing. So they have this visibility and they are in the best of all worlds. They are understood as being competent. So they do their stuff, they do it properly. They are understood for solving issues.
And next time they are sitting in a project room and there is a new task to delegate, chances are that this magically turns into an IAM challenge. So this is something that I've seen in many times as well. But there's a danger behind that. There's a risk behind that. And let's maybe talk about these risks. Now you have taken over this responsibility. You are doing it properly. You are solving that issue. What's the downside? I think if you have not streamlined your strategy with what you're taking over the ownership for, then you are running in a lot of risks.
I would say first one is you're doing something you might do not have the knowledge for. Yeah. So this means it could have negative impact on the service quality itself because a team is doing something they don't have the required knowledge or skills for. So it also possesses a risk in terms of the service quality. Another thing is that if it just bumps into your team and you take over the responsibility, maybe you get one employee from the organization, which is also shifted to your department for doing it, then you have to... That would be nice. That would be nice. Yeah.
Sometimes the idea is, okay, you don't get any additional FTE, but just do the work. But if you might get it, you have to think also about the business continuity of your services that you're offering. Yeah. Do you have enough personal to do it during sick leaves, during vacation time? Yeah. If you have any opportunity to scale externally? Yeah. Do you have the proper market knowledge to scale externally? So when taking over a responsibility that is not core of your business, you run into a lot of risks, maybe also into issues, if they're materialized.
And then you have to really rethink, how do you want to tackle these ideas? And they might include a complete rework of your operating model. Right. And just what you said, the operating model, as I mentioned before, and this is not necessarily the commercial break here, but I know that you will be talking about the target operating model at the Identity in Fabric Impact Day. And I will be talking about presenting and organizing your overall IAM service alongside or along the lines of the Identity Fabric.
So getting to a portfolio-based service delivery platform for all types of identities, but focused on the services you want to provide and not those that you inherit from somewhere. So really defining what you actually want to do and putting a price tag on that and delivering it with SLAs, with KPIs. That's what I will be talking about, at least as a kind of slight hint, but will be a topic there, how to operationalize the Identity Fabric there. But what you said, target operating model and maybe my service portfolio as the basis for delivering services.
Is this a way to solve this issue, at least partially? I would say it's a good starting point, yeah. I think before it comes, of course, with your strategy. What strategy do you follow? What strategy do you have? What do you want to accomplish with the services you're offering? And I think then to develop in line with that, a target operating model, which talks about which service are you offering? What is needed from the different areas, like the business areas, from the development teams?
IAM is a spider in the web, so you're always demanding something, requiring information from business application owners, from process owners and so on. So you have to really integrate with them. But on the other hand, it's also the point that you have to have a proper ability to scale. So the thing is, during the execution of your strategy, there might be changes in your environment that require you to onboard additional development capacities or for application onboarding, for example. So all of this requires really a model that supports your strategy.
And therefore, I think, yeah, then continuing your strategy with a target operating model is a quite good idea. And therefore, yes, join me in my talk where I elaborate how you get from the IAM reference architecture then to a target operating model and what questions you have to ask yourself to have a really sustainable IAM target operating model. You've mentioned the IAM is the spider in the web. So one question to answer is, where does this web end for me as IAM? So where's the boundary? Does my ownership end? Where are the interfaces that I have towards other teams?
And usually, they are easy to identify. This is cybersecurity, this is HR, this is governance teams that are not doing the actual access governance but go beyond that, IT, GRC, but also data protection, the CISO. They are all stakeholders that you want to liaise with but not necessarily do their jobs. So how can you establish these clearer boundaries? Is this a contract thing, an interface definition thing?
Yeah, I would say so. It's not only to have a contract. This might be the first thing but also the second step to have like, yeah, an assignment of clear responsibilities. Welfare responsibilities can only lie decentrally, yeah?
I always see IAM as someone who, of course, or the IAM team, the IAM platform, the IGA platform who supports you in fulfilling the policies and so on but the responsibility to really maintain the data, to be compliant at the end, lies in the organization and we are enabling them with our tools but at the end, you need to make everyone aware about their responsibilities to maintain the organizational targets at the end and yeah, of course, a contract is the first step but then utilize things like, for example, a RACI matrix or a RASCI matrix, yeah, the extension by a support function to really make it work for you and to also have your clear boundaries.
Where does your central responsibility end and where does the decentral responsibility start? I have this additional saying, I've mentioned my first saying already. IAM is always best when it's done collaboratively, when you're working together with people, when you are, and that's a good thing, a center of competence for what you do, which is IAM, which is the processes around that and you enable others, you make them able to do their own part of the work on the other side of the interface by communicating properly with them.
I think that's also a good starting point, really being there for communication and then really defining, okay, but yeah, I could do that but I don't want to.
In the end, also from time to time, using the word no can help in that and it actually makes them and the IAM team improve their overall work and their collaboration and this is part of this clean contract perspective that we discussed already to say, okay, yeah, this is your part, this is my part, this is the handover, you agree to providing a service to me with a proper KPI and the same I do for you, creation of accounts within, I don't know, five minutes or half a day, whatever it is, this would be a part of the contract.
So anything else that you would demand from your partners to remain effective from your side?
I would say what is very important at first for the IAM team, yeah, to really fund their know, yeah, so if there is the requirement or the, yeah, the necessity to say no to taking over a particular responsibility, just saying no is very easy without a funding but you can create your own intake framework that helps you to fund your know, yeah, understand your strategic boundaries, where does your central responsibility lie, where is it decentral and then also understand what is the knowledge I have in my team and if something comes in terms of the assignment of a particular responsibility, ask yourself, do I have the appropriate knowledge, yeah, does it complement my team or does it dilute and start to defocusing because of this or do I create sub-teams in my team and then now I just have a broader span of leading employees.
So these are questions you should ask yourself and then at the end what I already mentioned, ask yourself what do I need to have the operational continuity because the thing is if it is unassigned in terms of responsibility at the moment, it might be just kept alive, right, but if I think about now delivering a good service and if you're starting now with a new fresh IGA platform, IM platform, with a fresh team you have, then really understand the impact it has on your organization but this is the very big takeaway here, no is easier when you have a documented strategy.
Absolutely and I hope that because what you're telling is really directly from real life, from the experience as a practitioner and I can just confirm that usually there are these tasks that are leftovers or that have been taken over because of, yeah, they were lying around and nobody does it and the process doesn't work without that but when somebody of the audience listens to that and said I should get rid of this now that I've listened to Patrick, yeah, this is a task that is really no IM task, what would be and this is usually my question at the end of such an episode, so what would be a good starting point, so the three first steps to take to say, okay, this already has happened, I want to change that, I can get much better through this, where to start, three points, one.
I would say start with reviewing your operating model, IM operating model, yeah, define your ownership and if it does not yet then under define it and understand the limits of it, yeah, clearly draw lines and then start to map it to what you have, yeah, from a strategic perspective do a mapping and understand what does not belong here and then you have a starting point to look for, yeah, appropriate owners in the organization or maybe to fund also, you know, or your requirement for finding someone new in the organization for taking over and in the consequence then to also enable a transition, yeah, at the end of course, this is for the past, yeah, so looking at the past what you have already gathered what might be there but I always think it's never too late, yeah, really to create a sustainable IM target operating model but for the future create a decision list, yeah, understand what does the required responsibility or the responsibility you should be assigned require for skills, yeah, what is the knowledge that is required, what does this responsibility also mean to my organization and what would I need to operate it good or even better than it is now.
Matthias, from your end, anything else you would like to add or did I miss something?
Yeah, I think, no, you, as I said, when you came up with that topic I said, yes, please, let's talk about that because this is really an issue that many organizations are facing and that's because of this visibility that I've talked about too, so when you're doing your job properly let's add some jobs to that so because they can handle that, no, they shouldn't, IM is part of a service delivery when it comes to administration but also in cyber security, in business enablement and this, as you said, needs to be clearly defined, you really need to know what is my purpose within this organization, where can I serve this organization best, whatever organization it is.
You are responsible for propelling the overall IM platform to get better over time, we are talking about so many interesting new technologies and topics, say NHI, then you need to have these capabilities and the know-how available and you should not create personnel or staff numbers for HR, so this is really not your job and when somebody says, hey, I cannot handle these cross-organization movers because there is no handover in the HR system, can I use IAM for that?
This does not belong there, this is not the task for an IAM, you will be inheriting the data that comes from these two systems, make sure that you get your stuff done and that's the story to tell, this is not always easy, you need support and I think that is the answer to your question, you will need support by those who understand the bigger picture, you do, of course, your IAM, we understand bigger pictures but you need to have support by somebody who actually says, no, this is not an IAM task, this is a cyber security, this is an HR task, this is whatever task and telling that story, I think, is very important to make sure you are in that corner where you belong to and this is not a derogatory sentence.
Doing IAM properly is a challenge enough, especially with growing regulatory requirements, with growing cyber security requirements, with identity being that area where attacks and threats are increasingly aiming at, there's enough to do there, not get to everything else that somebody or that nobody feels responsible for.
Long answer, I hope that answered your question and anything to add from your side, also looking at Identity Fabric Impact Day in September in Munich and your talk and my talk, you both will be there, we will be both moderating, so for those interested in getting to know these two guys more in person, join us. Yes, and open for discussions, open for your views and maybe we can come here again together and discuss the insights that we get in practical.
I think one last sentence I would like to address here, if you sharpen your focus in IAM of your team, you will improve your service quality too, because you have a sharp focus and do what you are intended to do and not 100 parties at the same time. Nothing to add from my side, thank you very much Patrick. For those who are listening and those who have questions, as Patrick said, if you're watching this on YouTube, leave a comment in the comment section, we are monitoring that.
If you have any specific questions that you would not like to put on in a YouTube comment, reach out to us, we are easily to be found at the KUPPINGER.com website and the mail addresses are there as well. Reach out to us and if you say, okay, I would like, I always wanted to get rid of that task, can you give me a hint? This is not advisory sales, this is just give me a hint, how can I tell that story? Please reach out to us, we will be happy to discuss that with you.
For the time being, Patrick, thank you again for being my guest today, looking forward to having you again, hopefully again with such a real practical, real life topic to discuss apart from all these shiny new technical solutions that we're discussing, because doing things right sometimes is the bigger challenge than the new technology. Thanks, Patrick. Thank you very much, Matthias. Bye-bye.
