Getting Started with IAM Co-Sourcing: Operations Management (Part 2 of 2)
Posted by Frank Villavicencio on Tue, Aug 10, 2010
In part 1 of this two-part article, we provided the context and motivation for organizations to adopt a viable model for handling its IAM infrastructure operations. In this article, we will discuss options available to address this need.
What Are the Options?
Symptoms such as the ones described in part 1, indicate that your IAM operations are not optimal, and that perhaps your organization is not well poised to optimally run the environment. They are also, entirely common to any IAM deployment of any size and scope; particularly, Enterprise deployments. So what options do you have?
Here is what has been traditionally available:
- Insourcing – this was the de facto option up to five years
ago. The organization bit the bullet, hired expensive and specialized talent, trained these resources on the IAM product, invested in their ramp-up, often shadowing during the implementation cycle, and retained them to support, maintain and evolve the infrastructure. For the most part, this model has only worked well at large organizations, which can afford having dedicated staff that can be groomed to take over the operations management role. But for the majority of organizations, the operations staff is not dedicated and rarely has the right skill set and experience to take on IAM. For the most part, the resources are either too expensive or not available in the geographic location where [and when] the organization needs them. With luck, the organization will retain these resources long enough to realize a return on the investment, before seeing them go to an IAM consulting firm or an IAM vendor company.
- Outsourcing – this option is more predominant nowadays.
The organization contracts with an external provider who assigns a support engineer onsite or remotely to look after the IAM operation. They are typically focused on break-fix and remediation of issues, not on the ongoing evolution and configuration changes to the IAM infrastructure. The experiences tend to be mixed according to what we have heard from customers:
- On one end of the spectrum you have offshore outsourcing, which is great from a cost perspective, but is a nightmare from a cultural and organizational fit standpoint. There are varying degrees of overall satisfaction with the level of competency of these resources, and the effect of the time zone and communication barriers.
- On the other end, you have the onsite consultants who work alongside the customer staff. This scenario tends to work better from a customer satisfaction standpoint, even though attrition is an issue. Cost tends to be high, making this a less appealing option to executive management.
The Answer, well... Our Answer
At Identropy, we propose a different model to address this need: IAM co-sourcing.
The idea is to have a mix of staff and technology working together to optimize the operation of the IAM infrastructure. This model is delivered as a co-sourced managed service that combines a lightweight on-premises footprint with a cloud-based backend to provide a best-in-class operations management solution for IAM infrastructures. The organization can outsource monitoring, reporting, maintaining and remediating issues in their on-premises IAM infrastructure via a scalable service that is governed by defined service level agreements (SLAs), managed by a team that specializes in – and has a deep pool of IAM knowledge to draw from – IAM infrastructure and delivery.
This model enables the organization to scale operation management of their IAM infrastructure cost-effectively and with sound IAM expertise, without having to increase their Operations staff.
How is this Different from Traditional Monitoring and Support Models?
This co-sourced model provide much more than traditional system monitoring (i.e., monitoring that a system is up and running). It specializes in the IAM functionality that the customer cares about: Are events being synchronized to the target system? Are the LDAP queries returning the expected values in the appropriate time? Are there events being queued up in a particular workflow? Is the Acces Request web interface available and can users log in to it? Through a specialized correlation engine, it determines whether that behavior is abnormal for a given organization. All of these considerations go above and beyond pure system monitoring.
Additionally, the co-sourced model offers more than a break-fix service for issue remediation, since it also includes the notion of proactive up-keeping of the environment and incremental evolution, configuration changes, patching and preventive maintenance of the IAM environment.
It alerts customers when their IAM vendor releases a software update, whether a patch or an actual release. Which helps them stay on the upgrading or patching treadmill.
Lastly, it offers location independence for the IAM infrastructure, allowing customers to decide whether they want to host their IAM infrastructure in-house, or elsewhere, without trading off the operational efficiency they require.
Where to Go from Here?
We believe that this model introduces a paradigm shift in IAM thinking, and one that makes the deployment location choice a moot point from an operations perspective, addressing the organization’s concerns with the ongoing support and maintenance of the IAM infrastructure. Hence reducing the IAM operational risk for the organization.
An organization can adopt this model today with an in-house IAM environment and evolve into a managed services, hosted model later on, all while preserving the operational efficiency it requires.
As we announced recently, we are introducing a set of Identity Services under the SCUID framework that provide specific IAM functionality in a co-sourced model. All of these Identity Services hinge on [and include] SCUID Operations for operational management, which allows us to scale effectively and offer a cost-effective and SLA-governed service offering to our customers.
In future articles, we will discuss the merits and rationale behind some of the other services that are part of the SCUID framework. I would love to hear your thoughts.