I have had the pleasure of working on a significant Australian Government ADFS project over the course of the past year, and looking back on this now it occurs to me that maybe there are not to many sites in the world yet that are using FIM in the way it has been used there.  I can’t go into specifics, but I would love to know who else has attempted anything similar and discovered the same thing we did … that it just wouldn’t work without adopting a change event-driven approach with the FIM sync engine.

In this environment, a custom FIM client is used to delegate secure claims management to administrators who they themselves in turn have been delegated the administrative rights.  There are 2 cases where the real-time aspect of the solution have both transitioned from “nice to have” to “essential” requirements, namely

1. The provisioning of and syncing to user accounts in AD from the FIM Portal (e.g. admin enable/disable); and
2. The replication of claim objects in FIM to a SQL claims database wired up to ADFS.

It has become such an intrinsic part of the solution now that we’ve recently had to overcome a problem which was preventing accounts created in the FIM portal from immediately being provisioned to AD.  Get this … a test case was failed because 4 out of 10 accounts were not created in AD in less than a minute!  How many of you have had a FIM solution test case failure like that? Happily the problem was quickly tracked down to a FIM workflow being fired .too quickly in succession (over WMI) to be picked up by the mechanism we were using, and a fix has now been made available for site testing.

So when I went to our http://www.fimeventbroker.com website just now this got me thinking … people who look at this site and see “fully automated operations” may not appreciate that the event-driven FIM paradigm its about so much more than this … it’s about the ability to apply the FIM technology to real world challenges that just couldn’t be attempted without the tool.

Maybe this next anecdote is more common though … the “Crouching SharePoint” opportunity I blogged about recently was an example of an organisation looking to use the FIM Portal to replace an old in-house web “white pages” application, where updates were being made directly to AD.  It wasn’t hard for me to make the point that they couldn’t obsolete the legacy application and replace it with something that didn’t apply the changes made in the FIM Portal directly to AD (via the Sync Engine) immediately.  I wonder how many of you out there are starting to make similar observations?