Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor with KuppingerCole Analysts. Today is an episode that looks forward to our upcoming event in September in Munich. We are looking forward to the Identity Fabric Impact Day. And for better understanding the way how we use and leverage the identity fabric, I have invited two guests today. One is around for the first time and one has been around quite a while. So let's start with Christopher Schütze. He is the CISO and he is a lead advisor with KuppingerCole Analysts.
Hi, Christopher. Good to have you.
Hi, Matthias. Thank you for having me. Looking forward for this podcast. And as a first, we have Deniz Algin with us. He is an advisor with KuppingerCole. So he day by day works with the identity fabric when it comes to end-user customer engagements. And this is what we want to talk about, Deniz.
Hi, good to have you. Hi, Matthias. And thanks for having me. Great to have you. And I think this is not the last time that we have you because we want to leverage the experience of our advisors. And for those who will join us at the event, I know that sounds a bit like the shameless self-plug, but we really want to tell you what to expect also at this event and what you can learn from that.
And applying the identity fabric and using it for supporting our end-user organization's customers in improving and evolving and preparing themselves for the future, this is actually what we want to look at. So the challenges organizations have been doing identity management for quite a while are advanced. They are to some level mature, but they want to evolve. They want to improve. They want to add capabilities.
And maybe a first question to you, Deniz, when an organization approaches us and we help them, how does the identity fabric as a concept, and I assume the audience knows what we mean by identity fabric, maybe you can highlight that a bit. How can the identity fabric help actually organizations to design an IAM program that is capable of using what's already there? So it will be a brownfield approach, not starting fresh, no rip and replace. So there is infrastructure already around, which might be on-prem, might be in the cloud, might be hybrid, might be anywhere, all types of identities.
So how can the identity fabric help in helping them without disrupting the existing operations? So not to break anything while we're updating.
Well, I'd like to use an analogy of an airport. Well, just think of an international airport.
Well, what happens that there are travelers, they come from all over the world with different passport languages and, of course, different airlines. So what does the border control do? So they control all travelers, of course, but with unified standards like passport control, visa or fingerprints, and no matter where they come from.
Well, you can see the identity fabric then as a border control. Well, it ensures that users from legacy systems or SaaS applications and clouds are identified and authorized by the same rules. Right. So taking this analogy, that means that we also look at different types of identities, which represent the different types of passengers with their different origins. So we look at them as partially as being legacy, being already there, and partially adding new capabilities, new types of identities, new workflows.
But I think entering a new customer, and I've done that myself, of course, several times, understanding what's already there and understanding what needs to be added and what will be a proper, useful, future-proof outcome, that involves having the right advisory methodologies at hand. Christopher, when you are in this situation, when you support our end-user organizations and you are with a team of analysts or advisors from Copyrical on the field with the customer, what are the methodologies that you use to assess what requirements are there, especially when it comes to interoperability?
Because identity fabric means everything works with each other. Yeah, first of all, I really like the idea of comparing this to an airport. You mentioned identities, different types of identity, and at the airport, we have them. We have the internal people, we have the security guards, we have the border control people, and we have the passengers and the pilots and the stewardess and all that stuff. And we have multiple things people need to access.
Maybe starting traveling by train to the airport, entering the airport, going to border control, what Dennis mentioned, and then buying some beautiful stuff before boarding, boarding, going to the plane, and stuff like that. So at the end, always a mixture of different things around authentication, authorization, and governance. So the core of the identity fabric. And this is really a cool idea to draw this picture. And from a methodology perspective, what we do then with our customers, and Matthias, you mentioned you did this also several times, is talking to the people is the first part.
I already mentioned different types of identities. Usually they have internal stakeholders. Someone is responsible for internal, someone is responsible for externals. Someone is delivering information about them. Someone is maintaining that. Someone knows which systems we have, which applications we have. Maybe even if you talk about DORA and stuff like that, what physical assets do we need to protect and things like that. Then we have the IT guys and we have people from governance. Maybe you have a regulatory requirement, NIST 2, DORA, or ISO certified.
And then you have CISO or an information security owner within the organizations. And then do this based in interviews and workshop. The best thing usually we do is we start with the basics, join a mover, lever, and talk for this different identity types in the fabric from beginning to end, which systems are affected, where are information delivered from and things like that. And that is always a good starting point to understand what is there or what is needed.
This at the end depends on what the customer asks us for, but usually this is a starting point to really get into the level of maturity and then go in the direction whether you need something new or need to adjust something. That is our more or less approach. Talk to people.
The traditional advisory workshop is one key element, but from our experience and also in the work that we have with our end-user organizations and with our customers and with those who we want to support, it is also that we structure these workshops well, so that we get to a proper train of thought when it comes to identifying the most important stuff. I think one aspect that you can always apply is the concept of risk and the concept of benefits. There are these no-go words, more or less sounds like the BS bingo when it comes to quick wins and big wins, but in the end it is true.
When you have a group of people which are stakeholders within the organization and they can tell you what is currently the highest risk that should be avoided and should be mitigated, what is the process that takes the longest and should be much faster and more efficient. If you can apply these criteria, these dimensions, that is usually very helpful when it comes to identifying what should we do first. If it makes sense in a bigger picture, quick wins, big wins, and a risk-oriented approach is something that can be taken into account.
Maybe we have a short hint at maturity assessments as well later when it comes to understanding, yeah, this is where we are good and this is where we are not. That is really a good starting point. Talking of maturity assessments, Dennis, when we understand or want to understand where an organization actually is, we can read documents, but it is often always helpful to have the right stakeholders at hand to talk to them because this is much more fruitful.
On the other hand, having a joint target state definition to identify what the gaps are, that is also important, especially in a brownfield approach, cross-platform, hybrid, and when we look at integrating identity across everything that is there on this airport. Dennis, what is your point here?
Well, what you can start with is to be a center. What you can do is you can just write a one-page target state with, let us say, three headlines, experience, security, and compliance. Under each, you can list two or three measurable outcomes. What is important here is to keep focus on the outcome and not on a tool. Now that you have this list of targets, the target state with these dimensions as described, what could be a useful next step to actually get closer to the target state that you are aiming at? Maybe there was some addition from you, Christopher? Yeah.
Basically, if you collected, like Dennis mentioned, experience, security, and compliance topics, the next step is to define owners and due dates to really find a way to mitigate your gaps within the next step. That is a very important thing. You mentioned on the previous question things around risk-based approach and also big wins and quick wins, something we as advisors really love to use in phrases. That is usually something where the magic of our advisory service comes into place. Because of experience, we know which gap can be closed quick and which not, which needs some more time.
Then we support our customers in defining such a list to work on the next topics. Ownership responsibility, as always, in any topic that is business-related, is the most important thing. And to dig deeper into that, Christopher, and to have a more in-depth look at that, when we apply the Identity Fabric, and it will be the Identity Fabric in Payday, part of it is the reference architecture. This is where we look at capability. Everything that we do as an analyst company, as an advisory company, is capability-driven. The last thing that we want to look at are tools.
We need to understand what tools are and what they provide as capabilities, especially when they're already around and we can use them and organizations use them for years. But this capability-driven approach also for the target state, but also for the maturity assessment or for the SIS analysis. That is something that we really like to apply and that can, of course, be used in prioritizing interoperability initiatives across the business units and technical domains, also to tie systems closer together.
From your experience, what role does this capability-driven approach play and how does it end up in the roadmap? This is a thing that is really interesting. I mentioned when answering my first question, bringing the people together, talk to them, and you mentioned then already stuff around priority and risk.
Usually, when we do this kind of interviews, we realize in many organizations, the bigger the organization is, there are some kind of multiple instances of things doing more or less the same capability, if you keep in the capability phrase here. For instance, let's take an example, authentication. You have internal people that use some kind of authentication. You have internal or partners that are working for you, like external people. You have potentially customer, you have B2B2C things, and that all are using authentication as a capability.
Maybe you have three, four, five different tools, IDPs, authentication mechanisms that deliver something, and this is something you can unify, usually, or by using the fabric does not mean a single capability needs to be fulfilled by a single tool or service, but usually the option to downsize your IT infrastructure is really high. This then comes into account, so collecting the requirements, translating them into capabilities, see if you have some kind of duplicates, and then see where you need to mitigate the risk for implementation combined with effort.
You can use there tons of metrics, usually three, four, do the most sense here to prioritize what is the next step. Do I want to mitigate the risk? If it's a data privacy issue, I realize authentication is not 100% mature, or is it cost reduction? If my external partners can onboard themselves and authenticate, so Federation in that case, I don't need an internal resource on doing that, so then it's money at the end. Slicing this down from a capability perspective, what is the next step? What do I need to do? Coming back to ownership at the end helps to implement it.
Operationalizing identity fabric is really the challenge. It's not a one-time effort. It's something you need to do regularly, frequently, and also revise and check because requirements change over time. We all know that in our area, and that is something you need to be aware of. The identity fabric is really flexible on that. If a new capability, so not authentication, not Federation, comes into place for some magic IAI stuff, which will come next year and we don't know yet, this can be added to the fabric as well. Interesting.
If you look at the sequence of a project, we have started with workshops, we have started with understanding where the organization actually is at, we know what their requirements are, we know what's already there, we know their existing infrastructure on which they want to build or maybe which they want to get rid of. I think one of the key questions then is really, now that you know what they want to have, there is a target state, I know what is there, making the right steps at the right time, that is most probably one of the most challenging tasks.
This is the question when the customer says, now give me a roadmap. How do you recommend sequencing these individual initiatives as part of a project slash maybe program to get what we just said, so quick wins, big wins, achieving the target state, doing the right stuff at the right time and building upon that. How to do this with long-term architectural alignment, so really making something that makes sense in the beginning, but also in the long run. Long question, how to write a roadmap?
Well, you can take one lighthouse use case that is visible and manageable of course, and you can deliver then a clear win like a single sign-on for a key app and you can use these lessons to shape the router plan. Well, another thing you can do is you can run two tracks, for example, platform basics and app onboarding, and you can make sure that apps only use approved patterns from the platform track.
So, this will keep speed and of course consistency together. When we asked our colleague Philip, he is very good in exactly doing this exercise and he usually compares value, risk and effort.
So, really understandings of what can be easily achieved, but has high visibility and high benefit. That is a candidate for doing first. That would be a quick win. Big wins might be those who might need more time and more effort, but have even more visibility. And maybe there are those who require a lot of effort and have not much results, visibility. Why should we do them in the first place? And if we do them, when do we do them? Maybe at the end, maybe in parallel to what you do later, Christopher. And Matthias, this is something we as an analyst company in that case really love to do.
Philip as well, by the way, creating scattergrams with two dimensions and rate them and put them into the right order, like the famous quick wins. But also one thing to add, it's always a mixture of those things you can measure, you can calculate. It sometimes also depends on stakeholders, strategy and the big picture of the company.
So, it always needs some extra layer of experience and feeling what is the right next thing for the customer, not only based on quantitative factors. Exactly.
So, sometimes it makes sense to involve us and also to understand the market. What are others doing to understand what peers are doing? Maybe the peers in your industry, that might help as well.
So, this is where also an external partner, that's what have to be us, can provide useful insights into this prioritization process. And maybe you don't need yet another web application firewall. Maybe you need a more modern zero trust approach. And even if there are 10 stakeholders in your own organizations, you would love to have a web application firewall.
So, maybe that's a good starting point as well to bring in external expertise. We are already getting closer to the end of this episode, but maybe one question I love, this question at the end of a podcast is really to say, okay, what can go wrong?
Of course, I would never phrase it that way. I would always say, what are common pitfalls that you see in your experience? Because projects that we do don't go wrong, of course. But when organizations attempt to operationalize this interoperability that you described with the analogy of an airport, what can go wrong? And much more importantly, what can we do that this does not happen? Maybe starting with you, Christopher.
So, first of all, no, I will not start with this famous German airport and what could go wrong, even if it would fit perfectly. So, identity and access management is a very complex topic. That is the first thing that could go wrong. You need to be aware of what is part of identity and access management. We have with our reference architecture an idea of what should be part in the core areas. Nevertheless, it really depends on your organization, the area you're working in, whether this is the right scope or not.
So, scoping at the beginning is a very important thing. Do not include everything. Do not exclude everything. Focus on what is really relevant for you as a starting point. That is the biggest thing you need to do. The second thing is, we mentioned the word project. Identity and access management is never ever a project. It's a program with multiple projects. Because a project has a character to end at some time in time and budget. In the best case, in the worst case, it's like a famous German airport. Program has multiple things added and new requirements can be added.
And that's more like how identity and access management should be treated. For sure, program is also something that ends somehow. And if it's then part of the normal operations of the company, you need to verify. But starting with a program is always the right thing.
Then also typical things we see with every customer is at the end, still basics, like the identity data quality at the beginning, up to entitlements, whether you have policies, roles, whatever kind of construct you have for access, for authorization in that case, whether it's very cryptic, if you have an SAP environment, or you have very complex role modeling or policies no one understands, this is something you need to be aware of. Also stuff around the onboarding journey, offboarding and how to handle applications, which applications are in scope.
This is something you need to have clarity or you need to build clarity. And coming back to the fabric and the ideas of the beginning, you need to start with, what do you need? What are your use cases? What are your requirements? That is how we do that. We don't start by talking about, you have tool ABC and IDP, ABC, whatever. It's about, what do you want to achieve as an organization now and in the future? What is trend and market? And this is the foundation of building the identity fabric, having planned strategy, built into a roadmap.
And then also, if this comes into consideration during the project, seeing whether you need to replace something or need to have an additional tool. And with that structured tool, you cannot prevent from failing in some areas. That's the character of projects, but you can minimize the risk of failing and building the wrong thing. Right. And maybe to add upon that, really what you've mentioned is so important. And sometimes we encounter the situation that organizations tend to skip the approach that we like to use.
As I said, we're starting with a capability-focused approach. So we have this chain from capabilities, what do we want the system to do to a services-based approach? What is the overall service that we're looking at? So if we look at capability, which might be authentication, and if we look at the service, that might be an access management solution. Up until now, I have not mentioned a tool, but I won't do it in the next part. So we will then map these capabilities and the services to what is available on the market.
The pitfall is that we do it the other way around, that the customer says, hey, we had this great vendor here and they presented onsite for two weeks ago and they showed how good they are and what the capabilities are. I don't care. It looked nice and it seems to solve a problem. And I think that's something that needs to be avoided at any measure. This is something that we should take care of, that we really start with what is needed, how to bundle that and then map it to tools. Maybe that vendor is on that list and maybe not.
In the end, it's about what makes sense for the organization, for the airport. But we are not looking at shiny desktops and dashboards in the first place. Might be nice. The key is then to have these planes in the air and then that's what we're looking at. So thank you very much, Dennis and Christopher, for being my guest today. But one short question, first of all, will be the end, but not before I mention the event.
This is, as I said, an episode that wants to give an insight into how practitioners, how we as advisors, try to approach identity and access management programs the right way, as you put it, Christopher, and that's right. Really to do it the right way and to evolve over time. So identity and access management is not a single task effort. It's something that's ongoing. It needs to be steered over time. And Identity Fabric is one of the key tools, in our opinion, to use that, having a proper blueprint for that and using that. And that can be seen at Identity Fabric Impact Day in Munich.
September and talking to us and much more importantly to those who actually do it. So it's really about practitioners, about those whom you can ask to learn from their experiences. It's nice to talk to analysts. I know that because I am one, but it's also nice to talk to those who have already done that to the practitioner in the end. So I hope we can see you there and that you join us for this one-day event. Before we close down, now the question that I've mentioned before. Final sentence, starting with you, Dennis, before we close down.
Yes, sure. What I can say is that interoperability by design is not just a technical gimmick, but the foundation for digital transformation. And those who understand identity as a connecting fabric can not only manage legacy SaaS and multi-cloud, but also lead them securely and efficiently into the future. Right. And maybe trying to identify what has to go, it has to be replaced. Maybe that's sometimes not a bad approach as well.
Christoph, your final famous last words. My famous last words, mentioned multiple times. I don't know who started that phrase, but I love it. Identity and access management is a journey, not a sprint. And you need to be aware how to proceed and fulfill your requirements. And as you mentioned, the tool is the last thing you should think about, whether it has fancy blue or green buttons or not. It's about how this tool can support your requirements, your capabilities around identity and access management. And that's the only thing that matters, not the color of the button. Right.
So let's continue our marathon, but have a break on the 19th of September in Munich and talk there to each other. And looking forward to that. Great having you both as guests today.
Thank you, Dennis, for being here for the first time. Thank you, Christopher, for sharing your experience and expertise from your different roles as CISO and lead analyst and advisor. So looking forward to having you soon again and looking forward to seeing you all in Munich in September. Thanks again. See you. Bye-bye. Bye.
