| Subcribe via RSS

Sean O’Neill on OIA versus OIM

March 2nd, 2012 Posted in IAM Engagement, IdM Engagement, Vendor Specific

I was looking into an Oracle Identity Analytics discussion group on LinkedIn the other day and there was a friendly “back and forth” going on between Oracle Identity Analytics features versus Oracle Identity Manager features crossover.  I wanted to highlight the discussion here, specifically with Sean O’Neill‘s response because he really nailed it.

The backdrop, which I will provide here, is something clients ask often for Oracle IdM implementations because there does seem to be some cross functionality between Oracle Waveset and OIM for provisioning, certifications and attestations, as well as some role management, versus OIA for role management, certifications and attestations and overall identity warehousing.

“Oracle Waveset and/or Oracle Identity Manager have similar functionality to Oracle Identity Analytics, so which should I use?”

This is a common question amongst clients as well as implementers.  If you are a client and you see even implementers are divided on when to use which feature in which product, it can get a bit confusing if not unsettling.  The real answer, before I get to Sean’s response, is somewhat three-fold:

  1. (1) The dilemma stems from the fact these were all products derived from different sources and product roadmaps from other companies, and so there simply is crossover in features and functionality.  So the confusion is understandable, even amongst implementers.  In some cases, either answer (“go with OIM“, “no, use OIA for ______”) is “right” and may stem more from an implementer’s comfort level in implementation than anything else.
  2. (2) It’s best, when utilizing these products in conjunction (eg. Oracle Waveset with OIA or OIM with OIA) to settle on the proper division of functionality during the design phase of your IdM project, while keeping mind…
  3. (3) Oracle’s roadmap for both products in the new Oracle Fusion Middleware 11g line.

This will help “settle” the questions during implementation and provide for a more seamless transition to the Oracle Fusion Middleware 11g product line and conformance to that roadmap.

So, when choosing a vendor to implement the Oracle stack, make sure you choose one that understands the Oracle Fusion Middleware 11g product roadmap as well as the specifics of an Oracle technical implementation.  For OIM, you really need technical expertise, as there are many more moving parts for an OIM implementation.  (What a shame that Oracle Waveset was kicked to the curb, but it’s history now, so no sense lamenting it any longer.  A natural product progression for Oracle Waveset users exists in Sailpoint IIQ IMO. :-))  But make sure, when you are RFP’ing for what you know will likely be an Oracle implementation, that you bring on a vendor who thoroughly understands the Oracle roadmap and, preferably, has ties to internal Oracle IdM resources. :-)

Sean’s Response to OIM Functionality versus OIA

Now, for Sean’s clarification on “which to use,” which was the backdrop of the discussion on LinkedIn, I’ll just quote most of Sean’s response:

OIM can do many of the same functions (though not as richly) such as role management, attestations, etc. as OIA, but it can only do it for systems that are connected to OIM. In order for OIM to work with a target resource, it has to be connected to the resource. 

This means using a connector to access the resources user API’s, which introduces cost and effort. This means not all systems in the enterprise will get hooked up.

As most companies do not provision to 100% of their systems, it means they are working with a subset of user entitlement information. OIM is mainly a provisioning platform, using a BPEL based workflow engine to manage accounts across connected systems. (Yes, you can have stubbed, manually maintained resources using emails or flat files to dictate what an admin should change in the user accounts, but that complicates this discussion.)

OIA on the other hand, is at its core, a stand alone identity warehouse. It has an internal ETL engine that can take data feeds from any data table, CSV or XML data dump of user accounts from a resource. There is no “connector” to the resource, just a mapping file to help the ETL engine “wood chipper” the entitlement information dumped from the resource into the underlying warehouse. Therefore, all user entitlements and accounts can be fed into OIA for role mining/management and entitlements and certifications. Because it is more of an identity warehouse, it is a richer source of user/account entitlement information, so it offers a richer feature set around roles and entitlements. It can push changes to a database table or flat file to provision a user, but that is not really what a identity warehouse was designed for.

The good news is OIM/OIA have been integrated together, so if you have information in OIM from your provisioning activities, you don’t have to import/export the two. OIA can read in the subset of user account information in OIM into its warehouse, analyse for roles (including user accounts not in OIM), and then push back the changes to any managed resources in OIM, where they can be automatically applied through the workflow engine.

As OIA came from Sun and Vaau and not the Oracle gene pool, it is natural there are feature overlaps as mentioned elsewhere in this discussion. As Oracle continues to digest the OIA/Sun/Vaau code base into the Oracle 11g Fusion Middleware identity stack, these redundancies will be streamlined and more features will be integrated into the Oracle identity stack (personal opinion, sorry, no new insider info).

So you can use OIM stand alone for provisioning and do role management/attestation on the systems OIM is connected to, or use OIA to manage roles/entitlements across all enterprise systems, but with no provisioning. Or use both together and get the best of both worlds.

(emphasis mine)

I thought his answer was insightful as well as informative, as one would expect from Sean O’Neill, and I couldn’t agree more.  Hope it was helpful to you as well if you’ve been struggling with this question in lieu of a looming Oracle IdM Project or if you are currently working with these products as part of your IdM implementation.


Comments are closed.