While numerous regulatory and risk management 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 the main things to avoid:
1. Focusing 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:
2. Automating 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.
3. 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 lever-ages vendor-supplied technology,
80 percent of the functionality in the infrastructure should be standard functionality of the product,
20 percent should be customized infrastructure wait for the first upgrade cycle…).
4. 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.
5. Treating IAM as a Secure Robe 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 the 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.
6. 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 or a
heartfelt data breach occurs.
7. 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 should have a meaningful scope with well-defined and business needs. Empirically, there is something about the number; not to exceed 1200 person hours that is consistent in successful IAM projects.
8. Not managing expectations for the dollars allotted. This occurs when a company allocates most of the budget for product procurement, leaving insufficient 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.
9. Not 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.
10. Poor 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?
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?
securerobe 