It’s been 2 very busy months for me since I last posted, but before I get to the topic above, I want to mark the passing of 2012 and what it meant for me personally.

• Travel – thanks to Carol’s encouragement, and Gil’s willingness to take on board a new speaker, I got to present 2 FIM topics at TEC in both San Diego and Barcelona. I will never forget the experience, and hope very much to do a lot more of this, although sadly it can no longer be TEC as we know it :(;
• MVP – the year I was recognised by the Microsoft community of my peers for my FIM contributions, which I intend to continue making in 2013;
• UNIFY – the year my company launched the FIMTeam site to draw attention to our investment in and commitment to this platform, mixing local with overseas talent to launching our brand on the global stage through a variety of media, including co-sponsorship of the TEC event in Europe with Dell and Microsoft;
• Networking – through all of the above, together with this blog, the FIM Forum, and associated social media such as #FIM2010 on Twitter, I continue to meet interesting, inspiring and dedicated people eager to build a global community of professionals specializing in the Microsoft Identity and Access Management platform. A highlight was travelling to the other side of the globe with my wife and getting to know one of these people and his family in person for a weekend as their guest – priceless!

With such a hectic but resoundingly satisfying 2012, the last 2 months were supposed to be all about taking time out and being with friends and family. I have to thank my family and friends for their patience with me during this time, however, because time spent on the river 2 hours from my home (the new banner is an evening panorama taken just a week or so ago now) was interspersed with work phone-calls and Telstra 4G network facilitated live meetings at 3:30 am in the morning from the deck of a houseboat. The work stuff was what can be expected when you engage in FIM project work in the education sector, when the culmination of over a year’s work and planning happens to invariably coincide with the weeks of school holidays just prior to the start of the school year. The live meeting in the small hours, however, was something that some might have argued I should have given my apologies … but I knew it was about a topic that was of enormous interest to me, which brings me to the title of this post.

This Technet article was posted shortly afterwards, and at the time I must say that there was more than a touch of trepidation among some of us on that call. Everyone seemed to have a heightened sense of ownership of this topic, since most of us have been brought up on ILM2007 and MIIS2003 before it, and every single list item was about a feature of what we know now as the FIM Sync Engine.

For me personally, I have always found the beauty of this part of FIM is its stability and consistency over the best part of a decade. While there have been more than just a few moments of frustration and anxiety brought about by its quirkiness, complexity and through-put limitations, in many ways it has become like a familiar companion. When I find a good thing I tend to stick with it – be it a reliable car, a favourite bottle of red wine, an old woolen jumper, or even a mundane coffee cup. This trait of mine tends to annoy some in my family who would prefer I moved on … and in a funny kind of way I look at this 10 year old identity sync technology in a similar light.

When this kind of thing happens with me, I tend to overlook the negatives that others are quick to point out, and let myself dwell on the positives which are generally behaviours that I can rely on. In the case of this tool, it is for very good reason that I feel this way, due in no small part to the many, many hours I’ve invested in learning its nuances inside out. I don’t like surprises when it comes to those nervous moments (usually when everyone else is asleep) when you have to finally release 1000s of pending exports to Active Directory, which you know if it goes awry will light up the client’s call centre like a Christmas tree in the morning with angry users who can no longer log into the network. A former colleague of mine had the simple mantra “know your products”, and I’ve possibly adopted his mantra like an obsession when it comes to this animal. So when I hear that changes are afoot like these, my response naturally is that someone might be about to pull the proverbial rug out from under me.

On skimming through the list of items marked for depreciation, I have to say I was more than a little chuffed to see the “attribute precedence” entry, after having cursed the idea of “equal precedence” on more than one occasion. When it comes to FIM Best Prectice, near the top of my list I tend to have the steadfast refusal to implement this feature, and I have to admit to feeling satisfaction in seeing this vindicated. This goes for the “do not recall attributes” item as well – I always felt this was a horrible idea, and am very glad to see this going. I see the deprecation of things like these 2 items as being a good thing for everyone – but unfortunately for some this will raise a level of angst when the feature has been implemented as a cornerstone of someone’s FIM sync design. Hopefully, however, there won’t be too much resistence to either of these features being read their last rites.

There are other items in this list which I look at as simply “FIM growing up” (or shedding its skin as I have been thinking of it) … like where withdrawal of support for a legacy technology such as Exchange 5.5 is like releasing the handbrake on your car and letting it perform the way it was intended. As much as I am a lover of things familiar, I am also accused of being a hoarder … clinging onto that hard-to-let-go something that was once indispensable but is now just taking up space for fear you just may need it one more time. Remember that a deprecated feature doesn’t mean you can’t run the earlier version which once supported it … but on the flip side, there are certain things that we really must incent our clients to “get with the times” if we are to build them a solution that will provide them with a solid baseline for the future.

That of course leaves me with the couple of items which I really didn’t want to lose:

1. Combined run profiles – it has always been the “delta import + delta sync” run profile that I hold dear, since this allows me to avoid continually re-syncing 1000s of disconnectors every time I process an incoming change. This has always been highly desirable for systems like Active Directory, where your AD MA will often only ever be responsible for managing just a subset of objects in the connector space. I have often found myself projecting dis-connectors onto the Metaverse as “dummy” object classes to avoid the ongoing sync overhead of processing them each delta sync cycle. My first thought was that this approach was suddenly going to be the only option if this is to be a deprecated feature, However the footnote here leads me to think that I am not alone in having to handle this scenario, and that if it finally is depreciated then we’ll have a better answer as to how to handle the scenarios for which we once used to use this feature.
2. Transaction Properties – both myself and my colleagues @ UNIFY have always used these extensively with rules extensions under a number of entirely legitimate scenarios, such as detecting a variation between a CS object and an MV object that affects more than one inbound attribute flow (IAF), and ensuring that your code always works the same regardless of which order the IAFs happen to occur. Again, I expect that this feature won’t be deprecated without there being a new, better means of accommodating these scenarios.

Despite the moments of fear and trepidation, I thoroughly welcome the publication of this article as a sign that FIM is finally starting to “grow up” … an observation that is reinforced by word from the Microsoft product group that FIM scalability is an incredibly high priority, and that this means we should expect to see steps made to finally allow the distribution of sync processing over multiple sync services, which presently remains an uncomfortable inhibitor of the current architecture.