In this second article on Identity and Access Management (IAM) we look at why many organisation face difficulties transforming their IAM ecosystem, and how IAM programmes should be approached and structured. In our previous article – Identity and Access Management: back in the spotlight – we identified the main drivers of IAM improvement and four key maturity levels. We established that dedicated, proactive programmes are essential in climbing up this maturity ladder.
IAM is a far-reaching concept. This understanding must be put into practice when running such a programme, to avoid quickly falling into common pain points. Let’s take a closer look.
IAM programme challenges: some typical examples
Three main drivers which are putting demands on IAM are business change, cyber security, and user experience. However, organisations often undertake IAM programmes driven, exclusively or primarily, by the desire to migrate to a new solution. With technical debt or tooling the only real concern, IAM programmes can face issues very quickly.
1/ Broad impacts of migrating to a new solution
Often the desire is to simply migrate to a new tool or perform a major upgrade of the existing technical asset, whilst leaving all other elements of the IAM service unchanged. This can have unwanted effects on these other aspects. For example, a new tool will likely bring about new approval processes, which will require staff training on a new user interface. It could even require entirely new leavers and joiners’ processes for HR. This pain point ultimately boils down to a lack of assessment of the impact of the technology change, in the context of wider IAM ecosystem.
2/ An ever-growing list of requirements
When an organisation realises that IAM change is not limited to the tooling, this can often open the floodgates to an unrealistic number of new objectives. Stakeholders end up demanding more of the programme (such as better user experience and increased ITSM integration) – despite these new objectives not being originally identified and catered for. The programme can become a vehicle to voice dissatisfaction with the existing end-to-end IAM service, causing scope creep. This dynamic can quickly bring pain to the programme across change management, budget, and solution architecture.
3/ Forcing a like-for-like implementation
Once interactions between the new IAM solution and its perimeter services are fully functioning, you still need to consider differences in design philosophies between the new and the old tool. Key product design differences must be catered for. If not, organisations can end up requiring custom code and complex configurations on the new solution, simply to match the previous setup. This can impact on vendor support, maintenance, overall performance – and not to mention the need to retain a huge body of knowledge on the complex customisation. By going down this road, you can cause more trouble than that you are trying fix. A true butterfly effect of issues can be on the cards when trying to force a like-for-like on different tools.
The key to avoiding these common pain points is to acknowledge that IAM must be viewed as a transversal topic, which impacts technology, people, and processes.
What is the recommended approach then?
Key to success is the acknowledgement that IAM improvement is a far-reaching programme. The implementation of new solutions is only the tip of the iceberg, and key impacts should not be underestimated. Under the covers, we believe the key streams of the transformation are:
/ IAM solution renewal: the deployment (or upgrade) of the new IAM solution. This includes solution architecture, engineering, and technical migration.
/ Modelling of rights: existing access rights must be translated into the new IAM ecosystem, such as business roles and application profiles.
/ IAM data cleansing: the stream to review, cleanse, and validate reliability and correctness of existing user data. For example, recertifying the role of a user and validating their line manager to ensure the correct person is approving access requests.
/ New processes and change management: this includes new ways to request and review access to applications, new processes to manage leavers and joiners, and training staff.
/ Interoperability with other services and assets in the IS: for example, integrating the new IAM tooling with the SOC may require re-engineering the log ingestion into the SIEM and API calls. Another typical piece of work is to coordinate with concurrent AD migrations or upgrades.
We recommend structuring the IAM programme such that each of these topics is covered by an individual project. The design authority of IAM policies should operate at the programme level, with clear inputs to help guide all streams.
Critical to success is also strong sponsorship and a publicized vision of the objectives. Because IAM programmes touch so many organisational domains, it is essential that the programme manager and PMO function are supported at the executive level.
Finally, flexibility is key to manage changing circumstances and constraints. Here’s other tips to ensure the programme can remain on track to meet its intended objectives:
/ Find a good middle ground between legacy assets, the ideal target state & the capabilities of the new solution: the target state should be based on what best helps deliver the end-to-end IAM service to the business.
/ Evaluate the possibility of integrating new solutions with existing services, even if not originally envisaged in the ideal target state. Simplify and rationalise where possible. This will help in both the short term and the long term.
/ Do not rule out the possibility of retaining existing tools which were originally due for decommission, if it supports the overarching IAM objectives: sometimes it is best to maintain some existing assets, rather than decommission and migrate for the sake of IT modernisation.
In this article we have seen how defining key objectives is vital for the success of the programme. Understanding the breadth of IAM change is crucial, both for structuring the programme, and delivering on time and on budget. This approach will also allow programme managers and each stream lead to implement flexible measures to migrate from a legacy ecosystem and legacy applications to the new sol
