A recent response to a forum post by Craig Martin (MVP) stopped me in my tracks in the last days of 2011.  The comment was in response to my request to establish a “Best Practice” (which I will refer to now simply as “BP”) when it comes to working with one particular FIM scenario involving notifications – although the context is not particularly relevant to what I want to say.  His point was that while it might be considered noble to pursue BP for FIM, ultimately we’re all consultants who should be willing to sacrifice “elegance” in order to get the quickest possible outcome that just works.

At first this seemed to me to be a plausible argument, after all nobody is going to thank us for “polishing apples” when at the end of the day it may not alter the outcome.  However this got me thinking over the next couple of days, and early this morning as I lay awake on a houseboat holiday with the family (of all places), and I decided it was worth an article in its own right … mainly because I once thought the same way myself.

My thoughts turned to my own experiences on a project I worked on in my SQL/Web Business Intelligence (BI) days prior to turning my hand to IdM.  I was working in a small team of 3 as part of a (now defunct) MS ISV company in the months shortly after the launch of the Dot Net era, and I recall brimming with pride at the outstanding result we produced after 3 months or so of solid team teamwork, burning plenty of “midnight oil”, and ultimately the glowing response received from a happy client.  In doing so I remember the satisfaction of “thinking outside the square” and pushing beyond the limits of the standard BI toolkit to achieve results that we wouldn’t have dreamed of at the outset.

But the sense of pride and satisfaction quickly turned overwhelmingly to dejection and bewilderment when we were roundly criticized (and even ridiculed) for not sticking to the company’s own solution blue-print, purely on the basis that we had produced something that nobody else in the company could hope to support (with its extensive use of XSL, JS libraries and Flash).  The scathing (internal) peer review appeared to be at complete odds with the glowing praise from the customer, and the enthusiastic testimonial that appeared on our company website shortly afterwards.  Disillusioned, my two colleagues left the company not long afterwards and took their ideas with them, and although I persisted myself, I was forced to “toe the line” in subsequent projects.  While I still believe in the approach to this day, it taught me a very valuable lesson … the best technical solutions are not always the most profitable, nor the most palatable, and in the long run do not necessarily deliver the best outcome for the customer either.

Essentially, what I learned first-hand was that the further removed your solution becomes from the mainstream, the greater the Total Cost of Ownership (TCO) for the customer.  This means that when you have something that you know works, there are only two options if you wish to remain in business … either change the thinking of others to make it mainstream, or abandon the solution in favour of something considered more acceptable (think Beta vs. VHS, Novell vs. Microsoft, …).  This is not to say there isn’t value in pushing boundaries – there definitely is!  However in our case there were forces at work (in particular .Net and SQL Reporting Services) which were far greater than we could tackle at the time.

Ultimately, the thought that keeps coming back to me now is that if I’m not striving for BP in anything , then I might as well stop now!  Just by its very name shouldn’t BP be worth something?

So now … what do we REALLY hear when someone says BP?  What connotations come to mind?  What is the first thing that comes into your head?

Perhaps (like Craig I suspect) you think of that anally retentive guy who wants every “i dotted and t crossed”.  This is really the point of this article – what is REALLY meant by FIM Best Practice?

Maybe it would be easiest to first list some of the things it is most certainly NOT:

• a cookbook we can all blindly follow and expect a consistent result
• something that is beyond dispute
• an insurance policy that vindicates our approach if we do not succeed
• something that eliminates the need to think for yourself

So if it is none of these things, then what is it instead, and what makes it particularly valuable?

To answer this, consider what motivates people in their quest for these …

• discovery of “potholes in the road” (bad experiences), and how to recognise and avoid them
• a “eureka moment” when something previously untried happens to work
• a pattern which when repeated was found to return superior results
• hope of kudos in lighting the way for others to follow
• the quest for benchmarks to qualify certification
• the desire for solution maintainability

This last point is the one that is probably of most interest to me personally, because in the past this has proven the greatest challenge for me in establishing a business built largely on establishing repeat consultancy business with a steadily growing client portfolio, where major project work is typically separated by many months (or even years) of ad-hoc solution support (or “holding the fort” if you like).  It is this kind of environment where it is rarely enough to just get the job done quickly.  Very clever solutions can often be “thrown out the window” in favour of something far less satisfactory purely because the support consultant either

• didn’t understand the original approach
• couldn’t support the original approach, or
• had a personal preference for a different approach.

Such a scenario plays out far too often and invariably it is the client who ends up paying – that is if you don’t go out of business first!

So for me at least, BP should be something very much worth not only investing in, but loudly proclaiming to your current and future clients.  It can be something that sets you apart from the average consultancy as a company – not necessarily because you never make mistakes, but because your culture of “continuous improvement” makes you a more reliable service provider in the long term.

Ironically it is the blind replication of others’ solutions that is possibly the worst advertisement for BP.  I have sometimes worked with consultants who have a list of current certifications a mile long, but who simply cannot stand on their own feet in the real consultancy world.  But don’t blame BP for this – rather blame those who fail to adequately factor in the inherent unpredictability of the world of Systems Integration when scoping and resourcing your project.  Soldier types who are lost without a drill-sergeant continuously barking instructions are a very poor choice for an IAM consultant, and businesses that are not flexible enough to recognise and allow for the inevitable environmental variations from one client to the next will invariably fail.

So what is my Utopia?

My FIM Utopia is a world of community-conscious consultants collaborating to establish a peer-moderated knowledge base which is continually revisited, questioned and steadily improved over time.  It is contributions from left-field that prompt others to sit up and take notice.  It is the willingness to be proven either right or wrong without taking it personally.

That to me is FIM Best Practice.  That is definitely NOT a pipe dream.