In our last two entries, I blogged about the changing faces of the stakeholders of an Identity and Access Management (IAM) initiative. The first entry described the stakeholders during the inception phases of the initiative, while the second entry focused on the stakeholders that are needed in order to get the IAM initiative funded.  This entry will focus on the "Off to the Races" phase of the program.Off to the races

In this phase, the first objective should be to get the minimum team together that will be required to put together a practical IAM roadmap for the organization. The perfect forum to do this is the Identity & Access Management workshop.

The success of the workshop relies heavily on the attendees having the right combination of knowledge of the existing processes and infrastructure on the one hand, and executive decision making authority on the other.  The workshop is therefore designed to engage the attendees in a roundtable discussion with key stakeholders in order to foster discussions around the IAM requirements, in order to identify the appropriate solutions as well as the foundations for an IAM roadmap. 

Stakeholders Overview

At this stage, the four types of stakeholders are Process Owners, System/Application Owners, Data Owners and Executive Sponsors.  Each type has subdivisions, and an individual may fall into multiple classifications.  During a workshop, sessions with the relevant stakeholders should be scheduled in order to perform some preliminary due diligence.

identity management stakeholders

Process Owners

Process owners (aka Business owners) are responsible for interacting with corporate systems or applications in order to manage identities from a functional perspective. These individuals tend not to interact with the systems or applications from a technical operations perspective, but are rather end users from a business process perspective.  Therefore, sessions with business process owners should be scheduled first in order to understand the context of the system/application and identity data.

  • Examples: HR Functional Administrators, Deployment Managers (for applications and networks), Help Desk Administrators, Portal Content Managers, Change Order Approvals Manager, Physical Security Administrator, etc.
  • Questions to Ask: How are users created/deleted/disabled? How are passwords changed? How are privileges granted to access the system?  How is access to the application reviewed/recertified? Are approvals required? If so, for what actions? Are there multiple administrators for the system or application? If so, how are responsibilities divided? Is there a delegated model?  Are there any future changes expected to the existing processes and why?  Are there any upcoming needs that may require changes to the existing processes?

System/Application Owners

System/Application owners are responsible for maintaining various systems or applications from a technical perspective.  These individuals may leverage an application-specific administrative interface in order to maintain user accounts.

  • Examples: Active Directory Admins, Content Management System Admins, Unix Administrators, Vendor Portal Admins, etc.
  • Questions to Ask: What are the different user types within the system? Are there multiple ways for users to be created/deleted/disabled?  Who calls whom if there is a problem with a user’s access?  How is user profile data updated in the system? What is the access security model for the app?  Does the application function as a “user” for any other applications or systems?  Are there any existing policies that dictate how identity data in new systems/applications is to be managed?  Are any new critical systems/applications expected to be deployed in the near future? 

Data Owners

Data owners are responsible for managing identity data within a given environment - major identity data repositories.  They are usually database administrators and directory administrators with an in-depth understanding of the size and flow of data in the infrastructure.  Data owners should be knowledgeable of any online or offline synchronization activities that occur between repositories, as well as data transfer methods that are employed.

  • Examples: Enterprise Directory Architect, AD Architect, Database Administrator, etc.
  • Questions to Ask: How is data entered into the various repositories?  Which system is authoritative for what identity data? Are there synchronization activities of identity data? What tools are utilized to pull/push data?  How is identity data classified?  How is access to the data managed?  Are access control lists or other access management mechanisms utilized?

Executive Sponsor

Lastly, an executive sponsor is an individual (or set of individuals) who has the authority to make relevant decisions and changes regarding existing processes that manage identity data in the organization.

  • Examples: CIO, Compliance Officer, IT Director, etc.

Some Relevant Points

  • The examples of IAM Workshop Stakeholders provided above are typically not 1-to-1, since overlap of job functions is common.  For example, one individual may function as a system owner as well as a data owner. In some cases systems administrator may function as a process owner as well (Ex. Unix Systems Administrators).
  • The two critical ingredients for a successful workshop are knowledge of the existing identity management related processes (from both a technical and business perspective) within the organization, and the decision-making authority regarding changes to the existing processes.  Knowledge of the process without the ability to make changes may result in a plan that cannot be executed, while authority without the knowledge of what exists results in aspirations without a plan of execution.  It is critical for both aspects to be well represented during the workshop.
  • A common misconception regarding the IAM workshop is that there exists a direct relationship between the number of parties present at the workshop and its efficacy.  From our experience, the opposite holds to be true in most cases.  The best result is to keep the number of parties present below a threshold without sacrificing the two critical ingredients for a successful workshop mentioned above.  An excellent approach is to seek out individuals that can accurately represent multiple systems, applications, processes and data repositories.  Often times, an individual can accurately represent both the technical and process aspects of system or systems – or an individual may be able to represent data flow within the entire organization.  Such individuals are typically extremely useful in the workshop.
  • Another common misconception is that decisions regarding scope definition for identity management projects should be deferred to after the completion of the workshop.  For larger organizations, a preliminary scope check of the identity management initiative is critical in order to ensure the practicality and effectiveness of the workshop. Rather than initially seeking for a comprehensive map of every detail regarding an identity management infrastructure, it is better to focus on gathering stakeholders from the business critical applications, systems and repositories first. Remember, you can only boil one ocean at a time.


Ash Motiwala

Ash Motiwala

I’ve been in the identity space for most of my career, and I’m still passionate about it. Anyhow, a CTO is supposed to be the person who sets technical vision for the company, but honestly – Identropy has way too much brainpower for a single person to do that. Instead, I get my hands dirty with the customer development process, lend a helping hand wherever its needed, and I have the privilege to talk identity with some of the brightest minds in this space every day.