For some time, we have been discussing the advantages of a co-sourced model for Identity and Access Management (IAM).  In this two-part article, I will focus on the first logical step for migrating from a traditional IAM deployment model towards a co-sourced, managed service model: IAM Operations Management.

Operations ManagementLet’s face it, while there are lots of merits to “ identity-in-the-cloud” services models, they are not yet a mature technology so organizations are somewhat reluctant to fully embrace and adopt them.  Another reason is many organizations today already have some sort of IAM footprint in their environment.  Therefore, for the foreseeable future, organizations will continue to deploy IAM infrastructures on-premise.  I use the term “on-premise” to also include – co-located or hosted IAM environments that are considered part of the “internal” IT environment or the organization.

For it to succeed, any new deployment model for IAM would need to provide flexibility and allow for the IAM infrastructure to be hosted on-premises as a starting point, even if it is managed remotely or delivered via an appliance-based model.  Forcing organizations to move IAM infrastructure off premises from the onset will most likely not succeed.

This flexibility is what we refer to as location independence – it does not matter where the organization wants to host its IAM infrastructure.

The Question

So, how can organizations start shifting from traditional IAM deployment models towards a co-sourced, managed services model in a location-agnostic manner? Our answer: start with a managed services approach for IAM operations management.

This is something we have learned, and validated from over two years of working closely with customers across various industry verticals, such as Government, Retail, Financial Services and Healthcare. A managed services approach to operating and maintaining the organization’s IAM infrastructure is very appealing.

This is what we offer through our SCUID (Secure, Co-Sourced, Unified IDentity) Operations service.  It provides a cost effective solution that enables organizations to optimize the operations and maintenance of their IAM infrastructure.

Symptoms and Behavioral Patterns

Over the years, helping customers implement their on-premise IAM solutions, we have learned that traditional deployment models for IAM have very common behavioral patterns once the deployment is transitioned into production:

  • Call for help - Most customers approach IAM implementations as projects, so once the implementation is completed, the Call for Helpteam is dissembled and the know-how is diluted. The implementation team, often an external consulting firm, disengages. Despite good documentation and knowledge transfer, the customer’s operational staff still ends up needing to ask questions about their environment.  For the most part this need is only realized during an emergency/outage or during a change [gone wrong]. In these cases, the operations staff calls on our consultants directly asking: “do you remember what was the command we used to make X happen?” “Which configuration parameter was the one I needed to change to make Y happen?”   These questions did not exactly go away over time but kept coming. This indicates that the organization may not be ready to optimally maintain and operate its IAM infrastructure.
  • Fall off the upgrade treadmill – When the IAM implementation is rolled into production, the software products involved are typically up to the current and recommended patch level.  But as with any software, and especially Enterprise software, the vendors release fixes and patches,Falling off the treadmill which customers then need to apply, and in some cases are required to, in order to continue to receive support.  Or worse yet, when an issue is found and the customer calls the vendor support desk, the first question from the support personnel is: “what version and patch level of the product are you running?”, and almost immediately after the answer, comes the dreaded: “you need to be on patch level X [typically the latest or thereabout]. Please apply this patch and call us back”. And voila, now the customer needs to make a decision: undertake the upgrading or patching on its own, or start a consulting project to bring in external expertise to plan and carry out an upgrade.  And in many, many cases, these decisions need to be made while the “house is on fire”.  Definitely not the best situation to realize that an IAM environment needs to be actively nurtured to stay operational.
  • Need to make minor changes – AfterMinor Changes the IAM environment has been in production for some time, customers’ needs evolve incrementally. A few weeks after deployment,
    • the approval group for a given workflow has to be updated,
    • a new user attribute needs to be added to the profile,
    • a new application is being integrated for provisioning,
    • a target system is being upgraded or patched and the provisioning connector now needs to be updated and/or reconfigured.

In most cases, these changes are reactive (i.e., the situation presented itself without much warning), and the impact to the interested line of business or stakeholder needs to be dealt with promptly (i.e., I cannot delay my ERP upgrade simply because you don’t have the provisioning connector for this version or it has not been certified by your IAM vendor). Now what do we do?

Has your organization experienced any of these symptoms?

In part 2 of this article, I will discuss traditional and new options available to addressing these symptoms.

SCUID Operations Data Sheet

Frank Villavicencio

Frank Villavicencio