My company UNIFY is well into its 12th year of existence (as is my tenure), and our “application-driven identity management” mantra has been a core principle in our solution approach from the beginning.  With the advent of cloud and so-called “hybrid” (off/on-premise) identity management I have not wavered from the belief that nothing changes in this regard.  That is despite the popular misconception from certain quarters that identity starts and ends with your on-premise directory.  Let’s just say your AD makes a lousy source of truth (SoT) for identity!

The benefits of aligning enterprise identity lifecycle to its HR platform are many, and at UNIFY we like to focus not just on the various sources of truth (e.g. students vs. staff in an education context), but on the events that should trigger change to an identity profile.  When it comes to harnessing these events, which may be in HR, the on-premise or cloud directory, or even in an LOB application such as a CRM, we are confident our Broker approach is second to none in driving timely identity synchronisation on platforms such as Microsoft Identity Manager (MIM) or any of its predecessors.  Our investment over more than a decade in a common application directory platform for driving IAM solutions is now paying dividends in the form of application sources such as HR systems being presented to an IAM platform such as MIM as an LDAP directory in its own right.

Yet behind the LDAP layer, not all HR systems are created equal … or rather, “some are more equal than others” … but more importantly, not all HR processes, be they BAU (business-as-usual) or EOM (end-of-month), are going enable the HR platform to lend itself to becoming a proxy identity source from the outset.  Put another way … it’s unlikely you will find any HR manager’s KPIs are related to driving an IAM solution.  Here are some possible questions that might come to mind for the HR system owner:

• Did anyone ask me if I should allow my HR system to become the primary authoritative ‘source of truth’ for all enterprise directory employee user profiles?
• Where are all my extra staff going to come from to allow me to meet these new SLAs?
• Why didn’t anyone think to tell me that entering the backlog of new staff records the day before the monthly pay cycle isn’t going to cut it any more?
• I wonder if anyone has thought about what should happen when a contractor (or a bunch of them) take on a permanent role?

What the HR manager is NOT likely to ask, however, is the following:

• How might the IAM platform perform during nightly batch processes?
• I wonder when would be the best time to take the HR system offline for scheduled maintenance and backups?
• What if I forget to tell anyone when I upgrade the HR platform or extend the schema?
• What happens if I want to set up some new test processes in my production environment?
• Do you think it would be OK for me to delete and reload the entire employee table each night (don’t laugh – I’ve seen this one!)?

Lately I’ve been revisiting the fundamental application-driven principles I’ve taken for granted as being the basis for all good IAM solutions, and asking this question:

“What if (unexpected) sh*t happens?”

The question kind of answered itself, and quickly became this:

“Given that it is inevitable that (unexpected) sh*t will happen, who’s responsible for dealing with it?”

Just quietly, I may have been guilty in the past of taking the high ground (subconsciously at least) by thinking to myself (perhaps even out loud) “That’s not a matter for the IAM solution to deal with it – all problems must surely be addressed at the root!”.  Yet most enterprise environments are always in a state of flux, and it doesn’t really help anyone by ducking the problem when it might turn out that you are best equipped to make a difference in this regard – with a just bit of planning and lateral thinking.  This is not to say that the source systems are absolved from responsibility – far from it – but rather that it is better to be pro-active and take preventative action to avert a problem that has possibly yet to be seriously considered.

At this month’s (April 2016) MIMTeam User Group Skype Meeting I am presenting the topic of “Watch out for that Iceberg!”.  In this session (which includes a demo of a repeatable  MIM approach I wish to share with you), I will be asking what can we (as IAM consultants, solution architects and implementers) do to protect our customers or our own companies from unwanted SoT changes?  In particular, how can we be prepared for when unwanted changeshappen in large volumes, and wreak havoc on the unsuspecting systems and processes you’ve painstakingly aligned with that SoT?  What does the term “resilience” mean when used in the context of your IAM solution?

Please join me on the call (see when this is in my timezone) – looking forward to sharing some thoughts and ideas on this topic.