In mid 2010 I authored what was to be the first version of a couple of reusable workflow activities that have now become the cornerstone concept of essentially every FIM Portal implementation I’ve ever done.  Now I’m the first to admit I’m not a bonafide developer, but having said that, in the last 18 months I have done little but tinker around the edges of the UI components of both a “look up stuff” and a “create/update/delete stuff” activity pair.  Happily so, because the up-front goal I had was to all but eliminate the workflow development aspect of a standard FIM engagement, and I have to say it has been a resounding success (for the projects involved) right from the start.

So much of a success, in fact, that I think the value of these 2 workflow activities has been lost on almost everyone involved in the respective FIM projects, as the focus has been on the main solution design goals that needed achieving – as they should always be.  It is only now and then (like this evening) that I am reminded of just how successful they have been … and it staggers me to think that these have not been incorporated into the core product itself.  Kind of like event-driven sync really 🙂 … but I digress.

I have often heard people coming to grips with FIM saying words to the effect that FIM is only really good for FIM consultants to make money, and ultimately this is NOT a good look for this community.  The real value we can deliver to any FIM client is delivering a high quality outcome on time and within budget.  Nobody will thank us in the end for clever but ultimately costly coding unfortunately (think “total cost of ownership” or TOC), as much as we’d all like that not to be the case!

What we collectively now need to do is make FIM more mainstream, and continuing to reinforce the idea that clients are going to be forever reliant on the .Net developer fraternity to achieve their IAM vision is NOT the way to achieve this.

What I think needs to happen may not be every FIM guy/girl’s opinion, but I think that no client should really have to pay anyone to write workflows that can be achieved entirely by performing basic CRUD operations on the FIM database.  A former boss of mine said over 8 years ago now that if anyone these days expects to be paid still for doing this sort of mundane thing with a SQL database he’d be surprised – so why is it OK now in 2012 with FIM?  Just because we can and others can’t yet?  Surely the art is not in being able to perform CRUD itself, but rather the creative ways you can apply these building blocks to achieve unlimited functionality by simply building on just 2 very basic atomic workflow activities.

So exactly how can we do this when every business requirement is different and often complex?

Here’s an example that came up only tonight … where a design oversight meant that a objects of a specific custom object class in the FIM Portal were not being deleted when they should have been.  Furthermore, it wasn’t going to be easy to identify ALL the possible scenarios in which these redundant objects were going to potentially occur, so a broad-based approach was required to (a) perform a custom lookup when a target object fell into a set, (b) delete all instances of the object returned from the query, and (c) delete the target.  I am almost certain that the average FIM implementer today would look at this task as an unavoidable last minute development exercise.

Consider the impact of this realization when your solution has spent the last couple of months stabilizing in UAT, and the prospect of new binary components being introduced and the associated regression testing required sends chills down your spine.  What is more, you have all but exhausted your project budget!  I can almost feel the pit forming in the bottom of my stomach now …

Thankfully the solution turned out to be a rather trivial workflow implementation thanks to the CRUD activities, with the only complexity in the lookup query itself.  The workflow looked something like this:

1. Use the LOOKUP activity (or the function evaluator in this simple case) to write [//Target/ObjectID] to [//WorkflowData/SaveID];
2. Use the CREATE/UPDATE/DELETE activity (in DELETE mode) to perform a query to return all FIM objects meeting a certain (somewhat complex) criteria and delete them; and
3. Use the CREATE/UPDATE/DELETE activity (again in DELETE mode) to delete the original target object (in case step #2 didn’t happen to delete it first), i.e. /*[ObjectID='[//Target/SaveID]’]

If I look back through ALL of my workflows in this project, of which there are probably close to 100 or so, then it would be safe to say that I could count the number of them NOT implemented with exactly the same principles as the scenario above on one hand.

As an aside, the above workflow will need to be run periodically rather than simply on set transition, and as such is being implemented using what I call “FIM Housekeeping”, which I presented at TEC2012 and will blog about here in due course.

Meanwhile, my message in this post is that everyone can achieve the same thing, no doubt more elegantly than myself, and save a heap of development time, without any of the risk associated with implementing any new (untried) DLLs.  Looking back at this particular project, the only other workflow I think I’ve used might be the one which converted a GMT datetime property into local time for a notification … yet another activity that should be baked into FIM by now, along with the 2 CRUD activities themselves.

Why don’t I post these activities?  Lots of mainly commercial reasons really right now, but maybe one day that will change.  However, I hope that before I get the chance they will happily crop up in the product itself, and thereby in a very short time empower 10-100 times the number of people we are limited to today who are capable of implementing the above kinds of workflows themselves.