The challenge with implementing Identity and Access Management (IAM) programs (well, one of many challenges) is trying to realign moving timelines back to the IAM implementation timeline. As I was told once, business does not stop and you need to move at the speed of the business. Given this, you are probably looking at a timeline like the below.
Business, applications and general work will keep moving forward creating all these new branches from the implementation timeline (along with anything previous to the start of the timeline). Each of these branches represents a failure point in the IAM program and at some point, you will reach an overall breaking point.
The goal is to start purging these individual branches back into the sacred timeline (I watched Loki again recently so sorry for the loose references). This aligns with the IAM strategy of centralizing the IAM capabilities, enforcing security policy, and improving the user experience. You’ll be looking at something like the below timeline. Your timeline still moves forward, but as you go, you can start purging the branches back into your timeline.
Well, that looks great on paper and in principal, but what does that look like so that we don’t reach the failure point? Honestly, there’s no easy answer or perfect solution here, and in all the organizations I have worked with I have had different successes, but you can start with a common basis and adapt to your needs and organizational goals.
When going through these conversations and planning, I centralize on some key concepts.
- Make a decision, don’t get stuck in analysis paralysis.
- Executive / business support is critical (SUPER CRITICAL).
- Publish timelines and integration standards.
- Go for the quick wins and low hanging fruit.
- Follow standards and established integrations, resist the urge to over customize
- Plan and prepare for the long-haul.
It sounds simple enough to start, just make the decision, but this is where I see most projects and programs fail. There are a TON of good options out there, and you will have multiple stakeholders giving feedback, so is easy to get stuck in analysis paralysis. But ultimately you need to take what information you have and make a decision on moving forward. You aren’t going to win everyone over and be able to account for every edge case. The longer you wait, the more you delay, the bigger the problem gets and harder the realignment is going to go. Trust the process, reviews, requirements, and get started.
Once you have a plan and have made the decision, you need to make sure you have executive and business alignment. You can make the decision, but when you go to that next meeting, if the organization and executives are not behind you, you won’t have much success. So, with the decision (#1), make sure you have your executive sponsors lined up to help drive and support the implementation.
I’ll admit, this is one area I struggle in, but you need to publish timelines and standards. Its way to easy to run once you are ready to go, but you need to make sure everyone knows where you are, where they need to be, and how to get there. I had a mentor once that said if you get to the finish line and no one is with you, you did’t achieve anything. IAM projects are the same, you can implement all day, and do some really cool stuff, but if you don’t bring along the teams and stakeholders, they’ll keep on their own paths and you’re stuck with really cool shelfware.
So, we have a technology / plan, have support, and we have published the timelines / standards, now what? Go for the easy win! I always go for the hardest first because I feel if I get the hardest done, is easy sailing from there. But, I’ve had more success doing the easy stuff first and start getting some traction. Is easy to get stuck in design, customization, etc. with the hard integrations rather than get some of the low hanging fruit done and working then move on to the more challenging integrations. What are some quick wins? Password self-service, basic joiner / leaver workflows, cloud / OOTB SSO integrations. These all are well documented and can give some quick wins in the program to help set you up for the more challenging integrations.
One reason for doing the low hanging fruit and quick wins, it starts getting traffic and usage using known, established standards such as SAML, Oauth / OIDC, REST / SCIM, etc. So, when you get to that complex custom application that wants to do custom connector, complex workflows, etc., you can fall back to the standards based approaches to show them a simpler option. Given a void, people will ask for how they want it done until you show them better, simpler, integration patterns. So, quick wins help you drive standardization later on as you go to more complex integrations.
Last, but not least, plan for the long haul in terms of project implementations. IAM projects are a continuous effort. You may have a 1-2 year plan, but this is just the initial implementation. Make sure when you communicate your initial request for funds, planning, etc., it is established that this will be a continuous effort and require standard funding. Between on-going operations, maintenance, new applications, licensing, etc. this will be on your budget going forward. Me personally, I recommend people put this as a separate line item of security / IT (can be in the same buckets, but recommend separate line item) since this is an organization wide service. When added to standard IT / Security budgets, can get watered down in other budget items. Since this has impact on employees, customers, compliance, it should be documented as a cost to the organization with maintained budget.
From this point on, my projects have gone all over the place in terms of options for bringing things back into the main IAM timeline. Couple things I have had success with that may not fall into one of these general buckets:
- Once you get things moving, establish sun-setting timelines / deadlines for applications that do not integrate. Is great visibility and leverage when you can start saying anything not integrated by X date is going to be blocked.
- Although, be cautious on this one, has burned me also. If you’re not ready for the influx of requests, can quickly become a pain point.
- Have SDKs, integration kits, example code, wikis, etc. ready to go when asked. I get burned on this a lot, but the more you can publish information, the less you’ll need to handle from a request perspective. Plus, most developers I have worked with just want the how and they’ll integrate quickly with their stacks. But, if they don’t have the information / guides, can quickly become challenging.
- Lunch & Learns, knowledge sharing, general showcase meetings work wonders. I love talking and doing presentations, showcasing what I’ve built. So, I like to plan team and general consumer lunch and learns and other knowledge sharing sessions. This provides a group forum for people get questions answered, see capabilities, etc. This can go a long way in later integration, questions, capabilities discussions when they come up.
Whether you’re starting greenfield, trying to realign failed implementations, or just trying to modernize aging infrastructure, use these in your IAM program planning and implementation. But, realize this is not everything and you’ll have your own spin on each of these to fit your environment and implementation.
