Welcome to the KuppingerCole Analysts chat. I'm your host, my name is Matthias Reinwarth. I'm analyst and advisor with KuppingerCole Analysts. My guest today is, once again, and I'm happy to have him, Martin Kuppinger. He is the distinguished analyst at KuppingerCole and one of the founders. Good to have you, Martin. Pleasure being here. Thank you for inviting me, Matthias. Great to have you and we want to continue a discussion that was not on that podcast, especially although we talked about this already.
We want to talk about a topic that you first introduced at the opening keynote at the EIC in May in Berlin. We continued that discussion at the time of the recording one week ago in Cologne at the Identity Fabric Impact Day, where you talked about that in your opening keynote. There was a quite interesting panel with you that I moderated and with Marco Venuti. What was the starting point for that episode? There's so much more in that topic. I'm getting to questions very, very soon. The topic is orchestration.
You started your opening keynote with the idea that orchestration inside the Identity Fabric is an architectural capability that's often underestimated and it's for sure not another IAM product category. What changes when organizations finally understand that orchestration is one of the key architectural capabilities within the fabric? To be precise, the idea of orchestration has been introduced way earlier in the Identity Fabric as a key element. I think we started looking at some more relevant technology nowadays than maybe in the early years. It's a key capability.
I talked about that in the 2025 EIC keynote when I talked about the Identity Fabric for the 2040s, where I moved orchestration quite a bit up the stack. I think orchestration is relevant because it has quite a number of facets. There's the orchestration of user flows, more in the sense of authentication flows, stuff like that. There's orchestration in the sense of more administrative flows, either administrative users like the ones doing recertification process and workflow stuff in an IGA solution, but also administrative flows.
But there's also the orchestration in the sense of API-based integration of different IAM components. You have different tools.
Plus, and that is, I think, what is really a game-changer, more of a signal-based orchestration, so consuming signals, sending signals, using these signals to make decisions, to integrate, for instance, IAM solutions with cybersecurity solutions, stuff like that. This is another important area.
Obviously, authentication flows, to an extent, are already signals-based, so continuous access evaluation protocol is one of the areas here. Orchestration is at a key, and orchestration means we do something between full coding and no code.
That's, I think, where then the new elements, new discussions at the Identity Fabric Impact Day started. Exactly. What struck me was that you approached it from, why are we doing that integration, collaboration between building blocks, and how we are doing that. You introduced the term of integration debt to say, okay, maybe we are accumulating and we are piling up integration debt because everything is more or less, unless it's properly executed and orchestrated.
We are building up point solutions, one point solution beneath the other, and that is the other aspect, the other facet of orchestration, to be good at the orchestration process itself. First of all, what are the clearest signs within an organization that there is too much integration debt? What would be the warning signs, the red flags that you would see with an organization that have orchestrations but not yet properly approached? I think the warning signs, the problem is usually it's not that many warning signs.
I think when organizations spot that they have an issue, it tends to be sometimes already too late. When we end up with the scenarios where there are code elements or other types of integrations that also can be low code, no code, that no one really knows about what they are, what exists, who did it, why, how, et cetera. When questions like these pop up, then the organization or the part of the organization is in trouble.
Unfortunately, that is frequently in a situation or happening in a situation when there's already a lot of customization, orchestration, whatever done, and it's hard to get back on track. In a sense, this is not entirely new. When you look at a lot of IGA implementations, where it's not only orchestration, there's also a lot of customization, then on the UX level and other stuff, which I wouldn't count as necessary as orchestration, but there's also a lot of flows that are built.
I think every practitioner in IGA or in identity management has seen these IGA solutions, which are in a sense customized to death, where the customer sometimes not even can run an update anymore because it would break the customizations. We had more than one project where we were advising, which basically led to only the conclusion that there are two things, either you change the tool or you go back into a clean state. You then sort of speak, redo whatever you can redo, but you build on a clean release again. That's after the risk, that's where the risk turned already into a problem.
Matthias, I think you're already waiting for that. I always tend to bring up another analogy here. A lot of organizations have been using some, still are using or having it around Lotus Domino. A wonderful example of an environment where wipe coding, we didn't call it wipe coding back in the days, but where it went broke in the sense where it really went wrong because organizations are ending up with thousands of notes databases and not knowing anymore who did it, why, how, and is it still needed?
I think this is a rather similar scenario and the risk we have with orchestration and orchestration is becoming more important. It's vital to building any type of fabric, an identity fabric, a cybersecurity fabric, an IAI security fabric, data, whatever. There's a lot about orchestration of business flows as well. So it's not limited to an identity fabric. And if we do it wrong, we will end up in a similar situation. And right now we have all these promising concepts, these hype concepts, overhyped concepts, sometimes wipe coding.
We have the shift from complex coding for a longer time right now to no code, low code, which all makes sense, but we need to do it right. And this is, I think, what we emphasize that you need a structure, you need an environment, you need a governance on that to succeed with it. Right. The Lotus Notes analogon was the one that I was waiting for. The other is, I like that sentence, integrations or orchestration that work until they don't. So this is the part that everybody, I think, who is active and has seen before, of course, not in their current project, but in one before.
So it's really highly relying also on people, on heads, on people who did it, who understand what's happening. And if they leave, that's clearly also a sign of not having the proper governance of or over the orchestration itself. And I think that's something where we now have technologies and ways and means to just get better on that.
You've mentioned already the ways how we do coding, but also quality assurance might be an aspect where new technologies, of course, I'm thinking of artificial intelligence or LLMs or supporting tools that can just support us in getting better unless or as long as we do not trust them too much. Yeah, but I think that there's this promise that we can use AI to code faster, which usually means we don't understand what exactly is happening. So we just trust it. We can then use the same or other LLMs to do the quality assurance of the code. We can even use that to document code.
So I'm from a generation where when I started coding, it was not only a good practice, but also a common practice to comment on the code. So there were not only the lines of code, there were also all the comments around that. That was something I think which disappeared a bit over the years. AI obviously can document. The problem is AI can check for bugs, but it doesn't understand what is really meant, what is the purpose of the code. So you can give it a task and say, okay, I need code for that. But the other way around saying this is the code, what is this code doing is way more complex.
And obviously AI is not really good in it. When we look at the news just the last weeks, we tested this LLM and it escaped from that environment. It did rogue things. If AI would be good in understanding what could be the result of running certain code, what the code could do, then this would not happen.
So AI, the large players prove that they can't do that yet. So it's good in documentation. It helps us to a certain extent. But if you end up with hundreds of orchestrations that are around and try to figure out why were they built, what's the purpose of that, AI won't solve this problem for you. So we still need a governance, a framework where we do all the orchestration, where we implement the good practices in the organization. All this needs to be done. And by the way, people will like that if we do it right.
If it's not just about being restrictive, but helping people doing their job easier because at the end, the purposes or this happens because someone needs to do something to fulfill something. And if not everyone needs to figure out how this could be done, but if there are clear guidelines, how it is done, it simplifies a lot for the employees and the external student. So you say that even before starting the orchestration, there should be well-defined integration patterns, agreements on how to do things, also how to document that, and how to bring those into an architecture overall.
So that asks for a strong architecture IAM function in the first place, right? Yes, you need the right skills here to both do it and to, so to speak, plan it, and at the end also to govern it. But is that really new? So I think we have an interesting situation in IAM projects, where usually a third party system integrator comes in and does certain work. I can't remember having seen any single project that started with handing over the architectural principles, et cetera, et cetera, to the system integrator as part of the contract.
And at the very beginning saying, okay, this is the way we build stuff. I don't think I ever have seen a single project where this happened. And even there, we need it. We can't leave this to a third party to decide about how it is done. Total nonsense.
Yes, they are experienced, but experience only is good if it's ending up in the right results. Right. And if you contradict, leave your comments below that video on YouTube or just reach out to us. We would love to discuss that, if that is common practice, just as Martin described it, if this is something that we need to have in the first place. And I think such a strong architecture function within an organization gets even more important just right now, when we are talking to our customers, the end user organizations, we often come to the topic of the target operating model.
And I think the question exactly plays in there because we just say IAM. The question is, I need authentication for CIM. I need it for B2B. I need it for traditional IGA and authorization for access management. This is one capability across different systems, CIM, consumers, customers, B2B, but it's the same capability. And the systems behind them might be in different ownership. CIM belongs to a more business-oriented team.
IGA, IAM, access management for internals is owned by somebody else. So you need to have somebody who makes sure that orchestration works. So this ask for a strong architecture capability, as you said, was always there, right? Yeah. I think the art will be to do it pragmatic enough so that it works. So with orchestration being in a sense ubiquitous, with white coding being ubiquitous, there would be logic in saying, okay, maybe the enterprise architecture team must do that for the entire organization in a consistent manner.
I think that that is something where I would see the risk of this taking very long. So I think it's about finding a good balance between the enterprise level teams that help in guidelines and support, but also doing things pragmatically, for instance, by the IAM or cybersecurity teams that then look at this part and how to implement it in their specific environment with their specific types of orchestration use cases. Because obviously the way and the use cases for orchestrations vary.
Also, when you go back to the EIC keynote of this year, the orchestration use cases along the identity fabric, the AI security fabric and the cybersecurity fabric I showed, they are not always exactly the same. So there are nuances, there are different types of orchestrations. So we need to find a good balance here. You've just mentioned that, and I think that maybe a different angle that we can look at is also how you actually implement that from an architecture perspective. I say the word from a product perspective. There are vendors that offer orchestration platforms for IAM.
Other implementations just don't have that or it's well integrated into these larger platforms, identity fabric platforms, the huge vendors that have a lot of capabilities. Is there a single recipe or is this something that needs to be built for an organization to say, okay, this is the way how we do implement orchestration and we need product ABC or technology D or a paradigm E? What is the way to move forward when you want and you need to orchestrate? Never start with the tool. Start with orchestration on how you do the orchestration and then make decisions about where you do orchestration.
Keep in mind the tool may change, but you still will need flows. You still will need certain orchestration. So what is the right platform to do that? That's something I wrote a blog post more generically about how can I get rid of it again? One of the first questions to ask.
Again, that's where documentation helps. If the things are documented, if there's a good governance around, then you can much easier transfer it to something else.
But yes, the two of us, we had these conversations when it came to IGA and the standard process models and the process model is for us a tool independent. So if you move from one IGA tool to the next one and you have a good process model, this should stay very stable because the way you onboard people won't change because you change the tool. And I think this is a bit of a thinking that is similar to what we are discussing here. We need to understand what we orchestrated, why, and then we can decide on how we do it and on which platform we do it.
But if you do the first things right, then change and maintenance, maintenance is the first thing obviously, expansions, all these things can be done much easier. Right. And I think that is also an indication of the changing, the increasing, the growing role of identity and identity security and identity and access management across all organizations. So orchestration for me is just a large one, but a symptom of showing that identity is more and more key and central for security, but also for business enablement and for governance.
And that also means changing ownership, calling for strong architectural oversight, and to make this distinction between architectural view and implementation view, and orchestration lies a bit in the middle to connect the dots. Right. And on top of that is the warning, don't fall into the white coding trap across the entire IT and business. It always sounds so promising, but if we look at how much stuff is done on all these no-code, low-code elements, you have whatever in your standards, office environments, trust out there, how much is tested there?
How much time do the people spend in trying out how to do that? How much never results in something and how much works only a bit until it breaks? I think there are so many things we can do, but we can do them much better than we usually do them. And I think that's what a bit is also the alert behind that. As I've said, I've even written a book or maybe multiple, I don't remember exactly, about Lotus Nodes. So I know what I'm talking about. Right. And I think, yes, writing code supported by a tool is highly efficient, but nevertheless, coding, developing, being a programmer is not an art form.
It's a discipline and you learn not only to think of the happy path, so when everything works, but you also need to think of everything that can go wrong during a proper process definition. So where can it deviate from what you expected? And this is just the deterministic way of coding. We are not yet talking agents, but what can go wrong needs to be understood. And that needs to be, for example, within a connector, within orchestration to understand.
So when it's fine, it's fine, but make sure that it's also fine when something goes wrong, this art form, this discipline needs to also be integrated into how we do integration for tomorrow, although coding is changing right now. So final question before we close down. The changing role of orchestration, we discussed that. When it comes to ownership, I think there is a, we said architectural oversight, but is there also an ownership for orchestration? Twofold question in IAM, and you've mentioned all the kinds of fabrics that we are talking right now.
Is there some kind of chief orchestration officer in the future? We have anyway too many chiefs. I think ownership must be structured and there must be the right ownership for the right elements. So there must be some level of generic ownership that comes from an enterprise architecture function. There must be an ownership for how orchestration is done within the certain domains like identity and others. And these domains also may change. So they're in a sense a bit blurring lines. And last but not least, there is ownership for the, let's call it the various artifacts created.
So that, and that ownership also must transfer. So if someone builds something, it must be clear who has ownership and what happens when that person maybe changed, dropped, leaves the organization, et cetera. So ownership must be handled properly. And obviously that alone, that helps a lot because if there's a transfer of ownership established as a process, and re-established in the sense of it's done, that means people must start thinking about, how can I transfer that? That only will work if it's well enough explained.
So that I think helps creating some hygiene, so to speak, around the entire topic. Right. Thank you for this final closing thought. I need to go quite a way from my final sentence because everything that you said also is triggered by the way how we today and tomorrow will integrate the topics of a identity of, we hate the term, we know non-human identities into our fabric, how to orchestrate them within our IGA and our security. And if you're interested in that, this is the final, yeah, the commercial break part of things.
Please visit us, join us, learn a lot, talk to practitioners at the identity and NHI impact day on the 5th and mainly on the 6th of October in Munich. And we will be talking, of course, also orchestration, but integration of NHI, of AI identity, of agent AI, of how to control them within your overall identity fabric and your cybersecurity fabric and your identity security fabric. So this will be the place to be. We will be there and there will be lots of interesting stuff to discuss, compact and one day. Please reach out to us, join us on early October in Munich and Munich Marriott Hotel.
I'm looking forward to that. And having said that, thank you very much, Martin, for talking about orchestration, for highlighting the importance, although it was already there, but the bigger architectures become the more important orchestration is. Thank you very much, Martin. Welcome. Thank you.
