Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm analyst and advisor at KuppingerCole Analysts. And analysts and advisors are here today as well. So I have two guests today who will join me for discussing a topic that you don't want to miss. We want to talk about applying the identity fabric, a concept by KuppingerCole Analysts and the reference architecture, another and augmenting concept of KuppingerCole Analysts in real life, in projects.
And therefore I have invited Charlene and Kai as my guests who are senior advisors doing the real work with the real customers out there. Hi Charlene. Good to have you. Hi Matthias. Thanks for having me. Really looking forward to our conversation. Really looking forward to that. And hi Kai. Good to have you the first time in this podcast. Hi Matthias. Thank you for having me. I'm very excited and looking forward to a very good episode here. Right. And as I said, you are on the front. You are working with our end user organizations.
Of course, we don't talk about individual customers. That would not be fair. But we talk about the essence, about what you've learned when it comes to applying the identity fabric and reference architecture in real life projects and how it can be valuable. And the focus we are putting on that today is the topic of IAM maturity. So measuring where organizations are as a starting point for initiating a series of projects, a series of programs to understand where are you, what is missing? And starting from the beginning, of course, how do organizations begin assessing their IAM maturity?
Such an analysis. How do they do that? How do you do that, Charlene, when you deal with our end user customers?
Yeah, Matthias. Great question. So when we work with organizations on IAM maturity, one of the first things to recommend is a structured approach for the assessment. So what does that mean? This means using a capability centered framework. And what we typically use is the Köppinger-Koll identity fabric and the Köppinger-Koll reference architecture. And these frameworks will help us get a complete picture and a complete understanding of the organization's IAM estate. So one of the first steps in this assessment is then to talk about the status quo.
So where does the organization stand in terms of IAM maturity at this moment? And here's the important part from my perspective, is that these concepts and frameworks, they are not just a checklist to see if certain tools are installed.
Instead, we talk about whether capabilities like identity lifecycle management, are they in place? Are they functional? Are they repeatable? And are they even governed, right? So also another aspect to look at when we talk about capabilities is what are current challenges? What are gaps that your organization struggles with? So to summarize it, instead of asking, do you have an IGA tool?
We ask, do you have a capability that actually works end-to-end, for example, for identity onboarding and offboarding? Do you have access reviews in place? And are these processes reliable? And we might even ask, is onboarding automated for all relevant identity types?
So for me, the important aspect when using the capability-centric model is to have a common framework, which gives us a common understanding of IAM. We all speak the same language. And then we can use this framework to actually measure the maturity of each of the capabilities. Right. Anything to add, Kai?
Yes, absolutely. I really like your introduction, how customers usually do it and how we usually do it. There are sometimes quite a difference between those two approaches. That's why we, I suppose, go there and help them. And as Charlene already introduced, you need to have a very structured approach and then focus on the capabilities to really have a focused look on it and have an end-to-end view on the different processes to involve the whole company there.
One big advantage where you really can get a grasp on it to introduce a maturity model or levels of maturity to each and every capability. So you can say, okay, we rate them if we identified it in the beginning and have a rating on them. What state of the maturity level does this capability have? And that's where the crux comes into play. You really need to have a proper documentation on that.
I mean, we come there with our reference architecture and with our fabrics, which is already a documented piece of work, which already helps them to have this documentation. But that's not only it. Then there you need to apply all the learnings and apply all your knowledge of your company and introduce such level of scaling to the maturity levels and go on a very structured way from the beginning to the end. Right.
So when we look at, as you described, we're taking a step back and we're not looking at tools, as Charlie said, and we're not looking at how they are implemented, but we are looking at a capability, at a functionality that is provided through these systems and measure these towards or against a common scheme of maturity levels. So that is something that you are doing together with your customers. So it's not magic that we say, okay, let's look at this, let's look at that. And this is a medium level maturity. So there are defined levels of maturity, right? Maybe Kai?
Yes, absolutely. I mean, it would be good if the customer could do it by themselves. And it would also be good if we can do it for the customer all by ourselves. But reality shows that we have a good knowledge about our working tools and the customer has a very good knowledge about their environment. And so it's a really enforced cooperation to achieve very good results on this, to have a very good rating, as good as possible on the maturities, on the capabilities.
And the capabilities, I mean, we come with a defined set, as I already said, but we can only give it as a kind of a blueprint to the customer. And then we fill it with life, with the environment of the customer, which is always a little bit different, but overall quite the same. Right. So now we take the next step. So you're through, you've looked at all the capabilities that are relevant to your customer and you end up with a set of ratings and some are good and some are brilliant and some are not.
So the question is, how do you translate these results and how do you use the Identity Fabric for making the right steps? So we won't go to brilliant, brilliant, brilliant for all capabilities. So how can you get to tangible operational improvements? Maybe Charlie. Yeah.
So as you already mentioned, when we talk about the Identity Fabric from the architecture perspective, it's best understood as a strategic blueprint or a, let's call it a guiding framework that helps you to see on the one hand the big picture, but a lot of value comes when you actually translate it into concrete operational steps. And this is done by reflecting on the challenges you identified during the maturity assessment and also understanding the costs behind it. So for example, when you look at onboarding or access requests, ask yourself, where do I stand at the moment as an organization?
What are my current challenges and which capabilities address these challenges? And actually another important question to keep in mind is what is the desired state that I want to achieve? And by raising these questions, you will set the foundation for identifying areas of improvement while already looking towards your target state, which will later on be the goal that you eventually aim to achieve. So this will help you get a clear picture of, on the one hand, let's say, current state and challenges, and on the other hand, target state.
And it's missing in the middle to what is needed to be closed is the gap. And to close this gap, you need to think of actionable steps you can take, and these steps have to make sense for your organization. When we think about implementing the operational improvements, you have to keep in mind, what is my gap that I want to close? You have to come up with actionable steps that you defined, and they can look different depending on the organization. And you then need to implement these achievements that you want to create step by step.
So one example is that, let's say, user provisioning is still done manually, and your desired state is to have a fully automated provisioning process. You might want to have the desired state of automating the full process, which is a big goal, but you might put it into smaller chunks. For example, not automatically provision all systems in parallel, but let's say start with the five most critical systems and then take it from there step by step.
Yes, absolutely, Charlene. You are absolutely right. We need to focus there that we define actionable items and differentiate between short-term goals, which are achievable, and then more strategic goals, which align to the overall company's strategy.
And a very good possibility to really break this down and show progress there is to use KPIs on a different term or in different directions, where you really can track those defined actionable items and see how the progress really is going and if the performance of the overall actions is really targeting your real problem, or if you go into a different direction. And since we already spoke a lot about the blueprint and the reference architecture as a blueprint, as we learned, it is very good to have such a blueprint and it's kind of necessary to have it.
But in a project, you really need to treat it as a kind of a living guy, since as you go through the project, you solve different issues and overcome them. And over the course of the project, you really learn different stuff. And there you really need to be able and flexible enough to target new identified objectives and have a really good progress on the overall scheme. And not just looking on the initial focus target architecture, which you defined and drafted, you really need to work with the real environment and the real state. And this one changes day after day.
Yeah, I think it's also something, why do these projects start? They don't start, why? Because somebody says, I want to improve my IAM landscape just for the sake of it. This is not what you're doing. You do this for really tangible reasons. You have issues in cost, you have issues in throughput times and onboarding takes too long and auditor is unhappy. So there are reasons for that. Taking that step back, looking at the capabilities, decomposing also business processes into their individual parts within a capability model.
So onboarding, lifecycle management, provisioning, all of this plays together in its separate capabilities. But in the end, it's bad user experience or an audit issue. This is the reason why we're doing things and you are doing these projects. I think that that's also something to keep in mind. If they don't know what their maturity is, they do not know what their issues are and what their problems are. And to tackle them, that's the starting point. And to bring this together, I think that's also kind of the beauty of the model and the way of how you are doing these things.
So we know how to do it, capabilities. We know how to measure that and how to identify these different necessary improvements.
Next up, now you have a bunch of improvements, all important, all really relevant and all could help to improve the overall identity security posture. How do you prioritize effectively, put this on a roadmap, Kai? And that's the typical issue where we run into, as you said, we need to prioritize. And I think the major step is already then done to translate the pain points into the maturity matrix. And then we have the maturity mapping, which is of course always very important and needs to be done yesterday.
But if you take a step back, you can really decompose it into maturity and urgency and then really say, okay, what is our current capability strength? So how good are we? How is our maturity level? And then we have the urgency like business risk compliance deadlines. When is the next audit? Is it already overdue or do we have a real operational pain? Like you said, performance is very lacking behind. And then we really can construct our prioritization on the urgency and on the maturity to our priority or top priority levels. We can use a simple matrix and multiply them.
So if we have an urgency level and a maturity level, a very low maturity with a higher urgency is kind of a good indicator to do it sooner than later. If we have a very good maturity and our urgency is, let's say, not that urgent, maybe it's a thing for a later point. And there all companies are very different because the drivers are different. Some are more driven by operational focus because they want to have a very high user experience, a good performance. And there are other businesses which are very driven by compliance and by the regulators.
And therefore, you won't always have the same rating and matrix and the same following procedures. But in the end, the companies in general are kind of likely. And therefore, you can go with a similar approach. But in the end, each and every company is one of a kind. And therefore, you need to talk with all your peers. You need to involve all your peers, which is not only the project team which wants to improve their IAM. It's also the top management and other peers which are related to the IAM and the core system. And then you can really work out a priority for yourself.
And then it's just following a plan. Right. Your thoughts, Charlie. Are these the same or do you have different experience, other or just extending experiences?
No, I totally agree with Kai's points on the priority versus urgency. So in reality, everything is super urgent. Everything has top priority. And then organizations need to think of a structure to break it down. One aspect that I came across besides the urgency and the maturity is also the point of feasibility and cost. So even though you identified topics that are urgent, that have a high priority, it might be that these things in the implementation might lead to a lot of friction, might create high cost, might not be very easily feasible.
And this might also change the priority of these topics. So even though it's super urgent, you might come across factors that still impact when you will implement the solutions or the new process. One example that I might give is that let's say you have a gap, like you want to enforce MFA in an organization. And when we think of a technical perspective, this might be one click in the tool to activate that. Okay. So this might be considered pretty straightforward depending on the organization. And then there are other things.
For example, if you want to roll out enterprise wide roads so that the whole organization has defined roads that they can use for onboarding, for change of department, for everything, this can be a multi-year project, which will also have high cost. So even if it's urgent, it might be reprioritized due to other factors. But basically saying I can second what Kyle already said. Right. Very high on the list of the value of terms on the BS bingo for consultants and analysts are the terms big wins, quick wins, low hanging fruits. How important are they in that context?
Just to dig a bit deeper, I think proving success very quickly. So the quick wins, they are important to show you're doing the right stuff, right? Absolutely.
I mean, the list will probably go on with those terms, but in the end, it really showcases that it is important to show improvement and progress quite fast to the management. And that's where all ties together, as we said, defined and really small achievable goals in the beginning. Because otherwise, if you just sell the whole project to the management and then you come back after, I don't know, one and a half years and say, ah, we are done now. And the management will probably have forgotten that you are working and something like that.
Or even worse, they probably would shut down the project after two months if you don't show any progress at all. Right.
Of course, this doesn't happen to us. I would never say that. But pitfalls when it comes to things going wrong in such a project, what are from your experience and from what you've seen in other projects, what are common pitfalls when operationalizing IAM strategy now that you have identified what needs to be fixed and putting that on a roadmap? What are typical pitfalls and much more important, how to fix them, how to avoid them? Maybe Charlie? Yeah. So one of the common pitfalls I see is that there is a misconception that tool equals capability.
We touched this briefly at the beginning of our podcast today. And this basically means just because you have implemented a new tool, for example, an IGA suite, doesn't automatically mean that you have a function and access governance. So the tool might enable the capability, but it's the process behind it. It's the ownership. It's what you put in, which models do you use, which data do you feed into the tool that make it actually effective.
And now that we talked about low hanging fruits, I come across, I experienced that the basics, right, or the low hanging, let me call it, let me stick with the word low hanging fruit. So the basic groundwork might be skipped when we want to chase the highest fancy next shiny goal, right? So for example, there are organizations that want to push for really advanced models like zero trust or you name it, but they are still dealing with very fragmented, for example, directories or having no clear identity governance in place.
I mean, we can all agree that IAM is very complex. It touches multiple systems, processes and stakeholders. And so again, I want to second what we discussed before. The best way to success is to move step by step, to make sure the foundations are in place, to make sure you involve the right people and also align with your overall business priorities and your overall goals as an organization.
Yes, absolutely. I would say that's one major thing. It's a big topic and we are living in a fast changing world there. To decompose the question, what we really want to achieve is key. And often we tackle that the general problem will be IAM and therefore we want to change the tool and then we really go into it and really look where the trouble really comes from. And then it's sometimes the tool, but more often it's not only and exclusively the tool. There are a lot of different factors which pay into the whole formula.
And then there are like organizational topics and then sometimes data quality issues, which is not covered by the tool itself. And that's where the fundamentals come into play. We really need to decompose the question, what do we want to achieve? And then what can we achieve with what we want to do? So if we select a tool, if we go into the direction, we can only fix the issue which is related to this topic and not everything with one tool. Right.
And we started out this podcast with looking at how to initiate such a process, how to do a maturity assessment, but then also to move forward from this maturity assessment towards the next steps, towards a longer term roadmap, maybe even a program. But if you look at the starting point and these are analysis that you are executing on a regular basis, are there patterns? Are there typical patterns that you see that are similar across different organizations?
And maybe you can highlight one example of those and how to actually tackle them using the maturity assessment and the reference architecture as this capability model to really get to quick wins or hanging fruits and to really identify what could be a good first step to really show visibility, to improve and to really improve also the maturity. Are there typical symptoms that you see in real life? Maybe Kai?
I mean, it would be great if you can give like an approach for everyone and can say, okay, if you fix that, you will be 20% better than you already are. Of course, there are symptoms which are more or less always the same, but the root cause tends to be very different from piece to piece, which makes it that complex and also that interesting to work in this environment. If we stay, for example, with the IGA tool, the symptom is the IGA tool doesn't perform right. And then the logical resolution for that is we will swap out the tool and then all our problems will be fixed.
If you take a step back, we want to have small and achievable goals and fixing or swapping out an IGA tool is neither of it, or at least it's not easy to achieve in a short period of time. Therefore, we really need to decompose the whole thing, as I already said. And then we can look into, for example, data quality. Data quality is, I would say, quite often something which tends to be a cause for bad performance in the IGA tool.
As Charlie already introduced the topic of zero trust, data quality is really the fundamental thing to build up more complex structures on top of IIM and really have good automation here and there. Therefore, maybe it does make sense to look into data quality and if the data which we need to work with is really in the right quality, to the right time, in the right place. Right.
Also, we are not in the business of promoting products or exchanging products, and I think that is something that has proven right for me in many years of experience. And I like to be remembered with the quote that IIM is 30% tool and 70% processes and policies.
So, if we keep that in mind, and if somebody says my IGA tool is failing with mover processes, maybe your organization is failing with mover processes and you need to fix that. And that's the reason why we often end up in supporting, in defining and refining process and policies.
Right, Charlie? Yeah, great point. Now that you mentioned mover processes, or let's say JML in general, you were asking about patterns if we see something that commonly comes up. And I think JML processes are a great example for that, because these processes are not only IT processes, but they affect the whole organization. We have HR, we have IT, we might have security, we might have other teams involved. And the interconnection between different divisions within the organization is also what makes it complex.
So, it might be that the finger pointing starts, okay, HR made the mistake, IT did something wrong, whatever, but this is really not helpful. And as Kai already mentioned, we need to make sure that we understand the actual cause of the issue, and not just try to solve the symptom. And when defining and understanding the cause, we can come up with ideas to solve this issue, and actually make the entire process smoother, where in many cases, the whole organization benefits from.
So, it's not only IAM and IT, but also related parts in the organizations that need all of these processes to run smoothly. Right. And if you look at maturity, I think it's easy to say, I'm great with my joiner process and forgetting the external users, but the internal users are really brilliant. But the maintenance of external users is still in place and takes days.
So, sometimes you even need to divide a capability or a functionality according to the identity type that is related to that. I think that's also something to keep in mind. Your joiner processes are not all great, or could not all be great, but only a fraction of that.
So, we're getting to the end of this episode. We realized that the term identity fabric, again, is true. You've mentioned this is an interwoven, interconnected set of tools in the end, but it's also an interconnected, interwoven set of capabilities that together form what manages identities across a whole organization.
Of course, I don't want to close down without mentioning the event that we will be having in September, on the 18th of September in Munich, the Identity Fabric Impact Day. So, there is everything in that term.
And yes, this is the shameless self-plug and the mentioning of this event, but I think it's really important to get into discussions with peers that already have done that with or without us. It's nothing to sell from an advisory perspective, but it's really something to talk to peers and to understand where peers are right now.
So, the identity fabric and the reference architecture are tools that are in use and that we can deploy there. And you can talk to advisors there as well.
So, any thoughts from your perspective, Kai, with regards to the Identity Fabric Impact Day? It's different from EIC. It's smaller, it's more focused, and it's the identity fabric.
Yes, absolutely. The whole episode was around speaking with peers and understanding your company and then fixing the problems. And why shouldn't you go over borders and speak with bigger peers and other companies which already had this kind of challenge and overcome it?
So, learn from those who have already shown that it is, of course, an achievable goal to solve this challenge. And you really can make use of it and really can learn. And I think all the communication and discussion around it is really beneficial there. Right.
So, final words, Charlie, before we close down? Yeah, same for me.
So, I would say the IAM community lives from exchange, from getting connected to people, from networking. And at the end of the day, many organizations struggle from the same – let's keep the word – symptoms. It might not always be the same root cause, but this might be a great opportunity to get experience from peers, to talk about solutions, and just to network and exchange.
Yeah, great final thought. Finding the right root cause for your symptoms might be challenging. And maybe peers can help, maybe consultants can help, maybe your vendor can help, but maybe also an analyst can help or an advisor can help to really get you closer to the root cause and to solving that. Having said that, and having mentioned the Identity Fabric Impact Day in September, thank you very much, Kai. Thank you very much, Charlie, for being my guest today. That was a different episode.
That was a more advisory-focused episode in this analyst chat, but I think this also shows the breadth of what we're doing at Kupinger Coal. And this is much closer to where the fun is when it comes to really operationalizing identity and access management and the Identity Fabric. Thanks again. Looking forward to having you soon again.
And Kai, this was your number one. Number two is waiting around the corner. See you. Thank you. Bye.
