TEC 2009 Part 3

Greetings All,

This is my first public blog post.   Like many of the other posters on this blog, I was at the Las Vegas 2009 TEC conference as a speaker.  I presented on ILM “2” Best Practices, which was largely a repeat of a presentation that Bahram Rushenas and I presented internally shortly before TEC based on our experiences working with Rapid Deployment Program (RDP) customers that have been working with pre-release versions of FIM.
We tried to focus on both the technical “gotchas” in ILM “2” / FIM 2010 RC0 as well as the deeper, longer-term concerns in implementing a system that touches on so many aspects of the business including system availability and security. 
Some of the technical gotchas we talked about were naming standards and MPR interactions.  Those are the easy, straight forward points. 

The other area is a bit of a passion of mine.  While there are reams of information on how many products work at the nuts and bolts level, there is rarely very good documentation on how to take a business problem from genesis through to a documented, supportable, long-term solution.  (A notable exception is the Identity and Access Management Series at https://technet.microsoft.com/en-us/library/cc162924.aspx.)   Implementation of an Identity Management System relies on the architect or design team to wear a number of hats.  Infrastructure expert, Development guru, and Process Analyst skills are all required to make a fully effective IdM system. 

In ILM 2007 there really wasn’t a need to be more that a basic developer for the technology side.  Everything processed on a per-object, serial manner and occurred in the back room out of sight.  If you had a problem, then you just tied in the debugger and stepped through an object or two.

In FIM 2010 (formerly ILM “2”), you now need to handle workflow, web-services and concurrency on the development side and security, availability and performance much more than before on the infrastructure side.  Placing a debugger on the production FIM Service will likely generate a lot of helpdesk tickets since it will inhibit requests from processing while you are stepping through the code (if you can figure out which transaction you are looking for).

The scope of scenarios that FIM can handle is very much larger and more complicated than the scenarios for which we typically used ILM 2007.

Also, we need to take into account that the solution needs to run long after the implementer has left the environment.  Preferably as something other than a “black box”.  More on that point in a later post.

You will find the presentation from TEC by clicking on this link:  ILM "2" Best Practices Deck.