ITSM and IGA - How to Integrate Two Key Infrastructures Right

Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth, I'm an analyst and advisor at KuppingerCole analysts. My guest today is Martin Kuppinger, principal analyst at KuppingerCole one of the founders.

hi, Martin. Hi Matthias. Thank you for asking me to do that conversation with you.

Yes, and I think it's an important conversation that we should have because when we're doing advisories or when we're talking to end user organizations that we support in that process of, for example, implementing large scale identity and access management solutions. There's one question that we always come across and that is the integration of it.

Service management and identity and access management, all of these organizations that we're talking to have one or the other it service management tool in place where they order their machines, where they order an account where their audit paper and anything else that they require, and the integration of this into an overall identity and access management. That is a challenging question. Isn't it? It is interesting to see that there's really a 100% ratio of organizations asking that question sooner or later.

Obviously we also push organizations to ask the question, but it also pops up everywhere because as you said, there is the it service management tool and there's identity and access management. And that's also requesting services. It's about how do I get my access? And it would be identity measurement. And how do I get my smartphone? That would be it service management.

And there's an overlap very obviously when it comes to application onboarding, because the application then is in some way in new service at the level of it, service management and the access to it, the application is something that affects it, that affects the access management that affects privileged access management. So had linkage. And there's another one which is about fulfillment.

So I, it service management. We also have a tool that commonly support some type of ticketing, and we have a lot of manual fulfillment in identity and access management. So there are various areas and that is what brings up the questions of the customers on how to integrate by the way. And I think you also have served as much as there's another question, which is closely related to that. And sometimes pops up first before the integration question is discussed, that is, can we replace specifically ITA with the it service management, Right.

And that is really an important question because when, where is, where is the, the point where you needed to change systems when it comes to requesting an account rec requesting organizational roles for a new user of, for yourself, and then requesting access to a system where that would be something that is usually located with them within an IAM request management tool. And I think that question is more or less natural to say, how do I do request this additional functionality, which is access to an application? When do I leave my ITFM? Yes.

And the first question would be, why can't I just use my ideas and let's maybe start with deadline because I think this is really the entry point also of the conversations I have and the answers we have on that is very important to then come to the next step. The how to, so why or why not, why not use your it service management as your IHA too. There are a number of reasons.

First, a lot of common functionality in IGA tools, such as excess review, such as sod policies, such as multi level role models, such as access analytics are available out of the box and AIG, but are lacking in ITSMs. So you would need to rebuild them in your ITSMs tool, a lot of development, a lot of maintenance of what you have developed. So that is a challenge. And you should be very careful with that. Second it S M if at all, comes through some very limited connect firs to target systems, ITA delivers usually a huge range of connectors to variety of target systems.

Again, that would be an area where you need to develop a lot. If you don't rely on machine and assert aspect, which is probably the most important one is H and its M play at a F fell a different level of granularity. When we look at the services. So ITSMs looks up Rosser, huge call screen services. So you request a service or your requested wise, or your request.

As I said, a relatively broadly defined cost grade service in access management. You say, I need access to that functionality and that system, and commonly, we are talking about thousands, tens of thousands, hundreds of thousands, or millions of entitlements, depending on the size of the organization and how you do it while it service management deals is relatively low, low number compared to that of services. So it's trust that built for that. And you would need to add a lot of capabilities manually.

And then is the, I think the most important part of the hazard on the why question, why not to use its service management to build your own solution? Yeah, I think the G in IGA is also one of the important aspects because governance means also logging means auditing means making sure that there's evidence for everything around assigning and using access. And I think that is something that you just cannot implement in the same level of detail and at the same level of confidentiality that an IGA system comes with out of the box. So that's really something that it's not used for.

Their looks the same from a high-level perspective, you are requesting something, you are approving something and something happens in the background. But as you've mentioned, there are doing that on different levels of detail and they are just doing it for different aspects of the daily work of an organization. Yeah.

But what, what do you trust mentioned is also an important element of the various, how to questions, because the challenge on the other hand is if you have an ITFM tool, which is your starting place, then you have an IGA tool where they request specifics are handled, and then you might end up again, and it service management tool for the tickets which need manual fulfillment. Then you have two tools and to understand where in the processing is, your request becomes somewhat more complex. So you need to have a close alignment at closing the creation of both worlds, ITA, and TSM to track.

Where are you in the execution of requests? On the other hand, it makes a lot of sense to use ITA for that as the system where every single request for access flows through, because that allows you then to have one place where you can track all access requests instead of having it distributed across a number of systems. So the how to is from my perspective, and from my experience derive from many conversations, as many organizations, that there are two integration points between it, service management and Nigeria.

One is at the top where you come from, this is my portal where I request it services. And then I ended up in IGA for the specific access requests. And the second integration is about fulfillment.

So in IHA, you have some part of automated fulfillment where you connect to Microsoft active directory and you create a user account and all of a sudden automatically, but the vast majority of systems commonly is not connected automatically. So it's manual fulfillment, and then you create a ticket and the ticket ends up in the right TSM and distract. And someone manually fulfills that request executes on that request. Be it that user's grade be it that entitlement is granted or revoked B it's that as part of the application, onboarding new privileged accounts are created.

And the Bruce access management system, all these things are then done in the idealism. These are the integration points you commonly have. And so we need that integration, but we must not try to reinvent IHA by custom development on top of the ITSs tool, But an intern organizations should always think in both worlds when creating processes. So when there is an M in place brackets always, and you need to extend augment your existing IGA solution or created in a new, more modern fashion, you always should think of it as, as one important partner.

As you said, on the one hand being the front end on the other hand, being something like an enterprise service bus for manual fulfillment, where you can request something, get tickets back and approval back that things have happened. So there is always this, this tandem of, of its Emond IGA in place, but you should never try to rebuild functionality from the one within the other.

Yes, I have one seen an organization and it was not our advise, which spent three men years of architectural work in figuring out how they can sort of rebuild and re invent what the IHA tool already has in their ITSMs tool. And then they came to the same conclusion I had from the very beginning. And I told them from the very beginning that this is not the right way to do it. So they had stopped and did it more conventional, but you're absolutely right. We need to think about processes end to end from this is the browsers of access requests.

As it started, might start in the ITSs service portal. It might tell a link in some way to the IHA two, and it then might end up in it as I'm again, for parts of the manual fulfillment. And then we need to have this comprehensive process perspective and what you always or should have as we should have some, I would call it alignment of the UI. So the UI then used for requesting certain types of faxes or odd or IGA related stuff should be as close to the TSM UI as it can be. So that there's at least not a huge break.

So did there is that at least not a totally different UI, totally different user experience. That is what you need to avoid, but then it's a rasa straight forward singing. I think there's a simple rule as a footer, how to, if you learn that it's not in its ITSI and it would be a huge effort to do it right, such as segregation of Judy controls with all the policy engines behind them, better do it in the IHH. Don't try to reinvent things which are already there.

I think that leads us to one key recommendation beyond it is that we always had don't build systems yourself when there is existing best practices already available in an ideal world, even implemented and readily available in the products that you already have. I am processes are not that different from organization to another organization.

And this is really something where you can benefit from pre existing material pre-existing processes, experience that others have made also mistakes others have made before, and to avoid them, rebuilding it into an ITSMs is like starting from scratch more or less, and building an IGA solution for yourself. And this is really something nobody should.

Yeah, I think there's also one thing. And it's first, and I don't want to mention a vendor name here, but there's at least one first ITA tool building on one its platform in an integrated manner. So someone developing a standard software based on the ITSs platform, which extends and adds the IHA capabilities. And then you have a very tight integration, but you don't end up as custom development. So there are things happening in the market. We also working on Martinez probably will ask for hints on photo research.

We currently started the process of creating a market compass, which looks at the integration of leading IHA tools with the leading ITSMs when in the market. So to give a guidance on if you have that tool, which was in that case service now, which I say tools work better or lesser good with service now, because that will become more and more important to make decisions also with the context of how can I seamlessly or with little effort integrated.

Yeah, I think that is really important. So that could be a good fit for some of the organizations looking at that if their requirement is readily integrating with an existing ideas and platform, then that of course is an important factor when choosing a solution. And I think that makes perfect sense for them then as well. So you've mentioned already the upcoming market compass, I assume that there's also other research already available, at least for individual products like executive or even blog posts, maybe. Yeah.

We have a member that is leadership brief or will be a leadership brief soon, which looks at the standard concepts of integration. And as I said, there will be more soon. Perfect. And we can give advice.

Yes, exactly. That would be my next sentence as well. This is something that we are really doing on a daily basis, working with organizations that try to not try it, that I succeed in implementing such solutions, well-integrated into an ideas, but also well integrate into other enterprise architectures that are required when working successfully with an IGA solution. So if you have any questions around this topic or similar topics where integrating your IGA in an enterprise architecture, please get in touch with us. Just talk to us for a first call.

We will be readily available to talk to you and to discuss your individual needs. Just get in touch with us at KuppingerCole dot com and that's it for today. Thank you very much, Martin, for joining me today for this really well actual question that many organizations face, and I hope we provided some guidance here already. And if there is need for more, get in touch. Thank you very much, Martin. Thank you very much, but yes,