"If your only tool is a hammer, then every problem looks like a nail."
The identity management space was born out of a mixed bag of products targeted at specific problems. Examples of these products include:
Web single sign-on
The products have typically been produced by niche players because each problem space remains complex, so the solutions have been complex and expensive. As the products mature they become less expensive, and easier to design, deploy and manage. While this is great progress, the industry should be moving to make holistic identity management easier to design, deploy and manage.
Fierce consolidation in the industry has resulted in fewer vendors with more complete offerings. IBM is an example whereby they have acquired several products. Those products have been re-branded and are now offered as an identity management suite. Where consolidation has not occurred (or does not make sense) we are seeing partnering and vendor integration. Microsoft is an example whereby they have not made so many acquisitions, in favour of partnering to maintain core competencies lined up with the heterogeneous integration requirements. One vendor cannot likely produce an identity management suite capable of integrating with every target. Vintela is an example of a partner specializing in UNIX integration, and Blockade was an example of a partner specializing in mainframe integration. The combined strengths tell a compelling 'better-together' story.
So now we're past the confusion surrounding suites, consolidation and partnering.
In the context of provisioning, one tool is not enough solve all aspects of the problem. This is an important realization that can make solving these integration problems much simpler. Failing to accept this reality will result in using one tool to solve a problem it was not intended to solve. Employing another tool will result in a simple and more supportable solution.
Provisioning is a great example of the identity hammer syndrome because it is often approached with a workflow tool, or a synchronization tool. Some provisioning requirements are highly suited to one or the other. Trying to accomplish all of the requirements with one tool will be very difficult, resulting in a complex solution that is very difficult and expensive to design, deploy and manage.
Things with a lifecycle need to be managed for the duration of their existence. State-based synchronization is highly suited to manage things with a lifecycle. Consider the following examples:
Provisioning a user account into a directory.
The account needs to be managed until it is no longer required, then eventually removed. State-based synchronization can manage this object and track it, continually applying rules to the object until it eventually needs to be removed. Workflow can start to address this requirement too, but is an unnatural fit because workflow does not remember the object once the workflow is complete. If workflow is used to provision the object then another workflow will be required to update the object, and yet another workflow will be required to remove the object. Each workflow requires inputs in order to operate on the object. The inputs are not available to the workflow engine because it is not maintaining state.
Provisioning a cell phone for a new hire
The phone needs to be ordered from the supplier, and the contract signed with the carrier. Workflow can route the request for approval, submit the order to the supplier and carrier, and close the loop by verifying delivery and installation. This is a very natural fit for a workflow product, but a difficult problem to solve with a synchronization tool. This provisioning requirement does not have a lifecycle. One could argue that the workflow has a lifecycle, but can be better described as a transaction, and transactions do not require synchronization.
State-based synchronization is best employed to address requirements with a lifecycle. Stateless workflow is best employed to address requirements with transactions and human intervention. Understanding when to employ each identity tool, and matching the tool to the requirement will make identity management easier to design, deploy and manage.