I think it's important to understand that something like the Identity Fabric and the Reference Architecture is a joint venture to some point. And that's why I want to release a little shout out here to the community. Feel free to challenge what we have, what we publish. And if you think that there is something missing, let us know. Approach us, discuss with us. Let's understand collaboratively if that fits into the concept. Did we miss something? That's the major question here. And let's clarify that together. Welcome to the KuppingerCole Analysts chat. I'm your host.
My name is Matthias Reinwarth. I'm analyst and advisor with KuppingerCole Analysts. We are continuing a series or brief series of episodes around the topic of the KuppingerCole Fabrics. So we started with an episode a few weeks ago with Martin Kuppinger, where we looked into the history of why we created, as KuppingerCole, something like the Fabric. We looked into the term, the concepts, the relationship between capabilities, services and tools, which is essential. And we promised we continue that message. And here we are.
For this, I have invited two colleagues. It's again Martin Kuppinger and I've invited my colleague, Dr. Philipp Messerschmidt. So first of all, welcome, Philipp.
Yeah, thank you for having me and looking forward to this episode. And welcome, Martin, again to continue that conversation.
No, thank you for inviting me. So with this combination, we are perfectly set up to continue the conversation from the generic fabric concept that we covered in episode one of this series and move over to the identity fabric. And that is the tool, framework, architecture, concept, paradigm that we are using for, as we identified last time, seven years now. And we are using that for various purposes in research.
And Philipp is the expert on the one hand, also supporting and creating next versions of the identity fabric where we are currently very busy at, but also applying that in actual client engagements where we use the identity fabric as a means, as a lever for creating, improving, developing architecture, plans, frameworks and roadmaps. Philipp, so you're using the identity fabric in client engagements. How can that look like? Where do you actually use such a concept? Where does it get from a piece of paper and a slide to something that is actionable and actually helps?
Yeah, that's a good question. When we are working with clients, they usually approach us with different challenges and every IAM challenge, every customer is unique when it comes to that. We have the two frameworks, the identity fabric and the reference architecture as very strong blueprints, as structured approaches that provide a lot of guidance and structure for the customer as well.
So whatever challenge we face in the IAM space, we start with the identity fabric and create a structure, an orientation for the customer to move forward, to understand the challenge and to understand how to move forward. I think that's the most important part here. So usually we then start with identifying what kind of identity we are talking about, what target systems are we talking about?
And then we dive into the challenge itself by identifying which tools, which capabilities, which services are touched by these challenges, which capabilities are important to improve or to change or to use to overcome this challenge. And this is done in a series of steps, I would say. Usually we start with a maturity assessment. We talk about the target state to improve in the long term and that can result in a gap analysis, that can result in a roadmap discussion. But from there, when we have the status quo, we have the target state and we have the gap analysis, we can go various ways.
Besides the roadmap, we can also do a tool selection, we can talk about the target operating model, we can talk about technical architectures that highly depends on the challenge our customer approaches us with. And even if it is a more operational challenge, then we are able to dive deeper into the capabilities and focus on very specific operational day-to-day challenges. So this is what we can see when we are working with our customers. But I think it's important that this always goes from capabilities to services to tools.
And this is, I think, really like we discussed in the initial episode, central to the paradigm, the idea of the identity fabric, that we don't start with like it's frequently done with tools first. Tools are the result and tools also follow the service and services follow the capability needs. And the capability needs are derived from, you call it a challenge, from the requirements. And this is, I think, the really essential aspect that it helps making, at the end of the day, better decisions. That it helps to take a structured approach and not a tool-driven approach.
Plus, I think that's the other side of it. I see this in some of the conversations I'm involved. You surely also see it in your conversations. It's also something with this entire fabric approach also has a couple of elements in that are providing guidance more for a future-proof approach. So take orchestration as something that plays a very important role, API-first approaches and stuff like that. So I think in that concept, a side of the very concrete guys is looking at capabilities and ending up with tools.
And I think we are very well positioned for tools choice with our leadership compass work, with our advisory team. I think it also helps in giving guidance for sort of a evolution of an existing assets, identity management, which always is brownfield in some way towards something where maybe it's a little greener over the next, it becomes a little greener over the next years.
But that also plays into what we discussed earlier, that we are not only using that in client engagements, but we're using that also to structure our research in the best of all worlds to say, this is a new tool, a new vendor. Let's break down what this tool, this service actually provides. So to break it down into capabilities, into services, and then to actually reverse engineer what a new tool can do to make it fit into our analysis when it comes to understanding what are the right solutions for clients now that we understand their requirements.
So it's one step back and then back to the tool to say, okay, here we are. This is something that we need for the tools choice, right, Philipp? It's not just for the tools choice. I think that that happens all the time when a customer needs advice and comes with the question, hey, I have a challenge with my tool here or around a tool. The first step is always decomposing that tool into capabilities and take a closer look at the capabilities. And sometimes you even figure out that this technical solution, that tool is doing stuff it wasn't supposed to do.
So that this capability belongs somewhere else. And this is usually then part of the solution or it is the reason for the challenge that the customer has. The customer is trying to do things with that technical solution that this tool should not solve. In the end, this capability belongs elsewhere. And that's an important step towards the solution. And it's increasing the awareness for a capability-based model of organizing your organization. And I think that's what you said that helps, I would say, helps customers to understand where the risk of bespoke solutions is overly high.
So when you start using a tool for something it is not meant for, then you usually end up with customization. And I think we have seen it in many areas at some point. Over-customization puts customers very frequently in trouble because the maintenance updates, all these things start to fail. The cost is excessively high. And I think this is also one of the aspects where it really can bring clarity more in a reverse analysis of what is already there at the customer. In contrast to the, which are the capabilities I lack or which I don't serve well enough to understand what do I need to add.
But at the end, it's always a very helpful tool for a structured discussion. I think this is also the reason why it's so widely adapted now. This is a perfect example where we can use the capability view to organize our teams, our people, our experts. I'm talking about the target operating model here. Usually what we can see is that teams are organized based on tools. In the future, this, we expect that this will break up. So we are not organizing ourselves based on tools anymore. We are organizing ourselves based on capabilities.
And that means that the responsibilities of teams that come capability based in the future will be or won't be based on tools anymore. Meaning we have two teams, different responsibility, handling different capabilities, maybe even in the same technical solution.
Yeah, and I would say maybe it's even more, more service system where we organize the teams because services are sort of the bundlings of capabilities. My example would be on the cybersecurity fabric, but you also could envision, for instance, a central authentication service, which is an amalgamation of certain capabilities in cybersecurity fabrics. A security operation center is the service, which is using certain tools, which combine certain capabilities. And this is the organizational structure we use. But I think what is definitely wrong is to organize around tools.
The best example is SAP silos. They should be organized around capabilities and services, not around a certain technology. Same here. And I think this is the same thing that we see in reality, you know, that plays really well into my question that I prepared. And I do want to ask, because we've been looking at target operating models and service organization, that becomes a new twist. So the question is when you are in a discussion with a client and they say, yeah, I am, it's okay-ish, but we are struggling with our joiner mover lever processes. So it doesn't really work. It takes too long.
Birthrights are slow. Of course, deprovisioning is difficult and end of life, not so well done.
Philipp, how do you translate that into specific capabilities and how does that play well or not so well with the target operating model? So operational challenges is something that a customer can also come up with at any time. That's clear, especially when we are talking to experts in their fields that are working hands down deep into technology or functional processes. But that is then a different focus. So we are basically focusing on a single capability, then mapping that again, top down from the identity fabric into the reference architecture.
Drilling down into that capability and showing how deep we can drill down into the details on that capability. Of course, we need to ensure that it is understood what the capabilities are right and left and how the dependencies between those capabilities are. But that is basically what we do. So we identify the challenge, we pin it down to a capability, we ensure the dependencies are understood. And that already creates some awareness and increases the understanding for the structure. This is like 50 to 70 percent of the solution already, most of the time.
It could also mean that some of the origins, the root causes are outside of IAM and that is a service-based approach to say, okay, how good is data quality? Yes, we have data quality management as a capability in identity fabric and the reference architecture. But if the quality that is delivered from somewhere else, defined somewhere else, that could also already lead to problems in the process. So it's the target operating model. Working also together with non-IAM teams might be a different aspect to look into to get to a whole picture.
And I think this is an interesting example because this data quality and the relationships thing shifted in the latest release. We first time showed at our European Identity Conference in May, that shifted to one of these foundational layers. So there's right now a data and relationship layer, which looks at relationships between different identities. And we look at the identity fabric at all types of identities, the autonomous identities like humans or agents, and the dependent identities like workload identities and others.
And so we need to deal with relationships nowadays when you go beyond the humans and their simple workforce trying to move a lever things. And we have the identity information quality issue. So this is really something which we understand as a foundational element of the fabric, like some of the other foundational elements like orchestration, authorization, and certain types of AI capabilities.
And I think that plays well into what we discussed in the earlier episode, but also which is a current challenge that Philipp, Martin, and I are all just working on to say, okay, ideally such a fabric is input agnostic. The identity fabric is target system and identity agnostic. While we are talking right now, identity and access management is changing quite a bit. So the question is, how does the concept of the identity fabric and the reference architecture, how does it hold up with the developments that we right see? It was created to be adaptable, is it Philipp?
Yeah, absolutely. I mean, we have the sets of capabilities, we have made everything expandable at that point that we can add new target systems, new identity types as Martin already did. We can add new capabilities and based on these identity type, we have new perspectives, new aspects, new integrations. So there we have a lot of flexibility when it comes to the frameworks. It is basically up on us to extend that and to use that and up on the customers and clients to understand these new visions.
Something that I currently see, and I have mentioned that earlier, we go away from this tool-focused perspective into a capability-focused perspective simply because we move towards an end-to-end perspective. And many organizations are doing that not based on a tool which has very clear borders and organizational constraints. But when we are talking about end-to-end processes, the capability view is very helpful and that also shows how many teams and how many tools are part of this end-to-end process or journey, especially when we are talking about the recent developments.
And I think a proof for the identity fabric, I brought it up a bit in the first episode, is that several of the foundational concepts were there basically from the very beginning. So the identity API layer and related to this, focusing on API-first approaches for the technology used, the orchestration basically was there in this thinking of a mesh of combining capabilities from the very beginning. Some things clearly have been added over time.
So the ability for signal sharing in both directions, for instance, is more pronounced now because we have standards for sharing signals nowadays like CAPE and Shared Signals Framework. AI clearly is more relevant, more significant in it. But I think the foundational concepts we had at the beginning still are here. They have been a bit evolved, but not fundamentally changed over the past seven years.
And going back to your question, with all the changes we are seeing, and also when we look at AI, I would dare to say everything in that we basically need from a high-level conceptual perspective to deal with sort of a new type of actor, a new type of identity, autonomous identities. Because we have the relationship in, for instance, so we have agents in as an identity, we have relationships in, which is super important in the world of agents because it's not just directed access anymore. It's a mesh of agents. And the fabric is built to deal with these changes.
And I think also, I brought it up in the first episode last year at EIC in 2025, I talked about the identity fabric for the 2040s. And I think this is also something which is very essential to that concept that what we are doing here is not just solving today's challenge for today, but helping clients, helping organizations to build something that withstands change that lasts for a longer time. Because I brought up last year this equation of 2025 plus two plus three plus 10 is 2040. And it's a very simple equation. It wasn't 2025.
We need two years of planning frequently for a larger tool and gathering the batches, et cetera, three years implementation time, not totally unrealistic. And then it lives easily 10 years. When you look at most of the larger IAM tools, IGA and others, they are around for easily longer than a decade. Sometimes we see tools that are here for two decades now. And that means the fabric is also something which is built for the future. Right.
And if we bring that into unison, not to say to balance it, because balance always comes with a trade-off, but to bring this into unison, to have a long-term strategy, to have a north star for an architecture and to use the identity fabric and the reference architecture for exactly that. And having an evolving identity fabric as well, that needs to be well done.
So, Philipp, how often does such a fabric itself need to be updated? So to make sure that you have that north star, that long-running, stable, reliable, long-term planning and strategy. And on the other hand, to be capable of adapting to what is changing under the hood. As you can see, we are continuously discussing the content and challenging it every day. I think the concept of the identity fabric itself is something that forces you to stay flexible in your mind, pointing towards the customer. If you think capability-based, you need to adapt to what happens.
But we, as the founders of the Copenhagen Cold Identity Fabric and Reference Architecture, are also forced to adapt. We cannot launch it and leave it there for years. We feel the pressure from the changing market and the changing challenges, the changing requirements to adapt to it. So in the background, we are constantly challenging our framework, constantly improving on it. And then snapshot-like, releasing new versions, like Martin did on the EIC, of how we will hopefully at the beginning of next year. And even interim.
So, for instance, this buzzword, IWIP, Identity Visibility Intelligence Platform, appeared. We got the ask by someone, how does this fit into the fabric? And I think this also proves the concept of the fabric and the reference architecture. And I'm grateful to Philipp and the team for doing the daunting tasks of also filling it up, doing all the detailed work, when I come up with maybe a new idea for the bigger picture. But I would say it literally took us less than an hour to adapt this in a first version to include IWIP and explain where it fits in.
And that is basically an amalgamation of mostly existing, very few new types of capabilities. And so it also helps to understand, I think this is super important with all the buzzwords popping up.
IWIP, ISPM, ITDR, or whatever else. Every second day or so, someone comes up with a new buzzword. And it helps also to take these buzzwords and say, okay, let's look, which capabilities are behind it? Are they already in, or is there really something new in it? And to shift away from this tool-centric buzzword bingo thing to a structured decision making. And it proves that it works very, very fast. So I revise my words. So I don't use the word revision of the identity fabric, but it's an evolution that we can see that is going on right now. But there will be some kind of revolution.
And we will talk about that in the upcoming episodes in this mini series of episodes. And when we look at having the same approach for different aspects of what Kupinger Coal is known for, and where we're good at, and where we're acting in, and that will be cybersecurity. So there will be an episode with the experts around the cybersecurity fabric that is currently evolving. And more pressing right now, the AI security fabric that is currently under development and almost there. So that will also demand for this kind of evolution. So there will be a first version 1.0 very soon.
And we will work with that on structuring the market, on supporting our clients, doing everything that Philip just explained from operational tasks to maturity assessments to make the next steps. So I'm really looking forward to that. And that makes the work for us advisors, of course, much more complex. So when you have more than one fabric, then you end up in getting two combined infrastructures, which is possible. And this is the target. But it's work. And this is the work that everybody has to face. Before we close down, Philip, a few final thoughts.
When we look at the fabric, its evolution, and how it's applied and how it's evolving right now. Yeah, I have a couple words. I think it's important to understand that something like the identity fabric and the reference architecture is a joint venture to some point. And that's why I want to release a little shout out here to the community. Feel free to challenge what we have, what we publish. And if you think that there is something missing, let us know. Approach us, discuss with us. Let's understand collaboratively if that fits into the concept. Did we miss something?
That's the major question here. And let's clarify that together. I think it's very closely related. What we deliver is the full paradigm, so to speak. Not everyone needs every capability. So the individual identity fabric of an organization always will look different than the big picture. Because it's driven by the requirements for capabilities and the way they structure the services of an organization.
But the overall concepts help exactly moving from a generic perspective, fabric and reference architecture, to very concrete guidance, architectures, roadmaps, everything, targeted operating models for every organization. And that's why we do it. Perfect. No more questions, no more comments from my side. Thank you very much, Philipp. Thank you very much, Martin, for being my guest today, for laying out how identity fabric is one incarnation. There will be more to cover in upcoming episodes. Until then, thank you very much, Philipp. And I'm looking forward to the feedback that you asked for.
So I'm happy to discuss this. And if you have any questions, if you have any comments, if you're watching this on YouTube, please leave a comment just below that video. We are looking at that. And no wonder we are replying to that. And we take this for serious. So every feedback is highly welcome. This is a community. This is a joint approach. So please let us know. Until then, thank you very much, Martin. Thank you very much, Philipp. And looking forward to having you soon in an upcoming episode. See you. Thank you. Thank you. Bye-bye. Bye-bye.
