by Frank Villavicencio
While numerous regulatory and risk management drivers require organizations to deploy an Identity and Access Management (IAM) solution, IAM deployments are notorious for taking too long, requiring too much upfront capital investment and for being too complicated to adequately support after deployment. Still, IDC predicts the market for IAM worldwide to hit 4.8 billion by 2013. While IAM has earned its bad reputation, enough tribal knowledge exists that it really doesn’t have to be that way. Here are some of the main things to avoid:
on technology before business processes. IAM is far more than technology. In
fact, many would argue that it is primarily about business processes. Yet, many
times an IAM initiative is so heavily focused on products and automation that
the underlying business processes are not given proper attention. In the long
term, this often results in the project being deemed a failure, in great part,
because all the technology is doing is automating broken processes. This leads
to the next most common pitfall:
bad processes. Defining a business process is one thing; having a good
business process is another. In large companies, identity-related processes can
be so complex and touch so many people that people don’t know how to fix an
inefficient or broken process or where to start. Unfortunately, what usually
ends up happening is that, instead of determining a better way to do it, they
automate a process that no longer serves the needs of the business.
- Having an
unsupportable infrastructure (leads to abandoning the roadmap). You can
have the best IAM solution possible today, but if it takes too much effort to
maintain, it ultimately ends up being abandoned. Assuming that your IAM
solution leverages vendor-supplied technology, 80 percent of the functionality
in the infrastructure should be standard functionality of the product, 20
percent should be customized functionality. Beyond this balance, the
infrastructure quickly becomes unsupportable (just wait for the first upgrade
- Lack of
executive sponsorship. This one is far from unique to IAM, as it is one of
the most common mistakes made. Whether IT or a line of business leads the
effort, unless IAM has a committed executive sponsor with visibility and
decision-making power, the initiative is doomed from the onset. Given the
inherent complexity of IAM, executive sponsorship is perhaps the most critical success
factor. Lack of sponsorship is one of the main reasons why IAM initiatives fail.
IAM as a project, not as a program. Even with executive sponsorship and a
well-defined roadmap, without ownership, stewardship, continuity and context,
the initiative will not achieve its goals. Having a senior leader – an IAM
project manager, who is dedicated, empowered and motivated to make the program
a success over a multi-year period, is instrumental to the success of the IAM
initiative. Conversely, “treating
IAM as a program, not as a project" significantly increases the chances of
success for the initiative.
- Lack of a
roadmap (the initiative loses direction). Without a defined evolutionary
path, it is all too common to see IAM initiatives dissipate and implode. This
usually happens when IAM initiatives result in response to an internal event,
say when glaring deficiencies are identified during an audit, or a heartfelt
data breach occurs.
- Tackling too
much, too soon. Managing scope is essential for any initiative to succeed,
and IAM is no exception. IAM initiatives should be split into phases not
exceeding six calendar months. Each phase should have a meaningful scope with
well-defined and measurable milestones that address prioritized business needs.
Empirically, there is something about the number; not to exceed 1200 person
hours that is consistent in successful IAM projects.
managing expectations for the dollars allotted. This occurs when a company
allocates most of the budget for product procurement, leaving insufficient
funds to fuel the end-to-end implementation of the solution. We have improved
in this area over the years, but organizations still need to set and manage the
right level of expectation with their executive sponsors - not just the cost to
procure, architect, host and deploy the solution but also the cost to operate
and maintain it (i.e. TCO), as well as the impact that it will have on both the
organization's applications landscape and end user training.
having the right team for the job. Having the right people in the team is
much more than just having the right skill sets and organizational structure –
they need to be available. And even if you have the right people, if they are
not available to devote time to the initiative, it will go nowhere. For
example: An on-boarding or termination (provisioning and de-provisioning)
project must have the appropriate
support from Human Resources, with active support from stakeholders -
particularly during the requirement analysis and design phases.
technical architecture. IAM becomes very difficult to change or adapt later
on if you have a poor technical architecture. Not only do you need to know the
strengths and limitations of your IT environment, but you also need to think
ahead. For example, ask questions such as:
- How would my IAM architecture adapt if our
company acquired another company or was acquired by another company?
- How would applications react if we changed our directory
schema, or if we decided to move away from user name and passwords for
authentication? Would they need to be recoded?
- How will this architecture scale over time in terms of response time performance, administrative support staff required, and geographical coverage?
- How would my IAM architecture adapt if our company acquired another company or was acquired by another company?
There is no escaping IAM – the value it delivers in
helping organizations to effectively
manage costs, compliance, and the ever-increasing need to secure systems and
data continues to drive market expansion despite deployment difficulties. While
large, complex, highly customized and costly IT projects will always be
perceived as risky (and rightfully so), avoiding these common IAM pitfalls can
prevent your IAM program from hitting the skids. Avoiding them will require a
high degree of rigor and attention to detail, but since when is that a bad thing?
Frank Villavicencio is executive vice president at Identropy (Moonachie, NJ). www.identropy.com