Patrick Parker - IAM Meat and Potatoes Best Practices

So finally last, but definitely not least Patrick Parker, the founder and CEO of empowered ID. Thank you for, Thank you very much.

Well, thank you everyone. My name is Patrick Parker. I'm the CEO of empower ID. I've been involved in identity management for the last 15 years.

Now, this discussion today you've heard many visionary discussions. The last one was very an excellent discussion about strategy about the future. This is not one of those today's discussion is more about just meat and potatoes.

So in, in the United States, we have a saying that something is meat and potatoes. If it is just a basic practical essence of something. So today's topic is about meat and potatoes, identity and access management project success, the pitfalls to avoid what to look out for, what to avoid as you're moving through your identity and access management projects, and then the solutions to those, those pitfalls, the best practices. And we worked with carpenter to attempt a, a corollary for meat and potatoes. So I don't know if we got that close. There weren't many food analogies we could come up with.

So projects in general were difficult identity and access management within the realm of projects tend to be large, larger enterprise projects, have a higher failure rate. They're more complicated. They hire more planning and more coordination, identity and access management projects are a more difficult sub segment of this. So therefore, best practices, coordination, avoiding pitfalls are even more important.

Now why identity management projects are so much more difficult is that the goal of identity management is to encompass all of your it infrastructure to integrate your HR systems for onboarding and offboarding to integrate your different applications, whether they're on the cloud or on premise to have a single unified security model and to have a process automation framework. So they necessarily touch as a goal, more of your it systems. They also require the coordination of the individuals that work in those various departments. So because they touch more systems, they talk to more departments.

It requires a greater coordination of effort between them also identity management projects. Typically there, there is no quick exit from the project you're talking to so many different systems. Those systems are changing over time. The landscape's changing, moving from on-premise to cloud. The threats are changing. The vendors are evolving and adding new features and new functionality or new protocols.

So necessarily identity management are typically gonna have an ongoing project process that is continuing throughout to eternity pretty much that you're gonna have to plan for and also identity management. Hasn't traditionally been a separate group within the organization. The directories management groups typically well defined the desktop management groups typically.

Well, the HR groups typically well defined in the application. Developers groups typically well defined, but identity management doesn't really have a home in many organizations. So there's no dedicated department, no historical organizational memory for how to execute identity management projects and how to manage them over the long run. Now identity management projects like any project, they can succeed. It just like skydiving. It is a risky business, but very few people die from it because you follow the best practices.

You need a parachute, your best practices, and your avoidance of pitfalls is your parachute to, to ensure that your project's going to succeed. So one of the key best practices is to look at identity and access management, not as a project, not as a we're gonna do this project, we're gonna buy a product. That's gonna have a clear start. Hopefully it's gonna have a clear stop and we're gonna get outta that business. We're gonna just maintain it. Identity and access management is a series of ongoing projects. So it needs a program management perspective.

The idea that you're gonna be integrating multiple projects, multiple teams over a long duration and more projects will be coming. So one of the first pitfalls, which is pretty well known is what we call lack of executive juice. Juice would be power influence the ability within an organization to get things done.

Identity management needs executive juice, more than most projects, because you have the involvement of so many different departments that if you hit a roadblock, if it the identity, management's one executive within one department and they need the HR team to work with them on data mapping, they need the development group to do a little bit of customization. If you do not have an executive sponsor that has the juice that can push through roadblocks, that can get team members from other teams to participate, then projects can stall. And that that's an often a point of failure.

Now, one, one point also on that is that you're the executive that is backing your initiative. Definitely make sure that you're aligning with their goals for the business. Typically they're more in tune with the overall organization's goals. So you want them to continue backing the projects to make sure that you're hitting their success points as well. Second common pitfall that we see is alienating the experts we've been involved in products, selection, processes, where it'll start in one group, let's say it starts in audit.

And then at the last second, when they're making a product purchase, they let it know, or it starts in it. And at the last second, they let audit know we've actually had technical people call us at the last second, when they were first notified that the, that the product was selected. Look in a frenzy, wondering what's wrong with this product? How are we gonna integrate it? What do I need to do? How is this going to affect my job? And that's typically the thing you need to pull in multiple team members from across different departments and plot them a plan for the future.

If I was doing active directory management or L a management, what will my role be in this new future world of identity access management? How can I win? How can I succeed? How do I see a path where I'm going to prosper in this new environment?

I, a second pitfall to avoid that we see is because it's not identity management is typically doesn't have a home. It's not the development group. It's not the, the DBA group. It's not the HR group. Often you'll pull people for that project because it's not treated as an ongoing program. And they're brought in from different departments. They think they're gonna work on this one project. They're gonna get in. They're gonna get out. And then they're gonna move on to another project.

Now, the challenge with that is that they're perpetual newbies. If you're shuffling people through your identity management projects, they're always hitting those first hurdles that everyone hits. They're not maturing in their expertise in identity management. They're not maturing in their expertise, in delivering identity management functionality and maintaining the solution. So they're perpetual newbies, always making the newbie mistakes, which are costly and often lead to the project, not succeeding.

Also, you wanna make sure that you pick people that are up to identity and access management is a very technical realm, as well as process driven. It has to match the organization's process. So if you pick people who you think they're not gonna be in there very long and their skillsets might not align, it leads to frustration. And then when you realize that they may not be, might not be up for the task, it presents an HR problem of what to do at that point. It can be demoralizing for the team.

So a typical team composition that you would need, these aren't necessarily dedicated staff that only work on identity management, but they are named individuals that they know that their role is DBA for the identity management solution. They know that their role as developer for the identity management solution, they know that they are going to be based their evaluations on that. They're gonna develop a skill set. They're gonna deepen their expertise and that when you start another identity management project, they know that that is their area of skillset.

So you, you're not shuffling different people through. They're not newbies and they can continue to improve over time. So every project gets a little bit easier for the team. Another pitfall to avoid is what's the empty mansion in the United States. We have a lot of people that spend the maximum amount they can to have what they call a Mo mansion, which is an extremely large house. And then they can afford the furniture. So go to their house. They have a, a mansion elaborate mansion, and there's no furniture everyone's sitting on, you know, futons or, or tiny chairs.

So one thing in identity management that can be, needs to be avoided is spending all of your money on the software and not budgeting for services, not trying to bite off all the software in one chunk and not having the Money allocated So that you can actually implement the Software. We'll do a little change up here. Thank you. So you wanna make sure that it, you phase in the modules over time, that way that you have enough allocated for internal resources or partner resources for consulting to ensure the success of implementing those modules.

It, it, but you don't want them to end up a shelf or you don't want them to be poorly implemented. So you can phase in additional functionality over time and make sure that the, the last bit of functionality that was purchased was successfully implemented.

Oh, we, we skipped ahead there. Another pitfall to avoid is blank canvas dev design. And that's typically where a product will be purchased. Every identity management pro product has a different bent to it, a different set of features that it's better suited a different paradigm for how you would implement functionality to match your business process. In that product blank canvas design is really where you are not familiar with the product with its built in capabilities. What's out of the box, what to use to make it that's easy to do.

And what's a completely going against the grain of the product. And then, so you design a solution without any of that in mind, that typically leads to lots of customizations that would not be necessary custom code to maintain. And also just additional complexity.

When, when the product upgrades, you're not really taking advantage of the features of that particular product. Now, the, the phase one high bar, this is probably the most common source of project failure that I've seen over my history. And that's really where an organization identity management's typically new to an organization or to the people that are involved in the project. And often the, the goal of the organization or the goal of the team is to hit the, the, you know, the sexiest most difficult project deliverable.

First, often this is provisioning, automated provisioning, automated deprovisioning integration with your E R P system. And typically the team is just not ready for that. Yet. Setting a high bar that early on in the process sets everyone up for failure. It doesn't give them any easy process to develop their maturity, to get a quick win. So typically the best process to use is to analyze your processes. See what's costing you money. What's a high volume process, but what is less risky?

What's something that is not gonna be as technologically challenging is not going to touch so many systems and what can be done in a shorter amount of time to show the executive management that this investment is producing results is producing ROI, gets everyone off on the right footing. Another area to look out for is testing identity management. Typically you're matching your business processes. There's always gonna be some customization to it.

Lots of features where you might implement certain features for a certain organization, certain policies, and a lack of testing can often lead to a, a, not a project success. So testing needs to be something that's planned out for in the, in the beginning, it's going to be an ongoing process and it needs to be something that, that you gain experience with, or that you pull in people from your development testing group to, to participate. Another key area is how do you approach these projects? It is a program they're going to be ongoing.

How do we chunk off the deliverables in a way that's going to lead to maximum success as you're maturing through your identity management skillset, the waterfall methodology and the software development lifecycle would be to do the design and planning all up front. And this can be a challenge because it's, it's new technology. You're not familiar with the product. You're typically not familiar with identity management. So doing all the design up front will typically lead to, to a design that doesn't conform to what you need later.

Once you're more familiar with identity management as a whole, and also the product that you purchased. So the best approach is to break off your deliverables into small chunks and to do agile delivery. Do key deliverables, quick wins in a cycle. Each cycle will include the design and requirements just for that particular deliverable. So you're not over designing. You're not designing too far in advance. And then you'll be doing the testing, the development and the deployment, and you'll have much, much quicker results and more to show to management.

Another area is closed door design usability right now, more than anything is a, a hot concern. Identity management is under the same pressure as every other area of enterprise software to have a better user experience, to show the corporate look and feel to provide something easy to use in an Apple-esque type manner. So a lot of it departments will get involved in designing the product or designing the identity management deliverables to make them more usable. And everyone likes to put on their designer hat, you know, be a, a Minite jobs, but often we'll overthink it.

We'll be designing behind closed doors. We don't speak to the users and we'll come up with what we're sure they're going to like. But then when it's presented to them at the end, they don't really like it. So get feedback early, present each deliverable deliverable early in the process to the end users, see how they use it, watch them use it, and then tweak the design as you go. And you develop expertise in that area. And then the last key key pitfall or best practice is building without architecting the plan, not thinking from a services perspective.

So in the best practices to think about services, one, one automation, engine, one authorization engine, one authentication broker, or Federation service in the middle that can talk to your systems. So avoiding point solutions where each solution has its own security model, its own audit log. It its own automation engine design from the upfront that you're going to be adding on functionality, but using base services and making them reusable, having one centralized set of services that are used across all your different deliverables in all areas of identity and access management. And that's it.

Thank you everyone.