Making IAM Projects Succeed - Why You Need a Solution Architecture

Welcome to the KuppingerCole Analyst Chat. I will be your host. My name is Matthias Reinwarth. I'm an analyst and advisor at KuppingerCole analysts in each edition. I will have one guest joining me after the fellow analyst or another interesting part. Then we will have a 15 minutes or so chat around current topics. My guest today is Graham Williamson. He is an analyst for KuppingerCole in Brisbane. So this again is a long distance call around the world. Hi Graham. Hi Matthias. How are you? I'm fine. How are you? I'm very well. Good to be with you today. Great.

Thank you for joining me today. Our topic today is actually I am projects and how to deal with them adequately. So keeping a coal has published recently a reference architecture for IAM systems. So this is a very high level architecture diagram that we work with when designing overall I am programs ideally. So to take this architecture as a future blueprint, maybe with different inclinations in between, and to move from an, from a status quo, Avaya transition architectures to a target architecture all behind that is the idea of the identity fabric.

So this concept of one platform, one set of services, implementing IAM functionalities, cup capabilities, working together and providing IAM services to all identities. But what we want to talk about today is the implementation of these individual projects. I think that is where you are aiming at for today. Is that correct?

Yeah, that's exactly right. Martin Kuppinger data video recently talking about how I am projects often fail, and he basically recommended that an I am project get chunked into his component parts so that you could manage each chunk separately and that increases your chances of success. And of course, that's true. So the question is, how do we do this?

You know, what are some of the ways of doing it? One way, which we were talking about in this book cost is a solution architecture. Another thing that I think we need to pay attention to is project management, but that'll be the topic of, of another podcast, but behind all of this is the fact that identity data has to satisfy the whole organization. You can't have a point solution when it comes to identity and access management, because the identity fabric in the organization has these demands on identity information.

At the very least, all of the applications in the enterprise will need to have some mechanism of having a user authenticated to them. That's an identity issue. Some of the applications will actually store identity in. And so the question comes, how does it get there? How does it get used? So the identity fabric is an integral part of, of, or understanding the identity fabric is an integral part to being able to manage an identity and access management project.

Okay, great. Martin said that in his video and you just reiterated on that. I am project tend to fail. What are the reasons from your experience, maybe Australia and APAC is a bit different here, but, but just, just from your experience, where are the typical touch points when you see that a project is yeah. Tending towards yeah, not fulfilling the complete promise.

What, what are the indicators for that? How do you identify? Right. Okay.

The, the, one of the main indicators is not properly understanding the touch points that our project has on the organization. So for instance, you might say, okay, we're going to install this identity and access management solution. And then it's given to somebody in it to go ahead and do that. Unfortunately, that person in it doesn't understand all of the components of that. And pretty soon it can get totally out of hand. So what I recommend is to actually have an architectural approach to this, okay?

Now this ties into the reference architecture, the KuppingerCole reference to architecture, but we have to look just outside of that to see how that fits in with the rest of the organization. So I like the full level approach. The top level is the business system architecture. And this is where we say, how has identity information collected? What's it used for what sort of entitlements do I have to be that whole provisioning aspect of it. We need to understand. And the artifact at the business systems level is a process maps. I love process mapping.

It doesn't matter what tool you use BPMN is very popular business process mapping notation. I Def zero as another one that's popular, particularly in government tool. Doesn't matter. The importance is doing it. I always remember a project I worked on for a Sydney based university. And when we came to the workshop to do the process map, there was actually groups within the use, the, the, the, the university that were quite in violent disagreement with how the process worked well, you cannot expect, and I am processed project to be completed successfully.

If you don't understand the basic, how the provisioning process and the changes that you go to accommodate work. This is something that, that actually you are making them do their homework to be able to actually implement the IMS. Yes. If they've got an enterprise architecture already in place within an organization, it tends to be quite easy.

But if you don't see that, and if you're managing an I am project, you need to ensure that work's done either do workshops as I've done in the past, or get them the tossed and come back and review it whichever way you need to have that business system architecture mapped out at the top level. Great. So you mentioned four levels. What would be then the next level Coming down from that? It's the application portfolio to understand, and we've, we've already talked about the identity fabric having to accommodate all of the corporate applications.

In many cases, organizations don't understand that I did a project for a Singapore government agency, and they didn't even know who the systems owner was for some of their systems. So what I recommend is there's an inventory done that maps out that who does own the system. Who's responsible for it. How many users are there in there? How many active users are there within the application?

What, how many admin positions are there? What sort of technology does it use? What sort of authentication mechanisms? And I like a page for each application that answers all of those questions. So then the IAM professional can pick that up and say, huh, now I understand. So having that application portfolio I've done with this inventory, being the artifact of that activity will greatly increase the probability your IAM project will succeed. Okay.

That also means that you understand actually which capabilities within the IBM architecture are actually required, which may be missing, or at least not fully implemented, where you also have to supplement additional core capabilities to fulfill the business needs. Absolutely. Like in some cases then application will be a basic web app. Okay. That typically quite easy to do and handle, and other cases there'll be a client server operation, and maybe that'll actually be storing identity information.

Well, that's a whole different ball game. So understanding the applications you've got to support as part of your fabric is critical to getting it right. Right. Okay. Yeah.

That's, that sounds really reasonable. Having the right people on board, having the process understood, having the applications at hand, when it comes to implementing what would be then the next level, The information architecture. So to understand within those applications, what identity information is actually required and in some cases stored. So the information architecture we'll typically use an artifact such as an entity relationship diagram.

So the entity relationship diagram will show each of the applications that are being supported and the data, the identity data that it requires each of those requires. And then it'll show the arrows as to how it gets it.

Now, is it pulling it from an enterprise directory? Is it being provisioned in there as part of the HR process?

You know, the entity relationship diagram, we'll show, we'll show you that. And then you won't forget an application. You won't have your name, you won't be halfway through. And an I am project and somebody comes along and says, oh, what about the ERP system? Have you considered that?

You know, that's, that's, that's what Martin's referring to with some projects are just too big. You know, you need to understand the pieces and the, an architectural approach will help you understand those pieces.

From, from my experience, I've seen that in many cases, identity, quality is not as good when it comes to all these yeah. Entities that you mentioned that this entity relationship diagram. So there are pieces of information that need improvement. Is this something that you see?

Oh, big time. Okay.

So again, when you get into a project that dirty data is a, is a, is a big, a big issue. So at some point in your project, you're likely to have to have a data cleansing activity to be done. So understanding where the data is will help you do that.

Okay, great. So we have we've come through business systems, architecture, applications, information, architecture, level four is missing. Okay. That's the technology architecture.

And, and often that's, that's accommodated. That's typically one area that most organizations start with getting the technology architecture, right. And that's good is important. Okay. This is where we look at the technology patterns. That's a supportive, you know, if everything's a web app, it tends to be quite easy. If we start throwing in a cloud server apps, if we start throwing in mainframe applications, you know, we've got a racket directory to accommodate each different pattern, you must support becomes another cost. So that's the reason that you need to understand it.

And even from the basics of, are we on a windows infrastructure? Can we accommodate Linux applications? All of those questions need to be asked if we're Linux, what version of red hat do we support? For instance, you know, we need to know all of that sort of information. And that's where the, the technical architecture comes in the artifact here as our technology patterns. And I like to have them graphically written out.

So we, you know, it's just, it might be a web app, but is it an NTR app? Does it have an application server presentation server and then a backend database?

So, you know, we need to understand how, how big that is. So mapping out the solution architecture, those four levels will greatly increase the chance that your project is going to be a success.

Okay, great. That sounds really promising from, from, as you've mentioned, them, technology architecture is the starting point for many organizations. Maybe that also is one reason that if you only look at an IBM project from a technology perspective, you are destined to fail because you're really more in all the three other aspects that you just mentioned. There's people, there's processes. There are applications, there is data. And if you don't take care of that, so actually it's solving business issues on behalf of an IAM project for it to be successful.

Then, then you really lost. If you don't do that, thank you very much, Graham, for giving that first insight. If you have to have one first real good recommendation for a project where the project lead is feeling that things are going wrong, what would be the first recommendation for them just to start with where to begin, Then they need to make sure there's an understanding of the full scope of the work required.

So I would be going in that circumstance, if they feel it's going off the rails, they need to go back to the project sponsor and get clarity as to what is the full scope of the work required. They don't want to find that out as they go along the way by doing that, that would be a far better understanding of the organization's it infrastructure. In many cases, you find people in an organization that don't really understand that organization's it infrastructure.

So the poll I am a professional needs to help the person understand and going through an architectural approach will help that to happen. Okay, great. Thank you very much, Graham, for that first insight, just to sum it up, we talked about how to deal with, I am projects in an adequate manner from a solution architecture point of view. Grant mentioned the business systems architecture as the first level, then application portfolio information, architecture and technology architecture. So these are the four levels that we consider today.

There will be a follow-up podcast in a few weeks, which will more look at project management of the documents that we mentioned today in that podcast. That is the KuppingerCole. I am referenced architecture and everything around the identity fabric is available at our website KuppingerCole dot com. And as things are currently completely changing when it comes to having events and having conferences around the world, I want to quickly the KC virtual event on identity fabrics and the future of identity management, which will take place in a few weeks.

And if you're listening to that podcast later that year, all recordings from that virtual event will be available also on our website, just by registering there, you can have full access to this information, that's it for today. Graham, thank you very much for your time today. Any final words that you want to add as recommendations as a thought to consider?

Yeah, please look at our, I am projects and let's make them a success. So I thank you very much for having me on this podcast. Okay. Thank you very much. And looking forward to a next edition together with you. Bye-bye