The Blue Cheese Effect
by Deborah Volk on June 3rd, 2010

If your refridgerator needs to be cleaned out, everyone living with you probably knows it because the task is usually so far down on your to-do list, you might as well plan a trip to Mars first. The task moves up the list as the odor becomes worse with each door swing. Eventually it reaches crescendo when your friends, neighbors and significant other(s) can stand it no more. This is the point where the "smell" becomes the "stink" or for those of you counting yourselves as fans of Sir David Attenborough, it becomes titan arum.
Back in the 1990s, Kent Beck coined the term "code smell" to refer to symptoms in code that could point to a deeper underlying problem. Typically these symptoms don't break the code and they work, but over time the "smell" can become a "stink". Since Kent, developers have been documenting "code smells" for different languages, contexts, and methodologies. And like any smell, what is perfume to one is blue cheese to another.
Recently I've been thinking about smells in a typical Oracle Identity Manager implementation. As is true for any enterprise-grade software deployed to solve real-world problems (read: abused and exploited) there are patterns that work well and some that don't work so well.

Detecting Blue Cheese in your Oracle Identity Manager deployment:

- Encyclopedia-like User Profile (Xellerate User / USR). I've seen user profiles with as many as 50 attributes. Although this varies with context, I think 10-15 attributes is a reasonable max. If Xellerate User entity represents your "core" identity, you should not have attributes on it that are better placed with the resource/target. Regarding access policies that fire based on groups which are driven by rules that work only on Xellerate User fields, here's a hint: rules are not the only way to become a member of the group.

- Duplication of Adapters aka Copy and Paste Programming. The raison d'etre of adapter mechanism is reuse. If you spend time designing your adapters and (shock! horror!) thinking about a library of adapters just like there are class libraries and frameworks made up of class libraries in various class-friendly languages, you won't see 10 copies of AddThisStringToThatString.

- Large Adapters. Don't click yourself to death and force others to drill down on two pages worth of visual spaghetti that ends up being generated code anyway. If it's more than a screenful (and I don't mean you over there with a 52" screen), it's too much and should be refactored into smaller adapters and/or underlying code.

- Tiny Lookups. Lookups with a few records at the most, sometimes (adding insult to injury) with code (attribute) and decode (value) being the same.

- Bloated Lookups. Perhaps the most frequently encountered smell after Duplicate Adapters and JARs Everywhere. This is when a lookup contains more than 10-15 records, occasionally running into hundreds of lines. OIM can be somewhat blamed for this as there's no good alternative for persisting app-specific metadata in the database unless you want to do it in your own (separate from OIM) tables using your own method.

- Environment-Specific Data Outside of IT Resource. Environment-related data is often spotted as task attributes. In other words, the same logical data element (e.g. server hostname) is present in a number of places. Moving OIM to another environment makes this smell a lot of fun!

- JARs Everywhere. Same JAR in JavaTasks, ScheduleTask, <oim_home>/lib, app server classpath, and (for a truly good measure) a few different directories inside the JDK. Classloaders of the world, unite! You have nothing to lose but your already loaded classes.

All of the things above would work, but over time, these things will start to turn your Provisioning Perfume into something a bit more pungent.

What is your favorite (or dis-favorite) OIM smell?

Posted in Oracle Identity Manager    Tagged with no tags


Ramesh GK - July 28th, 2010 at 6:46 PM
Excellent Article. These are the same/similar issues we face when implementing OIM. Some of them I see are proper Logging not being used when adapter code is developed and some times not logged to file and instead to console. Logging helps a lot in troubleshooting issues either in development or at production. The other one I see is proper organization of adapters/event handlers/scheduled tasks according to their functionality as best practice which allows for ease of on-going maintenance.
Leave a Comment

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)