Skip navigation
All Places > CA Security > CA Identity Management > Blog > 2017 > March

As organizations enter emerging markets by acquiring companies that are successful in those markets, the burden falls to IT departments to introduce new services, maintain security and reduce costs by integrating and streamlining operations, all while onboarding acquired employees. Often, that requires customization of your IDM solution, such as interfacing with legacy systems that need to be kept, at least for the time being.


Currently, 70% of IDM implementations I work on have some customization, but it’s tending down. I would estimate that in the past, 70% of IDM implementations had a lot of customization. In discussing whether or not to customize, I remind the customer that once CA leaves the premises, the client is responsible for governance of those customizations, so they need to retain the technical skills to keep it going.


But often, there’s a better solution. CA Services offers several rapid IDM deployment scenarios that reap value in three short months.


Deployment Xpress simplifies the process of deploying common IDM use cases, such as password reset, forgotten password reset, and birthright provisioning to common endpoints such as Active Directory, without custom coding. Clients select the use cases they need, and Deployment Xpress automatically creates the basic code and policies. A virtual appliance makes installation/configuration quick and easy.


Our best advice to customers is to stay on the field of play with out-of-the-box capabilities, but sometimes they need endpoints for which we don’t normally provide provisioning connectors. In those cases, we use Connect Xpress, an out-of-the-box tool, to create a new connector quickly.


Another option is IDM Policy Xpress, where we can do a lot of logic in policies out of the box, so that clients don’t have to code their own Java or C++ code. This is a huge advantage, for two reasons. First, governance is much less of an issue once CA Services leaves the premises. Second, when the client later decides to do a migration or upgrade (or any other work), there is no need for the client to have the right skill set to manage custom components.


When it comes time to migrate to a new release or environment, Config Xpress eases and facilitates a simplified graphical migration of IDM environments. This out-of-the-box tool supports the migration of and delineation of all IDM objects and their dependencies in the environment, including roles, policies, tasks and workflows, among others. It also provides a graphical comparison that establishes the differences between two configurations, without losing yourself in thousands of lines of XML code.


So before you decide that a customized solution is the only way to go, consider the semi-custom route with CA’s Xpress products.

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.