Implementing the Identity Fabric Model in a Bank: A Practical Approach [Intermediate]

Thank you very much. Then let's start.

So, Implementing the Identity Fabric in a Bank. It's me, Angelika Steinacker. I'm with IBM. And I'm Alex de Vries and I'm with Rabobank. We are the guinea pig in that sense, with our identity fabric and how we did it. And I think Martin Kuppinger had given us a really great, in football, soccer, you would say, Vorlage, so introduction into everything. So we can just keep on that one. Indeed. Indeed. And we have discussed that several times and we both, we can talk hours about it. But we don't want to bore you. And this is why we have given ourselves a guideline.

Based on the six honest serving men from Kipling. I don't know if you are familiar with this little poem which he had written for his daughter. But the main point is that there are six honest serving men and their names are What and Why and When and How and Where and Who. And this has been and is always a good guideline to structure something if you do not have enough time to expand in every detail. So let's start with the What. Yes. Let's start with the What.

Well, about the What is the Identity Fabric, right? So we heard, Martin, we've seen a lot of presentations today. Looking at the What, I see IAM as the capability that needs to be implemented in an organization. And as such, the Fabric brings a lot of structure on how to do that in such a way that it can deal with the rate of change of the organization, but also in our world of cybersecurity that we can deal with all that change and making sure that we can adapt and make sure that we can bring it.

So looking at that and making that a reality, then there are three things that we feel are most, or at least we took a structure that we feel is most important. One is an operational backbone. What do I mean by that? A rock solid processes with technology and data where we can trust that data and the data quality is correct. So that's sort of the foundation that you need in order to do, in that sense, anything. Then you have a digital platform.

Well, Martin already spoke a lot about orchestration, about APIs. So we need to have a catalog of our capabilities, which obviously the framework gives great guidance to. And as such, by having such a catalog and knowing which delivery of which service and what capabilities we have, we can structure this. Last but not least, if you want to scale, one of the biggest problems I think everybody has a problem with is because you can't find enough people and professionals to really deliver that by hand, you need to have a solution to basically give it away.

So you need to give it to your developers so that they can continue to work with it. So they get basically on the platform, utilize your solutions, integrate it in their day-to-day activities. And that's on the why, I would say. Maybe I can add a little bit on the orchestration layer. That's a good idea. Thank you. By the way, our slides, I think this is one of the slides with the most text because Martin had said that he's always challenged that his slides are too texty. We have tried not to do that indeed. But orchestration layer.

You have seen that also in Martin's pictures in the Identity Fabric. There is something like that. And it is a horizontal layer. We have put it intentionally as a vertical one because we think this goes through all of these layers. In the end, the instantiation or the real implementation might be something horizontal. But you need to orchestrate from the user journey through the processes, through the capabilities, through the microservice, technical components, and the base layer, the Identity Data Hub, what we had called it. I had called it for, I don't know, 10 years at least or so.

It is named a little bit different in the Köpinger Identity Fabric, but it is similar. The orchestration layer is, as Martin also had said, really the most important one. Like a conductor in orchestra, this is why it is the orchestration layer. It guarantees you that all these pieces are playing together. We are not only talking theory. We will show you how this works on a specific example a little bit later. Why are we doing that? Why are we doing all this effort with the Identity Fabric? Let's start where we are today. We have heard it a couple of times. We have siloed environments.

Many people are seeing IAM as a technical piece only, and especially in IGA, this will always fail, this approach. This will always fail if you don't include the non-technical parts in IGA, especially 70 to 80% non-technical. Then you will lose. Why is it so important and where we are today? If you are failing in having your identity and access management right, you might be threatened to lose your license to operate.

For sure, it is in the bank. Especially in the bank.

Alex, what do you think? What adds to the why? For me it is also very important. There is a lot of change. I don't know how it is with you guys, but we have a lot of legacy. How do you deal with that? How do you make sure that we continuously can innovate, that you continuously can deliver on all the changes you need to make, the audits that come to you.

Basically, you need the time. You need time and you need to find a way to be more agile to your organization. Definitely, if you look at our environment, we have 500 DevOps teams delivering changes every two weeks. That is a lot of IAM changes you need to do by hand if you need to. That is something you need to have automation for.

For us, it is a lot on, and that is only the internal perspective, but the outside perspective, looking at all the AI developments, everything that we see as an opportunity for us to, let's say, leverage to bring to the table as to improve and simplify our work. Hacker sees it as an opportunity to simplify their work. We need to make sure that we can also deal with that rate of change. It is a lot that we need to deal with in that sense. The cybersecurity and not to forget to simplify the experience for the user because it is a lot they need to think about.

If they don't speak IAM, and if they see an application and we change it, let's say, once every six months, they look at the application, we changed it, and then they don't know how it works anymore. How do you make sure that that experience for them becomes easier so that they can easier comply, and then at least we as a bank, being highly regulated, make sure that we can continue to deliver? Anything to add? No. I would say from the six honest serving men, we have now two. The what and the why. Let's get to the when because one size doesn't fit everyone.

What Martin also has said, this is why we think he has really given us, I don't know the English expression on Vorlage in football, but anyway. When, what do you think? What is your perspective in the bank? From the bank, at least what we try to do with this slide and hopefully also to give you a bit of a structure on how we looked at it. The more you are, for example, regulated, as I just said, it's a lot. We have 40,000 employees. We have a few hundred thousand things and interfaces.

We have a lot to manage, and when you're regulated, you need to look at when to implement it and to which extent, which is very important. For us, regulatory compliance and operational execution, the rate of organizational change, I just mentioned it, and the number of geographical locations.

Obviously, the laws will change over continents, so that's something you need to take into account. Looking at your tax service, also your risk appetite.

Well, if there's no risk appetite and you have no exposure, why have the whole fabric? If everything can be compromised and you have no secrets, then it's not such a big problem. But with your bank, it's a bit different.

Obviously, the more employees and IT systems. Those, at least for us, were the vectors to definitely take a look at it and start with this a few years ago. Two years ago, you said?

Three, yeah. What are we doing now? How we did it.

Yeah, how we did it. Because I think the theory, let me call it the theory, we have now heard yesterday morning in the workshop a lot of things. This morning, Martin has also talked about it, even with his examples, but this is the theory. And he had said you need to adapt it, all these things, and we want to show you that, how it had been done. And it is not as simple as a straightforward implementation, so you need a strategic approach for that one.

Indeed, yeah. So, as said, the orchestration layer, and you need to switch a bit of a paradigm.

So, what we did is actually we introduced something, which Martin called, I think, the API layer, or basically the decoupled APIs. We introduced the name Service API.

Basically, a business service, what the actual business needs. So, not the application APIs or a collection of those. We introduced tangible value. Let's say a join is a join API, right?

So, a joiner of an employee, or let's say a new machine that basically gets onboarded, it will be a full service, and you don't need to give, let's say, all the internal application APIs to those, well, developers. Two reasons to do that.

One, the decoupling. It's very important, because you can't change your ecosystem, or basically internals, if everybody is connected to your applications in those system APIs.

So, that's very difficult to make changes on. Second, if you want to swap and basically leverage everything that all those vendors basically outside can bring to you, you can't swap anything if you have exposed everything, because you can't take it out, definitely, if you're hooked into, let's say, thousands of applications.

So, the Service API is a start. That's basically exposed on the gateway. That's what you present to your customer. Then you have your orchestration layer that basically orchestrates the events that need to happen and basically the change that needs to happen in the actual application landscape. There are two gateways. In reality, you can have one real gateway, but just to show it as an example, they're basically virtual gateways. But this is how we started. This was our first project where we had the onboarding of Windows VMs in this way.

So, this leads us to this box here, and this is where the magic happens. And just to show you that picture, but where happens the magic? And this is the next one where you see an architectural picture with, as I said, some lines going through all these layers, Alex. Yes.

So, if you extrapolate basically the previous picture, which was more simplified, this is the reality on how you can scale out. So, on the top, we have our journeys. You have your software development lifecycle. You have your changer, mover, lever.

Sorry, joiner, mover, lever. You have all those journeys you have there on top, which are basically realized by process steps that they have in their journeys, which can be a user interface interaction in a process step or a machine basically having an interaction with a service API. And from there, your orchestration layer determines what happens in the application API down below, which is a real decoupling. And this is, well, basically what Martin was explaining on how it's done. Okay. Yeah. You have to, I see it. I also saw it.

Yeah, yeah. And you know, you know, I know, we are talking for, can talk for hours, but let's get that now to the where. Where should you do that? Let's move to that one. Yeah.

So, where? So, right.

So, one quickly, EOM is not something which is only owned by IT security or a business. It's all.

So, where do you locate it? Make sure at least that you get this located in a place where everything is a first world citizen and not let's say IT focused or only security, because that doesn't work with IAM. You need to take a look at the whole thing. What we find important is we have a IAM center of competence, really the knowledge where the standards and everything gets developed and where the people really know what they're doing. You have a factory where the process services are delivered and you have your satellite organization, which basically is in the business.

We have a matrix organization where we literally have knowledge on the business, but also on our EOM services that we have delivered in our factory so that we can look at the risks and have local people make sure that the risks of those business are addressed with the right products and services on our environment. And brings us to who to the stakeholders and the identity fabric, as you said it before, it's really to effectively serving the stakeholders.

Indeed, yes. So that's where the bridge comes in. Those satellites have these interactions with basically all these parties and we consider them all, as I said, first world citizens. The competence center has those conversations as well and make sure that standards and changes that needed by the factory that we have in a tribe, make sure that they get adapted and changed continuously on need. So this is how we did it. We need to be a bit quick, but I think the picture shows itself. Okay. So let's come to our key takeaways.

Yeah, let's do. This is the, not the last slide, but the pre last slide. Then key takeaways. So understanding. Understanding is the first point. What is the identity fabric and what does it mean for you? Yes. And what do you think? Implement? How to implement? Yes.

So, and how you get started. So that's how we covered that in our slides. And I think we elaborately explained that part, which was the key to bring to this audience. So I think we managed to do that. Yeah. And stakeholders serving.

Yeah, that's the last one, which I think personally is very underestimated, but one of the most crucial components of getting this across is if you don't have those relationships and what we implement with our satellites, we see those as very valuable. And I think one of our key enablers to really bring this to the next level. Okay. With that said, we are at the end of our presentation. Thank you for your attention. We have also put this little poem on that slide. So for those who are not aware of that, and as I said, this is always a very good guideline to structure things.

Ben, thanks a lot. And we are open for questions now. Now or later. We have a couple of minutes left. Yeah. Yeah. Thank you very much.

And first, a round of applause for this. Yeah. For bringing the identity fabric to life. I think that's very important for us. Yeah. And for all the people here to see how it really is then coming to life the theoretical patterns that we have here.

So, yeah. Thank you very much for this. And I have two questions from the audience I would quickly ask. So first one would be, what is the difference between user journeys and processes? It looks to me to be the same or similar.

Ah, good point. Ah. Yeah. A user journey is basically more elaborate, right? So if you have a joiner, a mover, a lever, that basically starts at a recruitment process. And within that, you have a process and a process step.

Basically, you have the Eon process that needs to be executed where an identity needs to be created, where the authorization needs to be connected to the identity, etc. So there are a lot of steps within. That's what we call a process or a process step. And basically, a journey consists out of multiple process steps. Okay. So you could say like the user journey is the look on the whole from the user perspective. Yes. Yes.

Yes, definitely. But the processes can be in various parts. Correct. Yes. Are owned by different people but go hand in hand. Yes. Correct. Yes. Okay. Another question. What were your prioritized services when establishing your service API? Sorry. The start part? What were your prioritized services when establishing your service API?

Ah, the prioritized services. Yeah. We started with the first one that was around previous access management. So we started with that. But in that sense, you can start with any service that is at that point in time the most important.

The first, the only thing is you need to get things started with your layers. And that's, I think, the tricky part. It took us approximately, well, six to 12 months to really get a first service set up in this manner. So that's because it's an agnostic layer and not an internal orchestration layer of any of the suppliers. We had a agnostic one, which was generic. So we need to get that up and live. And it took time.

But yeah, from there on, basically as soon as you get more of those services available, it becomes a lot easier to basically grab a few of the services and plug it into a new business service because that's when you basically can start accelerating over time. So the first one is hard. The next one is still a bit hard. And over time, when you can reuse existing services, it becomes really easy. So this means also it's not just a technical layer, right? No. It means a lot more, right?

Indeed, yes. Yeah. And the capabilities of your Köppinger Coal framework, I think brings great guideline on the things you can bring in this model that we brought today. Yeah.

Okay, great. Thank you very much again for the talk. Thank you. And answering your questions. You're welcome. Thank you very much. Thank you.