In a leading market survey, 66% of IT security officers stated that their identity and access management processes were too manual and insufficiently automated. This indicates that many organizations get less than full value from their identity management (IDM) solution.
As a CA Services senior security architect, I’ve been involved in dozens—if not hundreds—of IDM implementations. Here’s some advice for getting the most from your solution…with the least amount of blood, sweat and tears.
Tip #1: Get involved from the start and stay committed. While outside experts are almost always key to success, the client’s IT leaders will be held accountable for success or failure. That means they need to identify the right people on their team—the people with the right technical and soft skills—to collaborate with the service provider and take ownership of project success when the service provider leaves the premises. The service provider can help identify the required skills.
Requirements gathering takes place before the implementation officially starts—in fact, often before the contract is signed. This is a critical juncture in for project success, because the implementation will be designed and executed based on the requirements the architect gathers from client stakeholders. Don’t scrimp on the time or commitment that stakeholders allot to this phase.
Our clients are always working on many projects, so it’s often a challenge to ensure that the right people are involved, but I can’t overstate how important it is for them to participate through every phase of the project—and beyond.
Tip #2: Include a business analyst on your internal project team. About 50% of CA Services’ implementations are new solution deployments. The other 50% are migrations, where clients want to expand their use of IDM or upgrade to the next release—or even jump four or five levels.
Migrations present the risk of impacting the client’s business, so requirements gathering focuses on identifying risks and determining the client’s risk tolerance—which, more often than not, is close to zero. We always advocate for including a business analyst on the client team, because analysts are invaluable in identifying risks and risk tolerance.
CA Services often mitigates risk by doing a parallel build. We build a new hardware-software infrastructure with three environments—development, testing/QA and production. We plot out the course for migrating and testing the objects the business needs from existing environments to the new, parallel environments.
In typical migrations, clients want to expand IDM value by automating more business functions, resulting in fewer daily routine tasks for security staff. Expanded value also stems from extending the solution’s reach into new provisioning areas such as a mainframe environment or another database. After we identify how the client wants to expand IDM value, we go into the same kind of thought process as for new deployments—identifying the hardware and software the client should add so that we can provide the new function. During this process, business analysts are essential team members.
Tip #3: Test data needs to be real data, and testing can’t be given short shrift. Unrealistic data causes headaches for everyone—and a less-than-effective solution. Allow plenty of time for testing: Time “saved” on testing translates to time spent on fixing issues later.
CA Services architects now regularly recommend using BlazeMeter and JMeter to ensure that we have a broad set of tasks to run quickly—and the same way every time—to validate the implementation or migration. You’ll see more about these tools in future posts.
If your tests aren’t broad-based enough, you’ll go to production with a failed effort. By taking the time to automate the tests and run enough tests, everyone will be confident when you migrate that you’ve seen 95% of what you expect to see. And users aren’t impaired in their ability to do their work.
Tip #4: Never underestimate the effort required; the larger the organization, the more time it will take. This piece of advice speaks for itself.